[Servercert-wg] Draft Ballot for Cleanups

[Wayne Thayer]

On this morning's call I volunteered to convert this into a ballot and get
the review period started. I am, however, concerned by the lack of
discussion on the questions posed by Ryan - my comments are below. Will
everyone please take a look at these this week? Some of these corrections
and clarifications are long overdue.

https://github.com/cabforum/documents/compare/master...sleevi:2019-07-Cleanups

>
>    - 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
>
>
I believe that the code that creates a request token would meet the current
requirement, and most, if not all CAs will need to update their CP/CPS to
meet this requirement. This seems like more than a cleanup item to me.


>
>    - 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.
>
>
I prefer the alternative of leaving (ii) so that Test Certificate is
defined as "A Certificate which is issued under a CA where there are no
certificate paths/chains to a root certificate subject to these
Requirements." I'd prefer to add "...a root certificate that is or will
someday be subject to these Requirements.", but I feel that would also go
beyond the scope of a "cleanup" ballot.

>
>    - 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
>
>
LGTM

>
>    - 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.
>
>
- Wayne

On Tue, Oct 15, 2019 at 10:16 AM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> While working on the browser alignment ballot, I spotted one other
> incredibly minor issue for correction, which is referring to RFC5280 vs RFC
> 5280.
> https://github.com/sleevi/cabforum-docs/commit/b4739d241e5af7cde64bbf25a14b2669a13fee66 has
> the diff.
>
>> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191017/c93c388d/attachment.html>