Certificate Transparency

Certificate Transparency was built to solve a narrow problem — a certificate authority issuing a certificate it should not have, undetected — and solved it with a structure that turns out to be general. Entries go into an append-only Merkle tree. They can be added. They cannot be quietly changed or removed, including by the party running the log.

• Inclusion proof - Cryptographic evidence that a specific entry really is in the log.
• Consistency proof - Evidence that a later state of the log is an honest extension of an earlier one, with nothing rewritten behind you.
• Operator-independent verification - Both proofs are checkable by anyone, which is the whole point: you do not have to trust the log’s operator to trust the log.
• Auditor and monitor roles - The model separates who appends from who checks, which is what makes it work across organizations that do not fully trust each other.

The reason it sits in this catalog rather than only in a TLS one is that the pattern is being lifted wholesale. Germany’s federal API authorization architecture reached for a transparency log to make illegitimate changes to coarse-grained permissions reliably detectable — designing on the explicit principle that trust is based on protocols and processes, not on institutions, and assuming the insider threat rather than hoping against it. The same Merkle-tree guarantees appear again in Sigstore, in-toto and the Notary Project on the supply-chain side.

It pairs with the live half of the same story: where a transparency log is the durable tamper-evident record, the Shared Signals Framework is the real-time feed of security events between cooperating systems.

Written up in: Trust in Protocols, Not Institutions: Transparency Logs for API Authorization