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

Rick Andrews Rick_Andrews at symantec.com
Tue Sep 24 10:41:59 UTC 2013


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]
> 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
> https://cabforum.org/mailman/listinfo/public



More information about the Public mailing list