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

Ryan Sleevi sleevi at google.com
Tue Sep 24 03:50:18 MST 2013


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> 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]
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130924/973b6388/attachment-0001.html 


More information about the Public mailing list