[Servercert-wg] VOTING BEGINS: Ballot SC33: TLS Using ALPN

[陳立群]

Chunghwa Telecom votes YES on ballot SC33: TLS Using ALPN Method.

  Thanks!

                Li-Chun Chen

From: Servercert-wg <mailto:servercert-wg-bounces at cabforum.org> On Behalf Of Wayne Thayer via Servercert-wg
Sent: Saturday, August 8, 2020 4:06 AM
To: CA/B Forum Server Certificate WG Public Discussion List <mailto:servercert-wg at cabforum.org>
Subject: [Servercert-wg] VOTING BEGINS: Ballot SC33: TLS Using ALPN Method

This begins the voting period for ballot SC33: TLS Using ALPN Method

Purpose of Ballot:

In January 2018, a vulnerability affecting the ACME TLS-SNI-01 method of domain validation was disclosed [1]. That method is an implementation of BR 3.2.2.4.10, which is still permitted by the BRs despite the vulnerability. Some Browsers have banned the use of method 10 unless mitigations for the vulnerability have been put into place, and one approach to mitigation - using application-layer protocol negotiation (ALPN) - has now been standardized by the IETF as RFC 8737. This ballot replaces the poorly specified and potentially insecure 'method 10' with a new 'method 20' based on RFC 8737.

The ballot proposed no transition period during which method 10, or validations performed using method 10 may continue to be relied upon. The only known current use of method 10 is an implementation of RFC 8737 that would remain compliant (although it may require changes to the CA's CPS and the identifier of the method that is being logged when performing validations).

This ballot also limits the use of the new method to the specific FQDN that was validated - different subdomains require new validations, and wildcards are not permitted. This requirement is not the result of a specific known risk but rather stems from a belief that DNS-based validation methods are more appropriate for verifying control over an entire subdomain.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ


The following motion has been proposed by Wayne Thayer of Mozilla and endorsed by Roland Shoemaker of Let's Encrypt and Tim Hollebeek of DigiCert.

-- MOTION BEGINS --

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.7.0:

MODIFY section 3.2.2.4 as defined in the following redline: https://github.com/cabforum/documents/compare/df5bd3b00e3a215202dedafa68bf8f608d47041b...26913aa7f75a78eff1af5cb628451b9433011a67 

-- MOTION ENDS --


This ballot proposes a Final Maintenance Guideline.

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 31-July, 2020 17:00 UTC

End Time: not before 7-August, 2020 17:00 UTC

Vote for approval (7 days)

Start Time: 7-August, 2020 20:00 UTC

End Time: 14-August, 2020 20:00 UTC



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
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.