[cabf_validation] Draft profiles work

[Ryan Sleevi]

Just a reminder on this that feedback on list or on GitHub is very welcome
(thanks Corey and Dimitris!)

I've updated based on all the feedback received so far, and would
definitely welcome substantive feedback on the requirements, as well as any
pet issues for style and format :)

On Tue, Mar 23, 2021 at 7:04 PM Ryan Sleevi <sleevi at google.com> wrote:

> 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/20210405/69b4aba9/attachment.html>