[Servercert-wg] 回复： Discussion Begins: Ballot SC24: Fall Cleanup

[陈晓曈]

SHECA Votes Yes on Ballot SC24.


Regards,
Toria CHen


------------------ 原始邮件 ------------------
发件人: "servercert-wg"<servercert-wg at cabforum.org>;
发送时间: 2019年10月22日(星期二) 凌晨2:00
收件人: "CA/B Forum Server Certificate WG Public Discussion List"<servercert-wg at cabforum.org>;

主题: [Servercert-wg] Discussion Begins: Ballot SC24: Fall Cleanup




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 first part of 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-18-19%7D...sleevi:2019-07-Cleanups@%7B10-18-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-18-19%7D...sleevi:2019-07-Cleanups@%7B10-18-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: No earlier than 28-October 2019 18:00 UTC


Vote for approval (7 days)


Start Time: TBD


End Time: TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191106/427feb78/attachment-0001.html>