Making issuance observable
An individual client may not know that a domain holder never requested an issued certificate. Logs expose observed or submitted certificates and precertificate data so interested parties can monitor unexpected issuance rather than depend on chance visits.
A log is not a replacement CA judging a website’s business, nor does it prevent every misissuance. Detection must lead to revocation, trust management or other action. RFC 9162 specifies experimental CT 2.0; it illustrates the mechanisms here without implying that every browser deployment uses that version.
References: [1]
Inclusion and append-only consistency differ
A Merkle tree reduces ordered log entries to a root hash. An inclusion proof supplies enough nodes to reconstruct that root for one entry in a specified tree size and snapshot, avoiding download of the entire history for that check.
A consistency proof compares smaller and larger tree states, showing that the earlier entries remain an unchanged prefix. This append-only question differs from inclusion of one item. Proofs must also be tied to the relevant authenticated log and tree state.
References: [1]
Signed promises still need auditing
An SCT is a signed log promise concerning a submission, with inclusion due within its declared Maximum Merge Delay. Receiving one is not the same as holding an inclusion proof. Clients or monitors can later request proof to check that the promise was kept.
Monitors also inspect new entries and tree consistency. A malicious log can show conflicting views to different observers, so an isolated observer’s proof cannot rule out a split view; comparing observations helps expose it. Public logs also reveal otherwise obscure domain names, creating a privacy boundary alongside audit value.
References: [1]