<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
SHECA votes Yes on ballot SC33.
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>发件人:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> 代表 Wayne Thayer via Servercert-wg <servercert-wg@cabforum.org><br>
<b>发送时间:</b> 2020年8月8日 04:06<br>
<b>收件人:</b> CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>主题:</b> [Servercert-wg] VOTING BEGINS: Ballot SC33: TLS Using ALPN Method</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>This begins the voting period for ballot <span class="x_gmail-il">SC33</span>: TLS Using ALPN Method</div>
<div><br>
</div>
<div>Purpose of Ballot:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>[1] <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ" target="_blank">
https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ</a></div>
<div><br>
</div>
<div><br>
</div>
<div>
<div dir="ltr">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.<br>
</div>
<div><br>
-- MOTION BEGINS --<br>
<br>
This <span>ballot</span> modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.7.0:<br>
</div>
<div><br>
</div>
<div>MODIFY section 3.2.2.4 as defined in the following redline: <a href="https://github.com/cabforum/documents/compare/df5bd3b00e3a215202dedafa68bf8f608d47041b...26913aa7f75a78eff1af5cb628451b9433011a67" target="_blank">
https://github.com/cabforum/documents/compare/df5bd3b00e3a215202dedafa68bf8f608d47041b...26913aa7f75a78eff1af5cb628451b9433011a67</a>
</div>
<div><br>
</div>
<div dir="ltr">-- MOTION ENDS --<br>
<br>
<br>
This <span>ballot</span> proposes a Final Maintenance Guideline.<br>
<br>
The procedure for approval of this <span>ballot</span> is as follows:<br>
<br>
Discussion (7+ days)<br>
<br>
Start Time: 31-July, 2020 17:00 UTC<br>
<br>
End Time: not before 7-August, 2020 17:00 UTC<br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Vote for approval (7 days)<br>
<br>
Start Time: 7-August, 2020 20:00 UTC<br>
<br>
End Time: 14-August, 2020 20:00 UTC<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>