[Servercert-wg] Voting Begins: Ballot SC24 V2: Fall Cleanup

[Wayne Thayer]

Mozilla votes Yes on ballot SC24 V2.

- Wayne

On Mon, Nov 4, 2019 at 10:01 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> Ballot SC24: Fall Cleanup v2
>
> Purpose of Ballot:
>
> This ballot proposes to correct a number of minor errata that have been
> discovered in the BRs and EVGLs. The specific list of changes and
> motivations is as follows:
>
> To the BRs:
>
>    -
>
>    Remove overall ‘1 July 2012’ effective date for 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)
>    -
>
>    Move the construction examples of a Request Token to the definition of
>    a Request Token
>    -
>
>    Remove the definition of Test Certificate, as it is no longer used in
>    the BRs
>    -
>
>    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
>       -
>
>    Correct 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
>       -
>
>    Add the OID for organizationalUnitName, matching the rest of the
>    Subscriber DN documentation
>    -
>
>    Clean up 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.
>       -
>
>       It also removes the now-expired grandfathering for OCSP responders.
>       -
>
>    Referring to “RFC5280” vs “RFC 5280”
>
> To the EVGs:
>
>    -
>
>    Unify the references to BRs to consistently say Baseline Requirements
>
>
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by Ryan Sleevi of Google and Jacob Hoffman-Andrews of Let’s
> Encrypt.
>
>
> -- MOTION BEGINS --
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as defined in the following
> redline, based on Version 1.6.6:
>
>
> https://github.com/cabforum/documents/compare/master@%7B10-25-19%7D...sleevi:2019-07-Cleanups@%7B10-25-19%7D
>
> This ballot modifies the “Guidelines for the Issuance and Management of
> Extended Validation Certificates” as defined in the following redline,
> based on Version 1.7.0:
>
>
> https://github.com/cabforum/documents/compare/master@%7B10-25-19%7D...sleevi:2019-07-Cleanups@%7B10-25-19%7D
>
> -- MOTION ENDS --
>
> This ballot proposes Final Maintenance Guidelines.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 21-October 2019 18:00 UTC
>
> End Time: 05-November 2019 05:00 UTC
>
>
> Vote for approval (7 days)
>
> Start Time: 05-November 2019 05:00 UTC
>
> End Time: 12-November 2019 05:00 UTC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191105/dca8e47a/attachment-0001.html>