<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" style="font-size:12.8px">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" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">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">"(ii) the method used to obtain the document or data was acceptable under Section 3.2 at the time the document or data was obtained."</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:</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 proposal makes it effectively impossible to rely on revocation as a means of deprecating insecure practices related to the validation of Subject Information.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Explanation: As with the recent proposal from Peter and Kirk regarding revoking "pre-OV" certificates, for which Kirk/Entrust apparently heartily support, we recognize that there are times when the validation of Subject Information may not be to the level that our users' rely on. This applies both to the organizational information and to the far more relevant and sensitive domain information. Section 4.9.1.1 lists a number of reasons for revocation, notably Item 15, which the CA/Browser Forum has exercised in the past, such as Ballot 144 or in the deprecation of "internal server names". In both cases, the certificates were revoked for reasons other than "fraud or other illegal conduct", and in both cases, the expectation was that all new certificates were validated to the new standards of the in-force Baseline Requirements. This undermines the approach, by allowing a CA to 'resurrect' such certificates following revocation, by introducing ambiguity into whether or not the "replacement certificate" must conform to the in-force Baseline Requirements.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Example: Section 7.1.4.2 of the Baseline Requirements, Item J, permits "Other Subject Attributes", with the stipulation that they "MUST contain information that has been verified by the CA." Imagine that Foo CA, an enterprising CA with an eye for customer service, recognizes a new opportunity to introduce an additional name type in the service of its customer base. The CA determines the appropriateness of how to verify that information (which the BRs leave open-ended), and thus creates a number of certificates bearing this type. Bar CA decides to also engage in this activity, but apply a different standard of validation. Recognizing the inconsistency between this single field having different levels of assurance, Foo and Bar jointly propose a ballot to modify Section 7.1.4.2, defining new normative requirements for the use of this field, so that Relying Parties can have the confidence in the certificates they trust. In order to achieve this, much like past ballots, Foo and Bar require that all previously-issued certificates bearing this field MUST be revoked by a particular date.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Under this proposal, both Foo and Bar - and any other CA - may interpret this section as allowing them to 'resurrect' the revoked certificates. This is because they were revoked for reasons other than "fraud or other illegal content" (whether the information is viewed as misleading or as a security risk is predominantly academic and irrelevant to the example). The CA receives another request - bearing the same subject information - and thus interprets this as a "replacement certificate" - despite having not undergone the same level of validation and assurance. This interpretation is further amplified by the (ii) example, which can be seen as a justification to avoid the necessary validation steps adopted in the new version.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Conclusion: The consequence of this highlights exactly the point made in discussing Ballot 185 - that revocation is unsuitable to fully 'flush out' bad certificates. This proposal enshrines this problem and amplifies it, while undermining the trustworthiness of CAs and certificates.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Suggestion: Remove this entire section.</div><div class="gmail_extra"><br></div></div></div>