FAQ

What is the overall goal of the Certificate Transparency effort?

Broadly speaking, our goal is to provide an open auditing and monitoring system that lets any domain owner or certificate authority (CA) determine whether their certificates have been mistakenly issued or maliciously used. By extension, we’ll also protect users (as much as possible) from being duped by certificates that were mistakenly issued or maliciously issued.

How did this project originate?

We recognized that the number and severity of certificate-based threats has been on the rise over the past several years and we decided to do something about it.

Are you actually going to do this or is it just a proposal?

Google is currently operating a Certificate Transparency log, and we are filling the log with certificates that we retrieve while crawling the web. We are also actively working on monitoring and auditing software. 

In addition, we are developing a version of Chrome that checks for Certificate Transparency timestamps when establishing HTTPS connections. Because Chrome checks itself for updates every time it is run, and automatically applies any updates it finds, the Certificate Transparency feature would be in wide use very soon after its release. That said, we do not have a release date for this CT-aware version of Chrome.

Does every CA and TLS client have to participate to make this work?

A security measure that only works when everyone participates isn’t as good as one that does something right out of the box. Certificate Transparency is designed to provide a useful service from the very early days of its operation, and to get better as more organizations, browser vendors and users begin to participate. Google’s services could all offer Certificate Transparency timestamps right from the start. When Chrome finds Certificate Transparency timestamps, it will verify them and report any bad actors it finds right away.

Who is going to be running the logs?

Google is currently running a Certificate Transparency log. We welcome others who want to run logs. But keep in mind, anyone can run a log, since the log does not have to be trusted -- the verification protocols make sure of that.

Who is going to be running the monitors?

We believe most CAs will want to do some monitoring, mainly to track their own certificates, but also to track other CAs’ certificates and watch for missteps. However, anyone can create a monitor and provide subscription monitoring services. Google will likely offer a monitoring service at some point.

Aren't you just creating a CA of CAs?

No. Each log is just a cryptographically verifiable record of every certificate that has been issued. The log cannot include a certificate without that certificate being visible to everyone. Thus, the rightful domain owner is in a position to take action when a certificate is misissued.

If a log misbehaves and tries to, for example, provide a proof for a certificate that it does not, in fact, include in the public log, then this will become apparent when that certificate is used, and furthermore, there will be cryptographic proof of the log's misbehaviour. This will, presumably, result in the log no longer being used for Certificate Transparency.

How do you revoke certificates?

Certificates are revoked in the usual way and Certificate Transparency does not change that. It provides a mechanism by which you can know that a certificate needs to be revoked, but does not itself handle revocation.
How do clients know which logs to trust?
It is anticipated that clients will have a set of acceptable logs built in. If a log misbehaves, this list will have to be updated.

What is an SCT?

An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

How big is an SCT?

SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

How do I include an SCT in the TLS handshake?

The Certificate Transparency RFC states that all TLS clients must support the following three mechanisms for including the SCT in the TLS handshake:
  • X509v3 Certificate Extension
  • TLS Extension
  • OCSP Stapling
Servers can use any one of these mechanisms.

I’ve heard that Google will eventually drop support for TLS Extension and OCSP Stapling. Is this true?

There is no truth to this claim. We like all three mechanisms and we have no plans to ever remove them from the RFC. We also welcome any additional mechanisms that help encourage adoption of Certificate Transparency.

How can we ensure that all CT-enabled browsers trust the same set of CT logs?

Since the correct operation of logs can be publicly verified, there is really no reason for major disagreement between browser vendors. We are confident that a subset of CT logs large enough to ensure robust operation of CAs will be trusted by all common browser vendors.

Does each certificate have to be accompanied by SCTs from multiple CT logs? Or will 1 SCT from 1 CT log always be enough, assuming that particular CT log is still trusted?

The RFC (sect. 3.3.) states that “TLS servers should send SCTs from multiple logs in case one or more logs are not acceptable to the client (for example, if a log has been struck off for misbehavior or has had a key compromise).” We currently recommend including proofs from at least three CT logs. The RFC does not mandate a minimum number as log compromise can also be addressed by a) dynamically adding new SCTs via the TLS extension/OCSP; or b) replacing the certificate.

We note though that browsers may choose to enforce their own minimum number of SCTs - in particular for long-lived certificates or certificates with embedded SCTs only - in order to ensure that revocation of a single log does not break a large number of sites.

If SCTs are served via OCSP or TLS Extension, the SCT can by dynamically selected. We anticipate, therefore, that server software (either the web server or the OCSP server) would be configured to have a variety of SCTs available and could dynamically select an appropriate single SCT to conserve bandwidth. Since these SCTs can be issued asynchronously (unlike SCTs embedded in the certificate), the whole management/selection/issuance of SCTs could be entirely automated.

Each CT log will have the power to choose which CAs it accepts certificates from. This could lead to a situation where a Root Certificate is trusted by one or more browsers, but is not permitted to submit newly issued certs to any of the trusted CT logs. How can we ensure that this sort of situation doesn't happen?

We recommend that all logs accept a liberal list of CAs including at least the Apple, Microsoft and Opera roots. The CA check is for anti-spam and attribution only, so we do not foresee this becoming a problem in practice.

Also note that browsers choose both the CAs they trust as well as the CT logs they trust, so it is clearly in their interest to choose a sane configuration. If no such configuration exists, then CT has failed its goal, and browsers have the power to disable support for CT.

Will there be a limit on the number of trusted CT logs? Or will every CA that wants to run a trusted CT log be able to do so?

Increasing the number of CT logs increases the cost of monitoring for domains and auditors but we think “every major CA” is within limits of feasibility. However, CAs should protect themselves against collateral damage by also logging with third-party CT logs. High performance can be achieved by sending parallel requests to all commonly trusted CT logs and embedding the first n SCT responses.