[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

Note: This is not yet a formalized draft ballot, because of the
interactions with SC23 modifying some of the same sections. We'd need to
decide if we want these ballots to run concurrently, which would mean
providing versions both with and without the SC23 changes. Since folks are
still discussing SC23, it seems we should let that discussion finish.

https://github.com/cabforum/documents/compare/master...sleevi:2019-07-Cleanups
can be used to show the comparison of changes so far identified for
cleanups. In particular, these cleanups are the 'non-normative' bits; I'll
send a separate ballot for the cleanups to align the BRs with one or more
existing root program requirements (e.g. where the root program is more
restrictive).

This was an effort from the Validation WG, originally started by Tim
Hollebeek, formerly known as our "Spring Cleaning" ballot :)

The specific list of changes and motivations, along with specific requests
for feedback on some of these points:

To the BRs:

   - Correct the authorized port descriptive label (http -> https)
   - Correct a few typos (contract -> contact, assigns -> assignees)
   - Clarify the Request Token should be documented in the CP/CPS (or a
   document referenced from the CP/CPS)
      - One potential area of confusion is if folks read it as permitting a
      private/internal only document. I wanted to correct this to say
      "publicly-available document", but thought it best to check in with folks
      on this to see if there were objections. I'll take silence as assent
   - Moved the construction examples of a Request Token to the
   definition of a Request Token
   - Removed the term Test Certificate, as it is no longer used in the BRs
      - I'm a little mixed on this change. It's a term no longer used by
      the BRs, and so it makes sense to delete from the BRs. However, I worry
      that it might lead CAs to inventing their own definition of what a "test
      certificate" is (under the premise of Default-Allow vs Default-Deny).
      - An alternative, which if we want to pursue I suspect would be a
      separate ballot that aligns the BRs with existing Root Program
requirements
      (which I'll be sharing shortly), is to remove (i) which is forbidden by
      Mozilla since 2016, and only leave the definition (ii) in.
   - Correct some of our acronyms
   - Remove effective dates that are in the past
   - Remove validation methods that are no longer permitted
      - Note: This also involves typographical changes to section 3.2.2.4;
      the sections were inconsistent in their use of boiler plate, and so this
      simply aligned the formatting and line spacing, since this ballot is for
      changes that are non-normative in impact
      - Pay close attention to 3.2.2.4.4, which tries to address the
      concern with how to read "lists of things"; this should be only a
      formatting change, but if folks feel otherwise, we should correct
   - Corrects some unnecessarily gendered language to be gender-neutral
   - Clarify that the usable OIDs in a certificatePolicies are what the CA
   documents, and not simply restricted to a CA's own OID arc.
      - This is to make it clear that it's fine to use the CABF-defined
      OIDs for DV/OV/IV/EV
   - Adds the OID for organizationalUnitName, matching the rest of the
   Subscriber DN documentation
   - Cleanup the algorithm requirements
      - Section 6.1.5 is rewritten to reflect what is permitted. This is
      especially important to clarify the requirements are about when it's
      issued, and not simply the validity period expressed in the certificate.
      - Section 7.1.3 is partially rewritten. The MUST NOT is still kept,
      even though Section 6.1.5 clearly omits it, in order to avoid
any ambiguity
      from folks confused about signature algorithm. Given the confusion around
      Default-Allow vs Default-Deny, I can see an argument for
removing that MUST
      NOT, so curious folks' take
      - It also removes the now-expired grandfathering for OCSP responders.
      - That said, I can see confusion resulting from 7.1.3 explicitly
      mentioning certificates, and not mentioning OCSP. I'm curious how folks
      would feel about rewording this to "CAs MUST NOT sign any data using the
      SHA-1 algorithm", which would make it clearer that this also
includes OCSP
      responses. This should not be a normative change, but if folks
feel it's ok
      to sign OCSP responses with SHA-1, then we can defer that to a separate
      ballot and work out the nuances.

To the EVGs:

   - Unifies the references to BRs to consistently say Baseline Requirements
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191012/df92e525/attachment.html>