[cabfpub] Ballot 185 - Next steps

[Ryan Sleevi]

On Thu, Feb 23, 2017 at 8:37 PM, Peter Bowen <pzb at amzn.com> wrote:

>
> > On Feb 23, 2017, at 6:39 PM, Ryan Sleevi via Public <public at cabforum.org>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170223/e84e1f94/attachment-0001.html>