On Wed, Mar 1, 2017 at 4:50 PM, Ryan Sleevi <[email protected]> wrote: > > 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? > > 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. >
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. In the effort of providing greater clarity, I have created several new threads to help inform this discussion. Proposed for Section 4.2.1 "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." 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. 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. 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. Suggestion: Remove this entire section.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
