<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 2:23 PM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 17/05/17 18:04, Ryan Sleevi via Public wrote:<br>
> I totally appreciate that sentiment, but you realize one area of the<br>
> concern and issues has been the proposal - made by Kirk, Gerv, and<br>
> Jeremy - to allow the reuse of insecurely-validated domain names.<br>
<br>
</span>This is why I am proposing this. Not because I like it, but because CAs<br>
have not kept records of which method was used, any per-method variance<br>
would require them to redo all validations. (And I'm not up for<br>
requiring every CA to redo every validation, either, and it wouldn't<br>
pass even if I was.) So we sigh, grandfather everything in one last<br>
time, and make it a requirement that CAs record the method used so that<br>
in future, we can do method-specific rules.<br>
<br>
What's the alternative proposal, given that many or most CAs can't do<br>
per-method rules right now?<br></blockquote><div><br></div><div>The proposed extension would be simply that the CAs which haven't maintained those records can still signal a BR version 1.4.2 (or 1.4.1 or equivalent). As they gather/complete such records, they can signal a BR version 1.4.x.</div><div><br></div><div>As those who have maintained records revalidate, they can signal 1.4.x. If they reuse information, and it wasn't to 1.4.x, they can signal 1.4.2</div><div><br></div><div>So the capability remains. The signalling is optional until some phase in, with the intent that in the future, it can make such grandfathering technically reliable, which can open up greater flexibility for CAs and the ecosystem in assessing the risk of accepting such certificates. Modulo things which undermine the underlying cryptographic signature (e.g. the choice of algorithm and keys), this allows us greater flexibility to discuss how best to grandfather other aspects, whether about the certificate themselves or the issuance systems. </div></div><br></div></div>