[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.