One verifier reads three logs

A transparency log publishes a checkpoint: a short signed note that states how many leaves the log holds and which Merkle tree root they commit to.

The C2SP signed-note format defines the framing: an origin line, a size, a root hash, optional extra lines, then one or more signature lines, each starting with an em dash and a key name. Everything below the root is framing; the promise is the root.

origin.example.org
1462
a3f9c1e25b7d0846ac9e2f1d3b5a7c9e0f2b4d6f8c1a3e5b7d9f0a2c4e6b8d0f
— origin.example.org bb19f0…

The bytes above are illustrative and visibly truncated. Verifying the promise takes three things: the note is parsed correctly, the signature is checked against a key you already trust, and the root is the one your leaf really hashes to.

Here is a checkpoint from my log. Tell me what it claims and which bytes the signature covers.

This estate read Sigsum records and Rekor records through two checkpoint parsers written independently, and the copies drifted. The drift produced a real bug.

The recorded bug: one path read a witness cosignature key id from a parallel field that does not exist in the note format, instead of from the signature line itself. Verification kept running and every witness match silently read zero out of N, even against valid cosignatures. Nothing crashed; the answer was just quietly wrong.

Do both record verifiers parse the checkpoint signature line the same way? Show me where they differ.

The fix ends the pattern: one verifier written directly to the C2SP transparency-log spec family, with the trust policy as data.

The verifier takes every byte and every trust key as arguments and makes zero network calls; keys are pinned in a tlog-policy file, never fetched at verify time. That is what stops a compromised log directory from swapping the trust anchor under an old record. What stays per log, by design, is everything C2SP does not standardize: each log's leaf serialization and its submission path. Verification is the common ground; writing it once is the fix.

Verify this checkpoint against this tlog-policy text. Use only the bytes I pasted.

The transparency-log ecosystem runs on a small set of shared specifications, and the C2SP family is the layer the newest logs converged on.

Certificate Transparency seeded the design; RFC 6962 and RFC 9162 pinned its tree math. Sigsum stripped the idea to a minimal log, Google's Tessera succeeded Trillian, and Sigstore's Rekor v2 rebuilt on tiled logs. Sigsum's checkpoints already are C2SP signed notes, and Tessera and Rekor v2 both build on C2SP tlog-tiles, so one spec-conformant verifier reads all three.

My log publishes Tessera tiles and a Sigsum-style checkpoint. Which specs in the family does it speak?

The estate runs its own transparency anchoring on Sigsum, and the single code path from step 3 is what reads its checkpoints.

What the estate does today: Sigsum checkpoints for anchored records are verified by the single C2SP code path described on this page, and tool T625 is that code path running offline in a browser. The page's working claim: T625 verifies Sigsum, Rekor v2 and Tessera checkpoints, because all three publish in the C2SP family. What could plug in later: the same verifier reading tiled proofs from a log this estate does not anchor to yet.

Try the one verifier: tool 625, the C2SP transparency-log verifier

Take this checkpoint from anchor.ainumbers.co and verify it offline in tool T625.