<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 1, 2017 at 4:50 PM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>></span> wrote:<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 class="gmail_extra"><div class="gmail_quote"><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>
</blockquote></div><br></div><div class="gmail_extra"><div class="gmail_extra">It was pointed out that my description of the issues may not have been clear for some members, so I'll try to restate the various ways in which this proposal, whether intentional or not, weakens the current security guarantees provided by the Baseline Requirements.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the effort of providing greater clarity, I have created several new threads to help inform this discussion.</div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">Proposed for Section 4.2.1</div><div class="gmail_extra">"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."</div><div class="gmail_extra"><br></div><div class="gmail_extra">Problem Summary: The WHOIS protocol is ambiguous, human-readable form that creates significant risk of variance in interpretation as to what "the same registrant" means.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Explanation: The WHOIS protocol is specified in RFC812, which notes quite clearly "The responses are not currently intended to be machine-readable; the information is meant to be passed back directly to a human user." This problem was further discussed during the many meetings in which we hosted various ICANN representatives, who presented about structured forms such as WEIRDS and RDAP. While ICANN/IANA continues to revise its RDAP policies in a way that will provide the suitable level of assurance, the interpretation here leaves a great degree of ambiguity. It was in the pursuit of eliminating such ambiguity, and thus improving security, that Ballots 169/180/181 were adopted, with the eventual hoped for conclusion ballot.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Conclusion: As proposed, this reintroduces an element of "CA judgement" in a way that undermines the years of effort the Forum spent to improve the security of certificates by eliminating troublesome ambiguity in the BRs.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Suggestion: Remove this entire section.</div><div><br></div></div></div>