<p dir="ltr">Indeed, as we finalize dates and implementation, a corresponding policy update will follow.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cheers,<br>
Ryan</p>
<div class="gmail_quote">On Sep 24, 2013 3:42 AM, "Rick Andrews" <<a href="mailto:Rick_Andrews@symantec.com">Rick_Andrews@symantec.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ryan,<br>
<br>
Since not all CAs are members of the CA/Browser Forum, will you be publishing this to a Chrome policy web site? I see <a href="https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy" target="_blank">https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy</a>; I presume that's your policy page?<br>
<br>
-Rick<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]<br>
> On Behalf Of Ryan Sleevi<br>
> Sent: Tuesday, September 24, 2013 3:09 AM<br>
> To: CABFPub<br>
> Subject: [cabfpub] Upcoming changes to Google Chrome's certificate<br>
> handling<br>
><br>
> I'm writing this message to provide notice to members of the<br>
> CA/Browser Forum about exciting changes we have planned for future<br>
> releases of Google Chrome and Google Chrome OS, in addition to the<br>
> Chromium projects these products are based upon, in the hope of<br>
> minimizing any surprises or inconvenience these may cause.<br>
><br>
> We look forward to continuing to work with members of the CA/Browser<br>
> Forum to improve online security, and welcome feedback regarding these<br>
> plans.<br>
><br>
> Regards,<br>
> Ryan Sleevi, Chris Palmer, Adam Langley, and Ben Laurie on behalf of<br>
> the Google Chrome team<br>
><br>
><br>
> * Changes to Cryptographic Algorithm Minimum Requirements:<br>
><br>
> As specified in Appendix A of the Baseline Requirements, 31 December<br>
> 2013 is the sunset period for the issuance of certificates containing<br>
> RSA key sizes less than 2048 bits. Beginning in early 2014, Chrome<br>
> will begin warning users who attempt to access sites with certificates<br>
> issued by publicly-trusted CAs, that meet the Baseline Requirements'<br>
> effective date, and with key sizes smaller than those specified in<br>
> Appendix A.<br>
><br>
> The anticipated logic is as follows:<br>
> - The end-entity certificate has a notBefore date after the Effective<br>
> Date of 1 July 2012 of the Baseline Requirements<br>
> - AND the end-entity certificate has a notAfter date after 31 December<br>
> 2013<br>
> - AND<br>
> - EITHER the end-entity certificate has a key size weaker than those<br>
> specified in Appendix A (eg: RSA key that is less than 2048 bits)<br>
> - OR an intermediate certificate in the validated chain has a key<br>
> size weaker than those specified in Appendix A (eg: an RSA key that is<br>
> less than 2048 bits)<br>
><br>
> While we would like to extend this requirement to also include root<br>
> certificates with sizes of less than 2048 bits, unfortunately not all<br>
> Root Programs have been updated to remove 1024-bit root certificates.<br>
> This exception for root certificates is temporary, and all CAs must<br>
> immediately ensure that they are providing appropriately strong root<br>
> certificates to Root Programs. Note that future versions of Google<br>
> Chrome and Google Chrome OS MAY remove trust for root certificates<br>
> with RSA keys less than 2048 bits, independent of platform<br>
> configuration, as described at<br>
> <a href="http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-" target="_blank">http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-</a><br>
> Removal-of-Trust<br>
> , so this should not be seen as a permanent exception.<br>
><br>
> While it would be ideal if this caused no issues for users, our<br>
> current data suggests the enforcement of minimum key sizes will impact<br>
> small percentage of sites - roughly, less than 0.1% of sites surveyed<br>
> - due to CAs failing to adopt the technical requirements of the<br>
> Baseline Requirements at the effective date. We want to ensure that<br>
> CAs are aware of the upcoming changes and working with their customers<br>
> to ensure that the CA is capable of passing a Baseline Requirements<br>
> audit.<br>
><br>
> In addition, we anticipate applying these restrictions to so called<br>
> 'legacy' certificates at a to-be-determined later date, as part of the<br>
> natural sunsetting of weaker key sizes and algorithms. A hard cut date<br>
> for such certificates has not yet been determined.<br>
><br>
> Note that these programmatic checks will also cover the DSA and ECDSA<br>
> minimum size requirements, as also specified in Appendix A, but our<br>
> data suggests this should cause no disruptions.<br>
><br>
><br>
> * Improving the Security of EV Certificates<br>
><br>
> All values in [] are TBD.<br>
><br>
> In order to improve the security of Extended Validation (EV)<br>
> certificates, Google Chrome intends to require Certificate<br>
> Transparency (CT) for all EV certificates issued after [date TBD].<br>
><br>
> Once we have gained experience with EV certificates we will publish a<br>
> plan to bring CT to all certificates.<br>
><br>
> We are soliciting feedback on the following plan.<br>
> - Google is already running a pilot CT log.<br>
> - By Dec 2013 Google will deploy three geographically diverse<br>
> production CT logs which will accept all certificates issued by CAs<br>
> accepted by any major browser (which are [Chrome, Internet Explorer<br>
> versions [?], Safari, Firefox and Opera]).<br>
> - Google invites other organisations to deploy CT logs in order to<br>
> improve robustness.<br>
> - On [date TBD] Chrome will begin providing CT status information<br>
> through the UI.<br>
> - By [date TBD] all EV certificates with validity periods beyond [date<br>
> TBD] should be logged in at least [one] qualifying log (see below).<br>
> - On [date TBD] Chrome will create a whitelist of valid EV<br>
> certificates already issued without an embedded SCT [issued by CAs<br>
> participating in CT] from all qualifying logs.<br>
> - On [date TBD] Chrome will cease to show the EV indicator for<br>
> certificates not in the whitelist and not CT qualified according to<br>
> the criteria below.<br>
><br>
> Qualifying Logs<br>
><br>
> A log is qualified if its URL, public key and Maximum Merge Delay<br>
> (MMD) are known to and accepted by Chrome.<br>
><br>
> Chrome will accept a log's URL, public and MMD key if<br>
> - The log has not been shown to have acted in bad faith.<br>
> - The log is run by an entity believed to be capable of keeping the<br>
> log up at least [99.9%] of the time.<br>
> - The log has an MMD of no more than [24 hours].<br>
> - The log conforms to RFC 6962.<br>
><br>
> Qualifying Certificate<br>
><br>
> A certificate is CT qualified if the TLS handshake it is presented in<br>
> satisfies at least one of<br>
> - [Three] or more SCTs from different qualifying logs [or logs that<br>
> once were qualifying] [operated by distinct entities] are embedded in<br>
> the certificate.<br>
> - [One] or more SCTs are embedded in a stapled OCSP response as<br>
> specified in RFC 6962.<br>
> - [One] or more SCTs are sent via the RFC 6962 TLS extension.<br>
><br>
> And at least one SCT for the certificate validates and was issued by a<br>
> qualifying log.<br>
><br>
> Timeouts<br>
><br>
> Chrome will regularly synchronise its list of qualifying logs with<br>
> Google's servers. If the last successful synchronisation was more<br>
> than [10 weeks] ago, the client will [stop checking CT] and [cease to<br>
> show EV indications].<br>
><br>
> Google will keep an authoritative list of qualifying logs and post<br>
> changes to that list on the public CA/B Forum mailing list.<br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div>