[Servercert-wg] Fwd: Draft Ballot for Cleanups

[Wayne Thayer]

Ryan, Tim,

Will you endorse this ballot when the time comes? Also, if either of you
prefer to be the proposer, just let me know and I'll just do the leg work.

Thanks,

Wayne

---------- Forwarded message ---------
From: Wayne Thayer <wthayer at mozilla.com>
Date: Thu, Oct 17, 2019 at 2:44 PM
Subject: Re: [Servercert-wg] Draft Ballot for Cleanups
To: Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org>


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/819b12db/attachment-0001.html>