[cabf_validation] Profiles ballot - next steps for open discussion items

Corey Bonnell Corey.Bonnell at digicert.com
Wed Dec 15 16:35:29 UTC 2021


I reviewed the meeting minutes [1] of our very productive discussion of the
profiles ballot last month and distilled the discussion into the following
list of items that have yet to be addressed. Please reply to this message if
you know of other items that are still open but aren't listed.


Here are the 11 items I identified from the meeting minutes alongside some
proposed text for some items. Several of the items are still open-ended and
require further discussion before we can develop concrete text proposals:



1. Cross Certificates must have EKUs

Move to separate ballot


2. First policy OID must be CABF reserved OID

Change to a SHOULD, then consider changing to a MUST in "profiles v2.0"


3. Changes to Name Constraints

Drop specification around sRVNames entirely


4. Cross Certificates

Current text at

"Provided that the Issuing CA has confirmed that the existing CA Certificate
was issued in compliance with the then-current version of the Baseline
Requirements, the Issuing CA MAY deviate from the requirements in [Section
7.1.4](#714-name-forms) as follows:


The encoded `subject` name shall be byte-for-byte identical to the encoded
`subject` name of the existing CA Certificate."


Does this address the concern surrounding legacy names?



AKIs in roots: do we have follow-up for why this should be a SHOULD?



"Uniqueness": RFC 5280 and RFC 7093 make it clear that AKI and SKI values
are not security relevant. Why are we mandating this?


6. certificatePolicies in OCSP responder certificates



Change the MUST NOT to a SHOULD NOT, or MAY?


7. QCStatements as a SHOULD NOT



Change SHOULD NOT to a MAY?


8. Serial number

"MUST be a number greater than zero (0) and less than 2^159 containing at
least 64 bits of output from a CSPRNG."


9. Non-TLS CAs

This is still very much an open-ended question. We likely will need at least
one whole meeting on this topic.


10. (Domain Names in Subject Fields requiring DCV, example given was

Current proposal:



Change to:

"Subject commonName attributes MUST NOT..."?


11. Backdating



Change Description to "MUST represent time of signature plus or minus 48






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211215/15402690/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211215/15402690/attachment.p7s>

More information about the Validation mailing list