Certificate Transparency grew out of an internal document titled "What should a CA look like?". It was a hypothetical exploration of an `ideal' CA ecosystem assuming that we could start with a clean sheet.

One of the features of those CAs was they they published every certificate that they signed. That way, any mistakes would be public and sites could know when certificates were signed for them. That begged the question of how to detect CAs which weren't publishing all their certificates.

Our constraints are that we want to preserve the privacy of the clients as much as possible and that we can't be sure that we can making blocking requests during certificate verification. (OCSP/CRL revocation checks should use blocking requests but it's never been practical and so no major browser does it. Based on that experience we want to avoid them here.)

As an initial design we could have the clients record the certificates that they've seen and upload them to an auditor, asynchonously. The auditor tracks the published certificates and signals an alarm if an unknown certificate is reported.

But that's a poor solution on privacy grounds: the auditor gets to see the HTTPS sites that you visit. Hashing the certificates doesn't help because the auditor knows the set of valid certificates and can easily reverse the hash. Uploading over Tor is simply going to take down Tor at the scale that we're dealing with.

Instead we have the CA include a signed proof in each certificate that it has been included in the log (called an audit proof). We call the state of the log, at a particular time, a "snapshot" of the log. We also structure the log in such a way that we can generate proofs of consistency. Two snapshots of a log are consistent if all the events in the eariler snapshot are also included in the later snapshot: no events should ever be removed from a log.

The details of creating such a log are explained elsewhere, but we can build such a log and do it efficiently.

Now auditors can publish the hashes of log snapshots that they have observed. Clients can check, for each certificate, that it was included in the log because of the proof in the certificate and they can check that a future snapshot (validated by the auditor) is consistent with that snapshot, i.e. that it contained the certificate.

In order to check consistency they would need to get the consistency proof from the log. However, these are small enough to be reasonably delivered over DNS. Requesting a proof for a particular snapshot might reveal something about what the client is accessing, but DNS requests get forwarded by ISP DNS servers - hiding the client's address to the outside world. (Within the ISP, they already know what you're accessing based on your traffic.)

In the event that the certificate's log snapshot is in the future, with respect to the latest audited snapshot, or if fetching consistency proofs/audited snapshots is temporarily unavailable, then the client has to record the snapshot and try again to validate it later. If, after a reasonable amount of time, and several different methods of fetching a consistency proof, the client still can't validate it then it needs to start reporting the snapshot signature any way that it can - a single bad snapshot signature is sufficient to prove misbehaviour by a log. Typically the browser vendor is going to be both the auditer and the party to which the clients will report suspected problems.

This scheme becomes more effective if there are fewer log snapshots. Since there are O(n**2) consistency proofs, caching becomes much less effective when the number of log snapshots increases. So, rather than snapshotting the log for every certificate, we only snapshot, say, once an hour. (That does add latency to the certificate issuance process.) Once we've done this it becomes quite viable for clients to carry the complete set of valid snapshot signatures from a few logs, saving the lookups if they wish.

The idea that CAs should publish the certificates that they sign stuck. Certificate Transparency is the realisation of that idea on top of the existing system of X.509 certificate authorities.

Firslty, it would be tough to get every CA to implement this and, even if we did, increasing the number of logs dilutes the attention that is paid to each one. So we may well only want a few logs, although this is still up for debate.

And, if we don't have the CAs change how they do things, then we need another way to bundle the audit proof with the certificate in such a way that we don't have to update every HTTPS server to do it. That's still an area of research.