<div dir="ltr"><br><div class="gmail_extra"><br><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:<br><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 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><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">"A CA may rely on a previously verified certificate request to issue a replacement certificate, so long as the certificate being referenced was not revoked due to fraud or other illegal conduct, if:<br></div><div class="gmail_extra">(1) The expiration date of the replacement certificate is the same as the expiration date of the Certificate that is being replaced, and</div><div class="gmail_extra">(2) The Subject Information of the Certificate is the same as the Subject in the Certificate that is being replaced."</div><div class="gmail_extra"><br></div><div class="gmail_extra">Problem Summary: This introduces an additional implied requirement for revocation not present within the Baseline Requirements, and for which several Browser members have highlighted clear disagreement with CAs.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Explanation: The problem introduced here is with respect to "was not revoked due to fraud or other illegal content". The introduction of "Fraud" creates an ambiguity regarding what is required in the Baseline Requirements. The extent of obligations imposed by Section 4.9.1.1 does not include fraud as a general category, but instead limits it to a "fraudulently misleading subordinate Fully-Qualified Domain Name" in Item 7. Similarly, "illegal conduct" creates an ambiguity as to what is required, pursuant to Item 6, which through illustrative example makes a distinction between "illegal conduct" and "no longer legally permitted".</div><div class="gmail_extra"><br></div><div class="gmail_extra">Conclusion: This represents an agenda item for which CAs and several browsers have long disagreed. As a consequence, this detracts from the substantive, though incomplete, improvements being proposed regarding certificate lifetime.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Suggestion: Remove "due to fraud or other illegal conduct"</div><div class="gmail_extra"><br></div></div></div>