What is the difference between RFC 6962 and static CT?

RFC 6962 is the original certificate transparency protocol, where a log exposes a dynamic HTTP API and signs a Signed Tree Head with an ECDSA or RSA key. The static-ct-api model, sometimes called tiled logs or Sunlight, serves the same Merkle tree as static tile files and represents the tree state as a signed-note checkpoint. Static logs are cheaper to operate and mirror, and their checkpoint format natively supports multiple signatures, including witness cosignatures and post-quantum signatures. Let's Encrypt shut down its RFC 6962 logs on 28 February 2026, so the ecosystem is now mostly static.

What is ML-DSA-44 and why is it used for signatures?

ML-DSA-44 is the smallest parameter set of ML-DSA, the module-lattice digital signature standard published as NIST FIPS 204 and derived from CRYSTALS-Dilithium. Its signatures are 2,420 bytes and its public keys 1,312 bytes, much larger than the 64-byte signatures of Ed25519 or ECDSA P-256, but unlike those classical schemes it is not broken by Shor's algorithm on a quantum computer. Certificate transparency checkpoints can absorb the size because a checkpoint is fetched once by monitors rather than sent on every TLS handshake, which is why the transparency layer can adopt post-quantum signatures years before DNSSEC or the TLS handshake can.

All research

2026-08-18 · RESEARCH · The Offensive Technology team

Certificate transparency post-quantum: 43% of static-CT logs already sign with ML-DSA-44

Q: How does a witness cosignature prevent a split view?

A split-view or equivocation attack is when a malicious or compromised log shows one version of its tree to victims and a different, honest version to monitors, so the fraudulent certificates never appear where anyone is watching. Because a witness only cosigns a checkpoint after checking it is consistent with the history it already holds, a log cannot get two contradictory checkpoints cosigned by the same honest witness. If clients require a checkpoint to carry cosignatures from a quorum of independent witnesses, a log has to show everyone the same append-only tree, which closes the split-view gap that plain logging leaves open.

Q: How many certificate transparency logs are there in 2026?

The public CT log list we used lists 70 static, tiled logs across a handful of operators, in addition to the remaining classical RFC 6962 logs. Many of the 70 are temporal shards, each covering a range of certificate expiry dates such as the first or second half of a year, so a single operator runs many logs at once. All 70 static logs served a readable checkpoint when we measured them.

Census of 70 static-CT logs: 43% sign with post-quantum ML-DSA-44, 6 witnesses exist, 0 witnesses are post-quantum.

Certificate transparency has quietly started its post-quantum migration, and it is already 43% of the way through at the log signing layer. We fetched the public checkpoint file from every one of the 70 static-CT logs in the public log list, and 30 of them (42.9%) attach a post-quantum ML-DSA-44 signature to every checkpoint, right next to their classical ECDSA signature. That is remarkable, because no comparable surface has moved: DNSSEC is 0% post-quantum and the TLS handshake is only starting. The twist is the other half of the design. The witness layer, the mechanism that is supposed to catch a log lying about its own history, is barely deployed: only 11 of 70 logs carry any witness cosignature at all, we saw just 6 distinct witnesses across the entire ecosystem, and 0 of them are post-quantum. The signing is racing ahead of the watching.

The blunt version The part of certificate transparency that proves a log did not rewrite history is the part that is quantum-vulnerable and thinly deployed. Nearly half of static-CT logs already sign checkpoints with post-quantum ML-DSA-44, but the witness network that detects an equivocating log runs on classical Ed25519, covers one log operator, and has six participants total, four of them staging or proof-of-concept. Post-quantum signing is the easy, visible win. Independent witnessing is the hard, load-bearing one, and it is the one that has not shipped.

What we measured, and why a checkpoint is readable

Certificate transparency is moving off the old RFC 6962 request-response protocol onto the static-ct-api format, where a log is just a set of static files on a CDN. Let's Encrypt shut down its classical logs on 28 February 2026 (their end-of-life plan has the timeline), and the tiled model is now the mainstream. The one small file that summarizes a static log's current state is its checkpoint: the log's name, its tree size, its Merkle root hash, and then a block of signatures. It is public by design, because monitors around the world fetch it constantly to keep the log honest. Reading it touches nothing private and probes no host; it is the same GET a monitor performs, and it is the CT equivalent of reading a public DNS record.

We took the published CT log list, pulled out every tiled log, and fetched each one's checkpoint exactly once. All 70 answered. Then we parsed the signature block. In the signed-note format a checkpoint uses, every signature is its own line: a dash marker, then the signer's name, then a base64 value that is a four-byte key hint followed by the signature itself. That last detail is the whole method: the signature's byte length tells you its algorithm. An Ed25519 signature is 64 bytes. The legacy RFC 6962 tree-head signature is a timestamp plus a short ECDSA blob. And an ML-DSA-44 signature is 2,420 bytes, the fixed size defined by NIST FIPS 204. So we did not have to trust a label; we counted bytes.

Post-quantum is already on 43% of static-CT logs

Here is the whole population, classified by what actually appears in each checkpoint. A single checkpoint usually carries more than one signature line, so these are counts of logs, not of signatures.

Signature layers across all 70 static-CT logs, measured 2026-08-18
What the checkpoint carries	Logs	Share of 70	Algorithm	Quantum-safe
A classical log signature (baseline, every log)	70	100%	ECDSA P-256 / Ed25519	No
An added post-quantum log signature	30	42.9%	ML-DSA-44 (FIPS 204)	Yes
At least one witness cosignature	11	15.7%	Ed25519	No
A GREASE-style decoy signature	46	65.7%	random (ignored)	n/a

The second row is the headline. Thirty logs do not just sign their checkpoint with a classical key; they add a full 2,420-byte ML-DSA-44 signature on top, so every checkpoint is signed both ways. This is exactly what the checkpoint spec asks for. In its own words, logs should use ML-DSA-44 cosignatures to sign the checkpoint, and the cosignature format defines a dedicated post-quantum type, described as secure against quantum computers, sitting right next to the classical one. A 43% adoption rate for a should that most operators could ignore is fast movement. And it is concentrated: the post-quantum signatures cluster in a minority of operators who run large families of temporal-shard logs, so a decision by a few teams already covers nearly half the population. We report the aggregate rather than a name-and-shame list, because signing with more crypto is a good thing, not a finding against anyone.

The reason this layer can move while others cannot is size. An ML-DSA-44 signature is roughly 38 times the size of an ECDSA one, which is why it does not fit in a DNS packet and why the TLS handshake is wary of it. But a checkpoint is a tiny file fetched by a few thousand monitors, not a field sent on billions of handshakes. The transparency layer has the byte budget to go post-quantum first, and it is spending it.

The witness layer is the opposite story

Signing a checkpoint proves the log made a statement. It does not prove the log made the same statement to everyone. A compromised log can mount a split-view attack: show victims a tree that contains a fraudulent certificate, and show monitors a clean tree that does not, so the fraud never lands where anyone is auditing. The fix is witnessing. A witness is an independent service that remembers the last checkpoint it saw from a log, verifies each new one is a consistent, append-only extension, and only then returns a cosignature. Require enough independent witnesses on a checkpoint and a log can no longer keep two histories, because no honest witness will cosign both.

That is the mechanism that turns a log from trust-me into can't-lie. In the live ecosystem, it is thin:

Only 11 of 70 logs (16%) carry any witness cosignature at all, and every one of those logs belongs to a single operator's log family. Every other operator's checkpoints are signed by the log alone, with no independent party attesting to consistency.
Just 6 distinct witnesses appear across the entire ecosystem, and only 2 of them look like production services. The other four identify themselves as staging, dev, or proof-of-concept witnesses.
Every single witness cosignature is classical Ed25519. Not one witness uses the post-quantum ML-DSA-44 cosignature type the same spec defines. The anti-equivocation layer is 0% post-quantum.

Where witnessing does run, it runs well: the cosignatures we saw carried timestamps a median of about 5 seconds behind our fetch, so witnesses are cosigning in near real time. The problem is not latency, it is coverage. A split-view defense that covers one operator and has two production participants is a promising pilot, not yet an ecosystem guarantee.

Two different bets on transparency's future

Put the two layers side by side and a pattern falls out that is more interesting than either number alone. The logs that have gone post-quantum and the logs that carry witness cosignatures are disjoint sets, run by different operators. One camp is spending its effort on post-quantum log signatures and ships no witnessing. The other camp is spending its effort on the witness network and ships no post-quantum signature. Nobody in this census is doing both.

That split is worth naming because the two investments defend against different threats, and the harder threat is losing. Post-quantum signing defends the far-future scenario where a quantum computer forges a log's signature. Witnessing defends the present-tense scenario where a log equivocates today. The ecosystem has collectively front-loaded the speculative threat and under-invested in the concrete one. Post-quantum is the visible, demonstrable upgrade; witnessing requires other people to run infrastructure and clients to demand a quorum, which is organizationally harder. So the easy half shipped first.

The decoy signatures, and why they are a good sign

One incidental finding says something healthy about the ecosystem. On 46 of the 70 logs (66%), the checkpoint carries a signature line under the name grease.invalid, whose bytes are random and verify against nothing. This is not in the specification, so we report it as an observation, not a rule. But it lines up exactly with the documented requirement that a verifier must ignore signatures from keys it does not recognize. That rule is what makes it safe for a log to add witness cosignatures or a new post-quantum key without breaking old clients. Emitting a deliberately invalid signature, in the style of the GREASE technique from TLS, forces every parser to actually honor that must-ignore rule instead of choking on the first unfamiliar line. Two-thirds of logs stress-testing their own consumers is a sign of an ecosystem that expects the signature block to keep growing, which is precisely what a post-quantum transition needs.

How we measured it, so a skeptic can trust the numbers

The dataset is our own, built from public files only, and reported in aggregate. We did not scan, probe, submit to, or connect to any log beyond fetching the single public checkpoint file each one publishes for exactly this purpose. No private data exists in a checkpoint; it is a tree size, a hash, and signatures. We name no operator as deficient, because none is: this is a snapshot of an ecosystem mid-upgrade.

The population. Every tiled log in the public CT log list, 70 in all. All 70 returned a parseable checkpoint on the measurement date. Many are temporal shards, so the log count is larger than the operator count.
The classification. For each signature line we decoded the base64, dropped the four-byte key hint, and read the remaining length. 2,420 bytes (in a timestamped envelope) is an ML-DSA-44 signature by FIPS 204; 64 is Ed25519; the short timestamped blob is the RFC 6962 tree-head signature. Algorithm by construction, not by label.
Log versus witness. A signature whose name matches the log's own origin is the log signing itself. A cosignature under a separate witness identity is an independent attestation. We counted them separately, which is why the post-quantum count and the witness count describe different layers.
Post-quantum by size. The 30 post-quantum logs each carry a signature of exactly the ML-DSA-44 length, in the cosignature envelope the spec defines for it. A classical scheme cannot accidentally produce a 2,420-byte signature, so the count is not an estimate.

Why this matters, and the honest limits

Certificate transparency is a foundation other defenses stand on. It is how the world notices a mis-issued certificate for a bank or a mail provider, and it backs controls like the assurances you can read off a certificate and issuance restrictions such as CAA. Like DNSSEC, CT signs rather than encrypts, so the quantum risk is future forgery, not harvest-now-decrypt-later. That means the 43% post-quantum result is genuinely ahead of the threat, which is good news and rare. But the flip side is the part that should get more attention: the mechanism that makes a log trustworthy against a present-day, non-quantum attacker, independent witnessing, is the one that is thin and classical. If you are betting on transparency to catch the next mis-issuance, the witness network is the number to watch, not the signature algorithm.

A result without its limits is marketing, so here are the boundaries.

One list, one day. This is the public log list on a single date. Shards get added and rotated, and witnessing is being actively deployed, so the exact counts will move. The structural finding, that signing has outrun witnessing, is the durable part.
Served checkpoints only. We read what each log serves at its own checkpoint endpoint. A witness that cosigns a log but distributes its cosignatures elsewhere would not appear here, so the true amount of witnessing activity is a floor, not a ceiling. The point stands that the checkpoints clients actually fetch are mostly un-witnessed.
Presence, not verification. We classified signatures by algorithm and identity, not by cryptographically verifying each one against its key. A present ML-DSA-44 signature of the correct size is strong evidence of post-quantum signing; confirming every signature validates is a separate exercise.
The GREASE line is inferred. The grease.invalid decoy is our reading of an undocumented but consistent behavior, not a spec-mandated feature.

Frequently asked questions

What is a static CT log?

A static CT log is a certificate transparency log served as static files, called tiles, from object storage or a CDN, following the C2SP static-ct-api specification. Rather than the RFC 6962 request-response API, it publishes append-only tiles of 256 entries plus a small signed checkpoint stating the current tree size and root hash. Monitors read the files directly, which makes logs cheap to run and mirror. This design, first called the Sunlight API, became mainstream across CT operators in 2025 and 2026.

Are certificate transparency logs post-quantum yet?

Partly, and sooner than most people assume. In our census of all 70 static-CT logs, 30 of them (43%) already attach an ML-DSA-44 signature to every checkpoint, alongside their classical signature. ML-DSA-44 is the FIPS 204 lattice scheme that resists quantum attacks, and it is what the checkpoint spec recommends. So the log signing layer is well into its post-quantum migration. The witness layer that cosigns those checkpoints is still 0% post-quantum; every witness cosignature we saw was classical Ed25519.

What is ML-DSA-44 and why is it used here?

ML-DSA-44 is the smallest parameter set of ML-DSA, the module-lattice signature standard in NIST FIPS 204, derived from CRYSTALS-Dilithium. Its signatures are 2,420 bytes and its keys 1,312 bytes, far larger than a 64-byte Ed25519 signature, but it is not broken by Shor's algorithm. Certificate transparency can absorb the size because a checkpoint is fetched occasionally by monitors, not sent on every handshake, which is why CT can adopt post-quantum signatures years ahead of DNSSEC or the TLS handshake.

What is a CT witness and a witness cosignature?

A witness is an independent service, identified by a name and a public key, that watches a log's checkpoints. Before it cosigns a new checkpoint it verifies the new tree is consistent with the last one it saw, meaning the log only appended and never rewrote history, then returns a timestamped cosignature defined by the C2SP tlog-witness and tlog-cosignature specs. A checkpoint carrying cosignatures from several independent witnesses is much harder for a compromised log to lie about.

How does a witness cosignature prevent a split view?

A split-view attack is a log showing one tree to victims and a different, honest tree to monitors, so fraudulent certificates never appear where anyone audits. Because a witness only cosigns after checking consistency with the history it already holds, a log cannot get two contradictory checkpoints cosigned by the same honest witness. If clients demand cosignatures from a quorum of independent witnesses, the log must show everyone the same append-only tree, which closes the gap plain logging leaves open.

When did RFC 6962 certificate transparency logs shut down?

The migration ran through 2025 and 2026. Let's Encrypt announced the end of life for its RFC 6962 logs in August 2025, moved them to read-only on 30 November 2025, and fully shut them down on 28 February 2026, in favour of its static Sycamore and Willow logs. Chrome added static-ct-api support in early 2025 and is phasing out the requirement that at least one SCT come from an old RFC 6962 log.

How many certificate transparency logs are there in 2026?

The public CT log list we used contains 70 static, tiled logs across a handful of operators, plus the remaining classical logs. Many of the 70 are temporal shards, each covering a range of certificate expiry dates, so one operator runs several at once. All 70 static logs served a readable checkpoint when we measured them.