[cabfpub] BR "corrections" ballot

Peter Bowen pzb at amzn.com
Sat Mar 19 16:26:28 UTC 2016

I’d like to explore creating a “corrections” ballot for the Baseline Requirements with a focus on non-controversial changes that are not intended to change the underlying requirements but instead clarify them.  In order to ensure that it does not become an omnibus ballot mixing controversial bits with non-controversial bit, any member can ask to remove a topic to a separate ballot, no reason required or questions asked.  This should hopefully leave only a set of non-controversial changes.

To kick this off, here are a list of things I’ve noted from the F2F and list posts:

1) Move the information reuse paragraph (as per Doug’s email this week)

2) Clarify the wildcard definition to make it clear that it is only “*.” + a FQDN, not a “*” anywhere in the left label (no “foo*.example.com” or “*foo.example.com")

3) Explicitly allow the commonName in the Subject to contain domain names encoded using U-labels (meaning a certificate can have "xn--vernderung-s5a.com” in the SAN and “veränderung.com” in the CN)

4) Allow “_” in FQDNs

5) Ensure “Subscriber Agreement or Terms of Use” is used instead of “Subscriber or Terms of Use Agreement” and ensure that ToU covers the CA itself in addition to affiliates

6) Clarify that the Subscriber can authorize others to store and use their private key (e.g. VPS/hosting provider)

Other topics not proposed, as I think they are probably worth their own ballot if they are to be addressed:

- Email addresses, SRVNames, and other defined OtherNames in SANs

- Clarifying that a CA can have multiple types of issuers each with their own separate private key (re: Dimitris’ email "Distinction between Intermediate CAs and Subordinate CAs”)

Does anyone have suggestions of other things that should be considered for a BR corrections ballot or think any of my suggested items should be a separate ballot?


More information about the Public mailing list