<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 1, 2017 at 4:31 PM, Kirk Hall via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-2248932783601199251WordSection1">
<p class="m_-2248932783601199251MsoPlainText">There were people at several CAs who worked on this draft, but here is my understanding of these provisions. 
<u></u><u></u></p>
<p class="m_-2248932783601199251MsoPlainText">New subsection (ii) came from Ballot 186, and was intended to deal with the question of whether a change in a validation method requires revetting
 of all applicants who are still within the vetting data validity period. – the answer is no.  (This question briefly came up with Ballot 169.)  If a future ballot changes a validation method and wants to mandate revetting of data that is still within the data
 validity period, the future ballot should specifically say that so no one is confused.<br></p></div></div></blockquote><div>I would like to suggest that your subsection (ii) be an independent ballot. As the Forum strives for consensus, members should seek to ensure the least conflict, by ensuring harmony in the sections.<br></div><div><br></div><div>I appreciate your efforts to solve this issue, but this is a poor ballot to attempt to do so, and naturally jeopardizes the success by increasing risk.</div><div><br></div><div>I want to highlight that Ballot 186 was restating and reaffirming what's already written, and then further restricting it. The proposal here by Entrust does the exact opposite - it weakens the current Baseline Requirements and undermines security and trust in certificates.</div><div><br></div><div>Under the current Baseline Requirements, independent of any other Ballots, a CA MAY use documents and data previously obtained, but MUST use this information as part of the validation fulfillment of Section 3.2. This naturally flows from the explicit and intentional lack of the exception you're introducing. By introducing this, the proposal undermines the security by allowing the use of known-insecure validation methods, thus undermining the years of effort this Forum has spent with respect to Ballot 169/180/181/182.</div><div><br></div><div>While I appreciate the efforts made to provide clarity, the current text is incompatible with this insecure and harmful proposal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-2248932783601199251WordSection1">
<p class="m_-2248932783601199251MsoPlainText">On your second point, the following “new” BR language in Ballot 193 has part of EVGL 11.14.1(6) for EV cert domain validation for many years.  This new BR section is part of an effort to harmonize the BRs and EVGL so if a method is permitted
 in the EVGL, it’s also permitted in the BRs.<u></u><u></u></p>
<p class="m_-2248932783601199251MsoPlainText"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none">“ BR 4.2.1 *** <b>
<u>If an Applicant has a currently valid Certificate issued by the CA, a CA MAY rely on its prior authentication and verification of the Applicant's right to use the specified Domain Name under Section 3.2.2.4, provided that the CA verifies that the WHOIS record
 still shows the same registrant as when the CA verified the specified Domain Name for the existing Certificate.</u></b>”</p></div></div></blockquote><div><br></div><div>It's unclear whether you disagree with the substance of my analysis, and are thus stating it was intentional to weaken the Baseline Requirements, or if you're simply providing clarification for the intent, for which the weakening of the Baseline Requirements was unintentional?<br></div><div><br></div><div>If this was unintentional, we can work to resolve this in a way that achieves the intended resolve. However, if this was intentional, we will continue to disagree, and thus will find it necessary to vote against this ballot. I can only hope that, like Ballot 188, this was merely an unintentional side-effect, and hopefully one we can resolve through collaboration.<br></div></div></div></div>