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)
...
Here are some additional thoughts on revocation transparency and verifiable data structures from the specification author.
Champion / Stakeholder
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 praise 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. |
...
- Add to Log
- Retrieve information from Log
- Retrieve proof from Log
End State
tbd
Success
tbd
Failure
tbd