<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 9:04 AM, 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">Hi Ryan,<br>
<span class=""><br>
On 19/05/17 13:12, Ryan Sleevi via Public wrote:<br>
> Luckily, this is an incorrect interpretation of what's required. It<br>
> would only affect those domains affected by those changed validation<br>
> methods,<br>
<br>
</span>Indeed, but the point is, many CAs currently do not have records of<br>
which method was used, and so surely this would mean "all domains" for<br>
those CAs?<br></blockquote><div><br></div><div>It may, in the context of "data and documents" reuse. It would not, in the context of "previous domain validations" reuse.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> only if they're changed in incompatible ways,<br>
<br>
</span>Do you consider the current form of the 10 Blessed Methods to have<br>
"changed in incompatible ways" from the seven methods we had in the BR<br>
1.3.x timeframe? I'd say they all probably have. So again, isn't this<br>
"all domains"?<br></blockquote><div><br></div><div>No, not exclusively.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> and only when an<br>
> applicant requests a certificate.<br>
<br>
</span>Well yes, but if otherwise you could reuse the data as often as<br>
necessary for the normal reuse period, this is still a significant<br>
increase in work.<br></blockquote><div><br></div><div>I don't think the data supports that - it's proportional to the request. That is, as both Entrust and GlobalSign have highlighted, it's primarily centered around the enterprise set of customers (those acting as enterprise RAs or those OV/EV validated) moreso than it is all issuance. The significance of this is relative to the issuance.</div><div><br></div><div>That said, I think it's worth stressing - we think it's a reasonable path forward that if we allow the reuse of non-conforming validations (e.g. granting benefits to incumbents at the cost to new CAs or those customers transitioning CAs), then we should at least consider encouraging appropriate signals for the CAs that opt to not use the insecure practices. That at least strikes the right balance in providing public transparency regarding the security practices, agility, and thoughtful design that many members have participated in and practiced. </div></div></div></div>