[cabfpub] Upcoming changes to Google Chrome's certificate handling

Ryan Sleevi sleevi at google.com
Tue Sep 24 03:08:57 MST 2013

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

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
 - 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
, 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

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.


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.

More information about the Public mailing list