[cabf_validation] Draft profiles work

[Tim Hollebeek]

Thanks for the update Ryan.



-Tim



From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi 
via Validation
Sent: Tuesday, March 23, 2021 7:05 PM
To: CABforum3 <validation at cabforum.org>
Subject: [cabf_validation] Draft profiles work



While I'll be unable to make Thursday's call, I did want to share what I 
believe is a "mostly done" attempt to synthesize our profiles work into the 
BRs.



You can access the diff at https://github.com/sleevi/cabforum-docs/pull/36 
(which shows the diff against SC41), and I've attached a rendered PDF version, 
which you can also access from the PR.



There's obviously a lot of polish that can be done, and there are still areas 
that have outstanding questions to the list or need to be filled in, but I 
*think* enough of the thorny issues are sorted to give folks a chance to share 
their impressions.



A random assortment of known issues/open questions:

*	For fields which are SEQUENCEs of multiple structures (e.g. AIA, CRL DP, 
certificatePolicies), what's the best way to communicate requirements? I tried 
to find a good balance here, but curious folks takes. See Section 7.1.2.6.9 as 
an example of this.
*	Lots of polish issues - feel free to add your own pet issue

*	Still need to fix the page margins so that the page footer doesn't run off 
the page (this also affects how the tables are laid out whether on a new page 
or not)
*	Should we left-align the tables or keep them centered?
*	Should we add labels to every table?
*	How to express informative text, like in 7.1.2.6.11 - is there a better way 
to provide context?
*	Still removing various bits of vestigial text (like 7.1.2.4 All 
Certificates)
*	How to express a good MUST/MAY requirement (e.g. see 7.1.6.3 around 
locality/stateOrProvince)
*	Does having the footnote repeated on every page it's used help or hurt, for 
common fields like non-critical nameConstraints.
*	Weird table caption wrapping (see 7.1.2.2.3)
*	The font size for the monospaced font appears to be slightly larger than for 
our default font

*	Various other weird bits

*	e.g. for Subscriber certs, we allow the emailProtection EKU, but the RFC 822 
name SAN is prohibited, so are we effectively saying folks should use the 
deprecated emailAddress subject attribute? Or should we just make it clear 
that emailProtection+TLS == security disaster
*	Separately discussed with DigiCert and Sectigo the handling for 'XX' certs, 
since they're the only ones using them. This approach may not be final.

*	Whether the certificate hierarchy makes sense, and if there are other use 
cases missing

*	For CAs, we have variance based on (Cross-cert vs not) x (Affiliated with 
issuing CA vs not) x (TLS capable vs not) x (Technically Constrained vs not)
*	For Subscriber/Server certs, we have variance based on (level of validation) 
x (country/state/locality information)

*	I need to take another pass documenting all of the bits about the MUST NOT / 
SHOULD NOT, which were derived from various intersections of our existing 
requirements

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