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

[Corey Bonnell]

Hello,

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
https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2
ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1856:

"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?

 

5. AKI/SKI

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

 

https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2
ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2797

"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

https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2
ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2404

 

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

 

7. QCStatements as a SHOULD NOT

https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2
ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2260

 

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
O=SSL.com)

Current proposal:

https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2
ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2950

 

Change to:

"Subject commonName attributes MUST NOT..."?

 

11. Backdating

https://github.com/sleevi/cabforum-docs/pull/36/files#diff-e0ac1bd190515a4f2
ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR2128

 

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

 

 

[1]
https://lists.cabforum.org/pipermail/validation/2021-November/001728.html

 

 

-------------- 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>