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

Thu Nov 7 19:44:49 UTC 2013

Although we appreciate Rick’s and Erwann’s points (and agree with a few of
them), DigiCert still strongly supports CT.  Speaking from experience (as we
already make CT available to customers), only a few of Rick’s points caused
us concern when developing our systems.  The rest were really non-issues.
Here is what we found and recommend when deploying CT:

1)      Complexity. The deployment process was straightforward.  It took one
developer about a week to configure all our systems to support CT. Although
every CA’s systems are different, CT is a simple and elegant solution that
caused minimal impact on our systems. Since Google already supplies most of
the code, even the log server was relatively easy to set up and operate. 

2)      Time Frames.  Maximum Merge Delay is not a long period of time.
Considering that sites can currently go weeks without detecting a mis-issued
certificate, even a CT of 24 hours (which is ridiculous, it’s more like
minutes) provides a substantial benefit over the existing landscape.  A DoS
attack against the log server is detectable, and a log server that fails to
report for an extended period of time becomes untrusted, minimizing the
possibility of an attack. Plus any attacker would need to attack every log
that issued an SCT proof.  

3)      Preventative v. Remediation. Although we also favor preventative
solution, we do not believe any currently proposed preventative solution
alone is sufficient.  CT helps fill the gaps where preventative solutions
fail. Deploying CT does not eliminate prevent CAs from deploying other
preventative solutions.

4)      Log Availability.  The only requirement for a log operator at this
time is availability.  Considering DigiCert and Google are both willing to
host log servers, two of the three log servers are highly available.  If
only a single log is required (see below), each CA can access Google’s log
for the sole proof, making log availability and costs minimal.  Given how
Google has already minimized the cost to CAs, we believe the benefits of
deployment far outweigh any risks identified.

5)      Size. We do not support Google’s recommendation for three separate
time stamps.  Two is sufficient to provide protection.  In fact, I’d prefer
to include only a single proof in each certificate.  If you log a cert to
multiple servers, you can include a new proof later on during re-issue,
which minimizes concerns about log compromise.  Regardless, I do not think
Google should dictate the number of logs.  Instead, each CA should
individually evaluate the risks of a log compromise or unavailability and
decide the number of proofs required.

6)      Costs. DigiNotar exposed a weakness in the multi-trusted CA model.
As direct providers of these services, CAs are in the best position to
remediate the problem.  If expense is required in deployment of the fix,
then CAs should bear it, especially where the change is an opportunity.  We
do not see the costs as disproportionately large if you remember that the
attacks in this area are not theoretical.  CT is a response to an actual
event.

7)      Monitors.  Monitors are already under development and will be
deployed shortly. In fact, I believe some monitors are already in beta. The
auditing role is already being assumed by several universities and (if I
recall correctly) the EFF. CAs are not required to provide monitoring
capability, meaning no expense is required.  

8)      Location of Log Servers. Google is providing a full list of trusted
log servers.  If the log is not on the Google trusted list, then the log
server’s SCT response is useless.  The entire universe of logs will always
be known.  

9)      Privacy. This was a significant initial concern for us.  However,
crawlers used by CAs and EFF already find most of this information.  Since
only the certificate contents are included in the log (and client certs are
not part of the log), the risk of unwanted solicitation is minimal,
especially when all of this information is available through WHOIS.  No
certificates should be exempt from logging as the benefit of the log is only
fully recognized if all certificates are included. Note that all
certificates issued from a domain-constrained intermediate are considered
logged if the intermediate is logged.

10)   Mandate.   We believe Google should require CT for all certs, not just
EV.  To date, EV certificates have been free from missuance.  Changing
processes and creating logs for just EV requires a lot of work for little
benefit.  In fact, we are concerned that requiring logs for only EV
certificates may have a negative impact on EV adoption and implementation.
Implementing  CT for DV certificates is of greater importance and will yield
a more significant improvement in overall Internet security. We would really
like to see a CT requirement date for DV and OV certificates, even if Google
is unable to require full compliance by CAs for several years. EV are a
higher caliber of certificate, and we’d like to see more done to encourage
their use.  As such, we highly recommend that Google establish a CT date for
all certificates instead of just EV certificates. If Google insists on only
requiring CT for EV, then the date for full CA compliance, and a loss of EV
indicators, should be March 2016, two years from when CAs must include
proofs in the certificates.  EV certificates are only valid for two years,
meaning this date will minimize the impact on issued certificates and keep
the white list relatively small.

11)   Browser Dependence.  We would like to see CT eventually become browser
independent.  To move towards independence, we’d like to see other industry
groups committed towards operating logs.  Indeed, we’d like to see Google’s
log be less preferred than those operated by independent bodies.  

12)   Implementation Date. We suggest that March 2014 be the date when all
certs are required to hit a log server.  This will give CAs time to adapt,
implement CT, and notify customers of the change. We suggest the same date
be used for all certificate types.  We do not thing CAs should be required
to include the proof in the certificate at that time.  Instead, that date
should be later to ensure a smooth transition of certificates and encourage
the spread of operational log servers.  Because of the development time
involved and encourage proofs through OCSP stapling, we propose March 2016
as the date when CT become mandatory for every certificate.  OCSP stapled
proofs are more elegant than embedding the proof, but we need time to
promote OCSP stapling and encourage adoption.

13)   Other Technology.  We agree with Rick that CAA (if implemented
correctly) is a good bootstrap.  However, CT and CAA are not mutually
exclusive. CAA adds security the same way requiring OV certificates adds
security.  CAA records add an additional step that ensure the CA know the
certificate is authorized, which is already part of the OV process.
Although neither remediate certificate issuance in the event of a compromise
both OV and CAA are great preventative measures.  Therefore, we agree that
the CAB Forum should continue discussing preventative technologies and
improvements.

Thank you,

Jeremy

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Erwann Abalea
Sent: Thursday, November 07, 2013 12:06 PM
To: public at cabforum.org
Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate
handling

Ryan,

I share some (if not most) of the concerns clearly detailed by Rick.

The first proposition (certificate with 3 SCTs) for a certificate to be CT
qualified is obviously the best one if we want to see a fast CT adoption,
and thus get some quick benefit from CT. But it also is the most scary on CA
software. We're currently evaluating how we can modify our software (luckily
we have our own) with the lowest security impact, but neither is completely
satisfactory:

*	2 certificates with the same serial number under the same CA is
absolutely out of question; the issuer+serialNumber unicity is a strong
requirement, nobody has ever asked for it to be removed, Mozilla recently
has asked CAs to check for this unicity; we have additional security
measures to ensure it
*	the pre-cert produced under a sub-CA may be a solution, but it
requires that the issuing CA is not constrained with a pathLenConstraint=0
(unless you allow for a "nearly-sub-CA"), and this constraint is also a
protection for us (that way, an online CA can't be asked to produce a CA
cert)

The second proposition (SCT in stapled OCSP response) allows for a shared
responsibility between CAs and webservers, so while the impact on CA
software is lower (some work effort is to be done on OCSP responders, fresh
SCTs need to be regularly fetched), the adoption might be lower due to need
for server support. Hopefully OCSPStapling is technically there, just not
deployed.

The third proposition (SCT in TLS extension) won't be seen soon.

CT is a good idea. We don't have the same concerns about privacy (or haven't
encountered the need for it) as Symantec, so being transparent and having
some giant audit log is positive. It's not technically finished, some
details need more work; the responsibilities/audit part hasn't been
addressed at all.

As Rick wrote it, I think CT is not yet ready to be mandated.

-- 
Erwann ABALEA

Le 24/09/2013 12:50, Ryan Sleevi a écrit :

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-p
olicy; 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

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131107/8e86ac69/attachment-0003.html>