Description

Certificate Transparency is an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. (q.v. IETF RFC 6962)

The objectives are described as:

Make it very difficult for a CA to issue a TLS certificate for a domain without the certificate being visible to the owner of that domain.
Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
Protect users from being duped by certificates that were mistakenly or maliciously issued.

(q.v. https://www.certificate-transparency.org/what-is-ct)

Note that end user TLS clients are not responsible for validating CT logs, all they need to do is enforce a requirement that certificates must have extensions that show that they were issued under these procedures by validating a Signed Certificate Timestamp (SCT) data object presented with the TLS server certificate. Monitors and Auditors have the primary responsibility of detecting anomalous certificates that were never submitted to the logs.

According to wikipedia, the implementation status of the standard is as follows:

Google launched its first certificate transparency log in March 2013. According to the list of known logs, there are 14 logs operated by 8 organizations.
In September 2013, DigiCert became the first certificate authority to implement Certificate Transparency.
Google Chrome began requiring Certificate Transparency for newly issued Extended Validation Certificates in 2015.

Here are some additional thoughts on revocation transparency and verifiable data structures from the specification author.

Champion / Stakeholder

Former user (Deleted)

Actors

Submitter	An entity that submits certificates to certificate logs for public auditing (the certification authority that issues the certificates or the certificate owner). If accepted by the log server, the submitter is given a Signed Certificate Timestamp (SCT) which represents the log server's agreement to incorporate the certificate in the log within a fixed amount of time.
Log Server	An entity that operates a log of certificates, based on a single, ever-growing, append-only Merkle Hash Tree of certificates. The log server accepts requests from Submitters to add valid certificates to a Certificate Transparency log.
Monitor	Monitors are publicly run servers that periodically contact all of the log servers and watch for suspicious certificates. For example, monitors can tell if an illegitimate or unauthorized certificate has been issued for a domain, and they can watch for certificates that have unusual certificate extensions or strange permissions, such as certificates that have CA capabilities. A monitor acts much the same way as a credit-reporting alert, which tells you whenever someone applies for a loan or credit card in your name. Some monitors will be run by companies and organizations, such as Google, or a bank, or a government. Others will be run as subscription services that domain owners and certificate authorities can buy into. Tech-savvy individuals can run their own monitors.
Auditor	Auditors are lightweight software components that typically perform two functions. First, they can verify that logs are behaving correctly and are cryptographically consistent. If a log is not behaving properly, then the log will need to explain itself or risk being shut down. Second, they can verify that a particular certificate appears in a log. This is a particularly important auditing function because the Certificate Transparency framework requires that all SSL certificates be registered in a log. If a certificate has not been registered in a log, it’s a sign that the certificate is suspect, and TLS clients may refuse to connect to sites that have suspect certificates. An auditor could be an integral component of a browser’s TLS client, a standalone service, or a secondary function of a monitor. Anyone can create an auditor, although it’s likely that CAs will run the bulk of all auditors because they are an efficient way to gain insight into the operational integrity of all CAs. Auditors take partial information about a log as input and verify that this information is consistent with other partial information they have. An auditor might be an integral component of a TLS client; it might be a standalone service; or it might be a secondary function of a monitor. Note that Auditors and Monitors also communicate with each other to exchange information about logs. This communication path, known as gossip, helps auditors and monitors detect forked logs.
TLS Client	TLS clients are not directly clients of the log, but they receive SCTs alongside or in server certificates. In addition to normal validation of the certificate and its chain, they should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key.
TLS Server	TLS servers are the entities whose certificates are protected under the scheme.

Prerequisites / Assumptions

TBD

Use Case Steps/Sequence Diagram

Functional Use Cases

Add to Log
Retrieve information from Log
Retrieve proof from Log

End State

tbd

Success

tbd

Failure

tbd