[cabf_validation] Draft profiles work

[Ryan Sleevi]

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/20210323/a7f096f9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BR.pdf
Type: application/pdf
Size: 330048 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210323/a7f096f9/attachment-0001.pdf>