[cabfpub] Upcoming changes to Google Chrome's certificate handling
Erwann Abalea
erwann.abalea at keynectis.com
Thu Nov 7 19:05:47 UTC 2013
Ryan,
I share some (if not most) of the concerns clearly detailed by Rick.
The first proposition (certificate with 3 SCTs) for a certificate to be
CT qualified is obviously the best one if we want to see a fast CT
adoption, and thus get some quick benefit from CT. But it also is the
most scary on CA software. We're currently evaluating how we can modify
our software (luckily we have our own) with the lowest security impact,
but neither is completely satisfactory:
* 2 certificates with the same serial number under the same CA is
absolutely out of question; the issuer+serialNumber unicity is a
strong requirement, nobody has ever asked for it to be removed,
Mozilla recently has asked CAs to check for this unicity; we have
additional security measures to ensure it
* the pre-cert produced under a sub-CA may be a solution, but it
requires that the issuing CA is not constrained with a
pathLenConstraint=0 (unless you allow for a "nearly-sub-CA"), and
this constraint is also a protection for us (that way, an online CA
can't be asked to produce a CA cert)
The second proposition (SCT in stapled OCSP response) allows for a
shared responsibility between CAs and webservers, so while the impact on
CA software is lower (some work effort is to be done on OCSP responders,
fresh SCTs need to be regularly fetched), the adoption might be lower
due to need for server support. Hopefully OCSPStapling is technically
there, just not deployed.
The third proposition (SCT in TLS extension) won't be seen soon.
CT is a good idea. We don't have the same concerns about privacy (or
haven't encountered the need for it) as Symantec, so being transparent
and having some giant audit log is positive. It's not technically
finished, some details need more work; the responsibilities/audit part
hasn't been addressed at all.
As Rick wrote it, I think CT is not yet ready to be mandated.
--
Erwann ABALEA
Le 24/09/2013 12:50, Ryan Sleevi a écrit :
>
> Indeed, as we finalize dates and implementation, a corresponding
> policy update will follow.
>
> At this time, we're soliciting feedback on the plans regarding
> Certificate Transparency, and wanted to provide broad notice to
> interested parties - in addition to individual efforts to reach out to
> CAs that are EV enabled within Google Chrome.
>
> Cheers,
> Ryan
>
> On Sep 24, 2013 3:42 AM, "Rick Andrews" <Rick_Andrews at symantec.com
> <mailto:Rick_Andrews at symantec.com>> wrote:
>
> Ryan,
>
> Since not all CAs are members of the CA/Browser Forum, will you be
> publishing this to a Chrome policy web site? I see
> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy;
> I presume that's your policy page?
>
> -Rick
>
> > -----Original Message-----
> > From: public-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>
> [mailto:public-bounces at cabforum.org
> <mailto:public-bounces at cabforum.org>]
> > On Behalf Of Ryan Sleevi
> > Sent: Tuesday, September 24, 2013 3:09 AM
> > To: CABFPub
> > Subject: [cabfpub] Upcoming changes to Google Chrome's certificate
> > handling
> >
> > I'm writing this message to provide notice to members of the
> > CA/Browser Forum about exciting changes we have planned for future
> > releases of Google Chrome and Google Chrome OS, in addition to the
> > Chromium projects these products are based upon, in the hope of
> > minimizing any surprises or inconvenience these may cause.
> >
> > We look forward to continuing to work with members of the CA/Browser
> > Forum to improve online security, and welcome feedback regarding
> these
> > plans.
> >
> > Regards,
> > Ryan Sleevi, Chris Palmer, Adam Langley, and Ben Laurie on behalf of
> > the Google Chrome team
> >
> >
> > * Changes to Cryptographic Algorithm Minimum Requirements:
> >
> > As specified in Appendix A of the Baseline Requirements, 31 December
> > 2013 is the sunset period for the issuance of certificates
> containing
> > RSA key sizes less than 2048 bits. Beginning in early 2014, Chrome
> > will begin warning users who attempt to access sites with
> certificates
> > issued by publicly-trusted CAs, that meet the Baseline Requirements'
> > effective date, and with key sizes smaller than those specified in
> > Appendix A.
> >
> > The anticipated logic is as follows:
> > - The end-entity certificate has a notBefore date after the
> Effective
> > Date of 1 July 2012 of the Baseline Requirements
> > - AND the end-entity certificate has a notAfter date after 31
> December
> > 2013
> > - AND
> > - EITHER the end-entity certificate has a key size weaker than
> those
> > specified in Appendix A (eg: RSA key that is less than 2048 bits)
> > - OR an intermediate certificate in the validated chain has a key
> > size weaker than those specified in Appendix A (eg: an RSA key
> that is
> > less than 2048 bits)
> >
> > While we would like to extend this requirement to also include root
> > certificates with sizes of less than 2048 bits, unfortunately
> not all
> > Root Programs have been updated to remove 1024-bit root
> certificates.
> > This exception for root certificates is temporary, and all CAs must
> > immediately ensure that they are providing appropriately strong root
> > certificates to Root Programs. Note that future versions of Google
> > Chrome and Google Chrome OS MAY remove trust for root certificates
> > with RSA keys less than 2048 bits, independent of platform
> > configuration, as described at
> > http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-
> > Removal-of-Trust
> > , so this should not be seen as a permanent exception.
> >
> > While it would be ideal if this caused no issues for users, our
> > current data suggests the enforcement of minimum key sizes will
> impact
> > small percentage of sites - roughly, less than 0.1% of sites
> surveyed
> > - due to CAs failing to adopt the technical requirements of the
> > Baseline Requirements at the effective date. We want to ensure that
> > CAs are aware of the upcoming changes and working with their
> customers
> > to ensure that the CA is capable of passing a Baseline Requirements
> > audit.
> >
> > In addition, we anticipate applying these restrictions to so called
> > 'legacy' certificates at a to-be-determined later date, as part
> of the
> > natural sunsetting of weaker key sizes and algorithms. A hard
> cut date
> > for such certificates has not yet been determined.
> >
> > Note that these programmatic checks will also cover the DSA and
> ECDSA
> > minimum size requirements, as also specified in Appendix A, but our
> > data suggests this should cause no disruptions.
> >
> >
> > * Improving the Security of EV Certificates
> >
> > All values in [] are TBD.
> >
> > In order to improve the security of Extended Validation (EV)
> > certificates, Google Chrome intends to require Certificate
> > Transparency (CT) for all EV certificates issued after [date TBD].
> >
> > Once we have gained experience with EV certificates we will
> publish a
> > plan to bring CT to all certificates.
> >
> > We are soliciting feedback on the following plan.
> > - Google is already running a pilot CT log.
> > - By Dec 2013 Google will deploy three geographically diverse
> > production CT logs which will accept all certificates issued by CAs
> > accepted by any major browser (which are [Chrome, Internet Explorer
> > versions [?], Safari, Firefox and Opera]).
> > - Google invites other organisations to deploy CT logs in order to
> > improve robustness.
> > - On [date TBD] Chrome will begin providing CT status information
> > through the UI.
> > - By [date TBD] all EV certificates with validity periods beyond
> [date
> > TBD] should be logged in at least [one] qualifying log (see below).
> > - On [date TBD] Chrome will create a whitelist of valid EV
> > certificates already issued without an embedded SCT [issued by CAs
> > participating in CT] from all qualifying logs.
> > - On [date TBD] Chrome will cease to show the EV indicator for
> > certificates not in the whitelist and not CT qualified according to
> > the criteria below.
> >
> > Qualifying Logs
> >
> > A log is qualified if its URL, public key and Maximum Merge Delay
> > (MMD) are known to and accepted by Chrome.
> >
> > Chrome will accept a log's URL, public and MMD key if
> > - The log has not been shown to have acted in bad faith.
> > - The log is run by an entity believed to be capable of keeping the
> > log up at least [99.9%] of the time.
> > - The log has an MMD of no more than [24 hours].
> > - The log conforms to RFC 6962.
> >
> > Qualifying Certificate
> >
> > A certificate is CT qualified if the TLS handshake it is
> presented in
> > satisfies at least one of
> > - [Three] or more SCTs from different qualifying logs [or logs that
> > once were qualifying] [operated by distinct entities] are
> embedded in
> > the certificate.
> > - [One] or more SCTs are embedded in a stapled OCSP response as
> > specified in RFC 6962.
> > - [One] or more SCTs are sent via the RFC 6962 TLS extension.
> >
> > And at least one SCT for the certificate validates and was
> issued by a
> > qualifying log.
> >
> > Timeouts
> >
> > Chrome will regularly synchronise its list of qualifying logs with
> > Google's servers. If the last successful synchronisation was more
> > than [10 weeks] ago, the client will [stop checking CT] and
> [cease to
> > show EV indications].
> >
> > Google will keep an authoritative list of qualifying logs and post
> > changes to that list on the public CA/B Forum mailing list.
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org <mailto:Public at cabforum.org>
> > https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131107/d14ec78a/attachment-0003.html>
More information about the Public
mailing list