> On Feb 23, 2017, at 6:39 PM, Ryan Sleevi via Public <[email protected]> > wrote: > My hope is that, now having a concrete Ballot behind us, and an upcoming > meeting, we can use this opportunity to focus on the concrete concerns > raised, to recognize our opportunities to gather and share data in advance of > those discussions, to find commonality in our perspectives now that we have a > clearer picture of where people are approaching from, avoid ratholing > ourselves onto concerns that weren't raised as part of this process, and > hopefully, ideally, acknowledge the unacceptability of the status quo, and > the urgent need for a plan forward. > > Given our own deep concerns about the CA ecosystem's current practices, I > anticipate Chrome will need to finalize our plans soon. My ideal outcome is > that we can use this time leading up to and during our meeting to explore > opportunities to reach an industry consensus, so that we can take this step > forward towards a more secure Internet together. > > For DigiCert, Entrust, Izenpe, Quovadis, Actalis, Symantec, Trustwave, CFCA, > GDCA, and Apple - I'm not sure we will be able to find consensus at 27 > months, unfortunately. Ultimately, the acceptable validity period of a > certificate that a browser accepts defines its commitment to the Web Platform > that we will make every effort to avoid disrupting site operators and users. > In doing so, we browsers take on the liability that results from CA > misissuance, in that it becomes necessary for browsers to address issues of > CA incompetence, malice, and apathy in a way to minimize disruption to our > users while ensuring their security. Similarly, it represents how long the > browser views the data and methods used to be acceptable and trustworthy > relative to the security goals and requirements of the browsers. While I > appreciate the feedback, I suspect this is a point of irreconcilable > difference - 27 months represents a fundamentally unacceptably long time, > particularly given the risks the ecosystem faces and the changes the > ecosystem needs to cope with the continual violations of the Baseline > Requirements.
Ryan, I’m not sure I follow this last paragraph. I’m afraid that there might be a couple of run-on sentences in there that may things a little confusing. I think you said: Browser vendors (at least Chrome) are trying to make a commitment that a certificate that works on its issuance date will work until it expires. This commitment is true regardless of changes in the standards for issuance of certificates. Put another way, from your perspective, the only acceptable method to roll out changes is by making the change effective for all certificates issued after date X. Invalidating existing certificates is something that should only happen in the absolutely most extreme case. Further, Chrome believes that the status quo for certificate issuance is not acceptable. Public certificates, as the exist today, do not hit the target security bar. Various attackers have found a number of ways to get certificates that they should not have been able to get (e.g. they didn’t properly control the FQDN in the certificate). Your view is that this can be attributed to some combination of "incompetence, malice, and apathy” on the part of CAs — for example, the CA either didn’t do a good job of implementing robust validation processes or or didn’t care that their process wasn’t strong enough (e.g. did the minimum to meet the BRs). One of the implications of this is that you can’t trust any issuance date asserted by the CA. Given that (1) breaking existing certificates not acceptable, (2) the objective is to raise the security bar to an acceptable point, and keep raising it as issues are found, and (3) you can’t differentiate between certificates issued before the bar was raised and after the bar was raised, the only acceptable solution is to reduce how long “existing” certificates can exist. Right now it takes at least 3 1/4 years to remove all “existing” certificates after a change, which means 3 1/4 years to get the bar raised to the new level. Given the speed at which attackers are innovating and evolving, this is too long. The Chrome view is that 13 months is the longest acceptable wait to raise the bar. Is this accurate? Thanks, Peter _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
