<div dir="ltr"><div>Just a reminder on this that feedback on list or on GitHub is very welcome (thanks Corey and Dimitris!)</div><div><br></div><div>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 :)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 7:04 PM Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>You can access the diff at <a href="https://github.com/sleevi/cabforum-docs/pull/36" target="_blank">https://github.com/sleevi/cabforum-docs/pull/36</a> (which shows the diff against SC41), and I've attached a rendered PDF version, which you can also access from the PR.</div><div><br></div><div>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.</div><div><br></div><div>A random assortment of known issues/open questions:</div><div><ul><li>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.</li><li>Lots of polish issues - feel free to add your own pet issue</li><ul><li>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)</li><li>Should we left-align the tables or keep them centered?</li><li>Should we add labels to every table?</li><li>How to express informative text, like in 7.1.2.6.11 - is there a better way to provide context?</li><li>Still removing various bits of vestigial text (like 7.1.2.4 All Certificates)</li><li>How to express a good MUST/MAY requirement (e.g. see 7.1.6.3 around locality/stateOrProvince)</li><li>Does having the footnote repeated on every page it's used help or hurt, for common fields like non-critical nameConstraints.</li><li>Weird table caption wrapping (see 7.1.2.2.3)</li><li>The font size for the monospaced font appears to be slightly larger than for our default font</li></ul><li>Various other weird bits</li><ul><li>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</li><li>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.</li></ul><li>Whether the certificate hierarchy makes sense, and if there are other use cases missing</li><ul><li>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)</li><li>For Subscriber/Server certs, we have variance based on (level of validation) x (country/state/locality information)</li></ul><li>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</li></ul></div></div>
</blockquote></div></div>