<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 8:40 PM, Peter Bowen via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</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">
Do others agree that this path makes sense in order to provide high assurance of website identity?<br></blockquote><div><br></div><div>In past discussions, many CA members have rightly pointed out the the Baseline Requirements' Effective Date was non-binding, which is why so many of them failed to incorporate the many useful security improvements for some time. As best I can tell, based on the excellent public CA Communications that Kathleen Wilson of Mozilla did (at <a href="https://wiki.mozilla.org/CA:Communications">https://wiki.mozilla.org/CA:Communications</a> ), the set of currently trusted CAs did not fully comply with these requirements until mid-2013. Perhaps 2013-07-01T00:00:00Z would make a more suitable date to get the level of assurance so desired.<br></div><div><br></div><div>That said, I do worry that even with 2013-07-01T00:00:00Z may be too far back. The CA/Browser Forum recognized, since the first version of the Baseline Requirements, that 39 months represents the upper limit as to how long it is safe to rely on such organizational or individual information, as reflected in Section 4.2.1. Thus, I would suggest that if our goal is to adequately distinguish whether a certificate is legitimate OV/IV, we should apply that same standard. I do like the symbolic cleanliness of the five year anniversary of OV/IV, so might I suggest that we keep that, work backwards 39 months, my calculations suggest this would be to revoke those certificates with a notBefore of 2014-04-01.<br></div><div><br></div><div>It seems also prudent that, if our goal is to ensure that the corpus of CA issued certificates which otherwise are not compliant with OV, we should also consider revoking any of those certificates issued by CAs that have received a qualified audit, as the presence of a qualified audit is an indicator that the process and standards are not at the level expected. Given that auditors do not provide incident reports, nor do they analyze the scope of the misisuance in producing qualified audit reports, it would seem the ecosystem would only truly get that level of assurance if we also flush those certificates out. I'd be happy to work on a list of such CAs whose certificates should be revoked due to operational or validation failures, so that we can truly move the ecosystem forward.<br></div><div><br></div><div>Even with all of these wonderful steps - revoking such certificates with a notBefore of 2014-04-01, revoking such certificates from any CA who has received a qualified audit or had validation issues - I believe we might still have trouble distinguishing whether or not those certificates comply with the OV/IV portions of the Guidelines, because as presently worded, the Guidelines only apply to those 'intended' to be used for this purpose, and some CAs may have issued such certificates under other policies, as they did not intend for these certificates to be used this way.</div><div><br></div><div>Thus, in the effort of promoting a cleaner system, might I suggest we include in the set of certificates to revoke any certificate that does not assert either 2.23.140.1.1, 2.23.140.1.2.2, 2.23.140.1.2.3? This would help ensure only those that were truly intended for this level of assurance will remain trusted.</div><div><br></div><div>To the extent possible, I'm sure there's openness from the Browser community to help ensure such certificates are adequately revoked, by ensuring such software rejects certificates that meet any of the criteria. Of course, for those TLS clients that lack the flexibility to update, and thus are forced to only support revocation, I think revoking these certificates also sounds like a good idea.</div><div><br></div><div>I am concerned about what impact this might have on CAs' CRL sizes, which could be a quite unfortunate side-effect. Perhaps this Ballot should be accompanied with a requirement that if the CA has any such certificates (that would be revoked), then they MUST ensure all new certificates after that date utilize a different CRL Distribution Point. This will help ensure that new certificates do not pay for past mistakes, by ensuring those that check revocation do not have to encounter CRLs as we see today, easily multi-megabyte.</div></div></div></div>