<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 2:00 AM, Kirk Hall via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Gerv said a few weeks ago, requiring revalidation of all outstanding domains every time there is an incremental improvement in domain validation methods will turn out to be a tremendous disincentive to ever adopt such incremental improvements. </blockquote><div><br></div><div>Luckily, this is an incorrect interpretation of what's required. It would only affect those domains affected by those changed validation methods, only if they're changed in incompatible ways, and only when an applicant requests a certificate.</div><div><br></div><div>For what it's worth, the same logical argument you're making can be applied to CA selection - that is, the reuse of domain validation information provides a tremendous disincentive to ever changing CAs, because it would require revalidation of any applied-for domains. As such, the opposition could, in some extent, be seen as a way to try to discourage market flexibility by offering incumbents greater advantages over their competitors.</div><div><br></div><div>We cannot argue that domain validation is difficult without also acknowledging that, in part, the reuse serves to benefit incumbents and discourage market flexibility. That is the reality of what is being discussed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If there is ever a strong evidentiary showing that a particular existing validation method has *actually* resulted in a meaningful number of misissued certificates, everyone would likely agree to improving the validation method immediately and launching a campaign to revalidate all the affected domains over a short, reasonable period.  </blockquote><div><br></div><div>I wish this were true, but this is simply posturing. Google raised concerns with the web based domain validation, for which we saw - and continue to saw - 'not approved' certificates issued. CAs have responded, in turn, by suggesting these certificates - issued against the domain holders will - are not actually 'misissued', since they were 'properly' validated.</div><div><br></div><div>This was over three years ago, and we still do not see progress. It appears that CAs are putting cost in front of security, but such as it goes with the Baseline Requirements.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">However, in our current discussion of Ballot 190, no such strong evidentiary showing has ever been made by anyone, and so Ballot 190 clarifies that the long-standing rule permitting reuse of proper validation data under BR 4.2.1 and EVGL 11.14.3 continues in place.<br></blockquote><div><br></div><div>That is an interesting way of phrasing, as a way to dismiss the past members-only discussions and examples raised.</div><div><br></div><div>To the more substantive, technical part of your argument - that is, to ignore the logical flaws in the other aspects - it would appear you may be misinterpretating Peter's explanation, or at least, taking a degree of liberalness with it.</div><div><br></div><div>That is, there's the reuse of data and documents - 4.2.1 - and there's the reuse of domain validation - 3.2.2.4. Peter rightfully pointed out the arguments with 3.2.2.4 allowing this reuse, but you agreed by citing 4.2.1.</div><div><br></div><div>I do not think there is a reasonable argument for suggesting that the domain validation process itself constitutes data or documents - that part clearly contradicts with the language in 3.2. I think Peter's summary of the debate around 3.2.2.4 is reasonable and accurate, but it's entirely separate from 'reuse of proper validation data' - because, very clearly, when you're using one of these legacy methods, you are _not_ reusing previous data to verify the current request (4.2.1) - you're using a previous validation to skip domain validation entirely (3.2.2.4).</div><div><br></div><div>Does that help clarify the difference for you about what's being discussed?</div></div></div></div>