On Thu, Feb 23, 2017 at 8:37 PM, Peter Bowen <[email protected]> wrote: > > > 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? >
I should have you review all my mails before I sent them. Yes, this is exactly the set of concerns I (poorly) tried to capture and why 13 months is a critical requirement. Note that 3 1/4 years represent the floor, meaning it's the minimum, not the maximum. This is why, historically, Chrome has pushed for very aggressive timelines - because we're always at a 3 1/4 year penalty out of the gate, so phasing something in over 1 1/2 to 2 years can easily mean it ends up taking 5 or more years to actually address security issues. As we reduce that base time, we have much more flexibility on how to phase in raising the bar.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
