[cabf_validation] Minutes of the Validation subcommittee call on 2020 08 13

Robin Alden robin.alden at sectigo.com
Thu Aug 27 06:57:57 MST 2020

Minutes of the Validation subcommittee call on 2020 08 13

Tim Hollebeek (leading)
Wayne Thayer
Amanda Mendieda (spelling?)
Andrea Holland
Aneta Wojtczak 
Arno Fiedler
Ben Wilson
Bruce Morton
Clint Wilson
Corey Bonnell
Daniela Hood
Joanna Fox
Johnny Reading 
Li-Chun Chen
Niko Carpenter
Rebecca Carpenter
Robin Alden (minutes)
Shelley brewer
Wendy Brown

Start discussion on subscriber certificate profiles..

The sheet is at 

Going through the sheet in the order in which the fields appear in the BRs. Subscriber Certificate
a. certificatePolicies

Clint: as of September 30th must include CABF reserved policy OID
Corey: also, anyPolicy should be prohibited (but is not currently

Do we know anyone who is putting anyPolicy in subscriber certificates?
Corey: There are some in censys.io.  They do exist.

Wendy: Do you need to have a policyIdentifier or your own in addtition to
the CABF one?
Ben: No, the CABF one suffices.
Wayne: We should make clear that multiple policyIdentifiers are permitted.
Wendy: Can you have more than one CABF OID?
Not in a subscriber certificate.

Clint: it seems like all of the leaf certs (in censys.io) that have
anyPolicy are OCSP responder certs, so it looks like it would be safe to
prohibit anyPolicy in subscriber certs in a future ballot.

We decided to flag in the spreadsheet where we identified items for change
in a future ballot (e.g. prohibition of anyPolicy in subscriber certs)

Wendy: Saying that's a BR violation if you can only have one CABF OID in
there but we permit anyPolicy.
Tim: Maybe we should be careful about whether the Sept 30th requirement
includes only explicit policy OIDs, but the 'exactly one CABF OID' is not
currently explicit.
Corey: For subscriber certs, the CABF OID choices are mutually exclusive.

I would have read that as explicitly mentioned policy OIDs and not read it
as including 'anyPolicy.

Wendy: We're trying to make this profile document to be very clear, so we
want to add the language about anyPolicy being prohibited there, and then
flag it that we want people to review and make sure it doesn't prohibit what
they're doing.
Ben: Agree

Wendy: Would be interesting to see if any of the crt.sh certs with anyPolicy
also have the CABF OID.
Clint: They seem to be timestamping and OCSP responder certs.
(unexpired & trusted in censys)

Tim: Even if we want the first version of the profile to be mostly the
existing requirements, this is the kind of clarification that we should be
willing to include.
No reason to continue to permit things that are unintended and which no-one
is doing.

Wendy: Add in column 'N' anyPolicy is prohibited.

certificatePolicies:policyQualifiers:policyQualifierId (Recommended)
(RFC2119 - same as SHOULD)

HTTP URL for the **Issuing CA**'s Certification Practice Statement

'Issuing CA' is a defined term.

Wayne: Should it point to a directory of all of the docs? Or should it point
to a particular document pertinent to this cert?
(further discussion required)

BRs say (HTTP URL for the Subordinate CA's Certification Practice Statement,
Relying Party Agreement or other pointer to online information provided by
the CA.) - which is more permissive - i.e. that doesn't say 'must be a CPS'



(Browser alignment ballot is incorporated into profile spreadsheet)

BasicConstraints -> Optional
You can have pathLength must be omitted because ca=False
(agreement on removing basicConstraints altogether for subscriber

keyUsage (no criticality requirement)
various values prohibited.

We will pick up by finishing off keyUsage


Robin Alden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200827/50efaea1/attachment.p7s>

More information about the Validation mailing list