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

[陳立群]

Chunghwa Telecom Co. Ltd., Votes Yes on Ballot SC24. 

 

Sincerely Yours,

 

             Li-Chun 

              

 

mar., 5 nov. 2019 a las 6:01, Wayne Thayer via Servercert-wg (<servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >) escribió:

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

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

o 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

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

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

o 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

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 
http://cabforum.org/mailman/listinfo/servercert-wg



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191111/bd59e3e5/attachment-0001.html>