<div dir="ltr">Let's Encrypt would be happy to endorse.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 4:20 PM Wayne Thayer via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I am seeking two endorsers for the following ballot that replaces domain validation method 3.2.2.4.10 with the TLS ALPN method defined in RFC 8737.</div><div><br></div><div>Thanks,</div><div><br></div><div>Wayne<br></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 name of the method 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 xxx of yyy and xxx of yyy.<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/pull/205/files" target="_blank">https://github.com/cabforum/documents/pull/205/files</a> </div><div><br></div><div dir="ltr">-- MOTION ENDS --<br><br><br>This <span>ballot</span> proposes two Final Maintenance Guidelines.<br><br>The procedure for approval of this <span>ballot</span> is as follows:<br><br>Discussion (7+ days)<br><br>Start Time: TBD<br><br>End Time: TBD</div><div dir="ltr"><br></div><div dir="ltr">Vote for approval (7 days)<br><br>Start Time: TBD<br><br>End Time: TBD</div></div></div>
_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</blockquote></div>