Signed Ledger Checkpoints: Verify Exact Bytes, Key Authority and Retained Evidence Separately

A valid signature answers a narrow question: do these bytes verify under this public key? It does not establish that the key was authorized for this ledger, that the checkpoint matches an independently retained copy, or that its signed ledger history is financially correct.

You will build a verifier that keeps those questions visible. It authenticates exact checkpoint bytes, evaluates a supplied current key policy and compares the entire payload with independent expected evidence. You will also re-sign an edited checkpoint and see the signature turn valid while retained correspondence still fails.

The Cedar ledger and trust receipts are synthetic. The signing seeds used here are published RFC test fixtures and are public to everyone. They are never production credentials.

Start with the checkpoint, not a green badge

Hash-Chained Journal and Merkle-Batched Journal Commitment establish content commitments. This topic adds signer authentication and explicit authority policy. It does not rerun those history checks inside the signature function.

The checkpoint has eleven exact fields: version, checkpoint ID, stream, ledger, entity, creation claim, ending journal sequence, group count, chain head, Merkle root and Merkle size. The shared Cedar vector describes three complete groups containing four journals. Its correction group contains two journals, so group count and sequence are different quantities.

{
  "schema_version": "d30-integrity-checkpoint-v1",
  "checkpoint_id": "CHECKPOINT-4",
  "stream_id": "CB-GENERAL-EXPORT-V1",
  "ledger_id": "CB-GENERAL",
  "entity_id": "CB-A",
  "created_at": "2026-10-24T12:00:00.000Z",
  "through_sequence": "4",
  "group_count": "3",
  "chain_head": "8af37be6b7835169129ae57b561d98c0fe36e231921c76029f5aff8c9540beea",
  "merkle_root": "34ad17bffd657e7227adb7083eb1be5d0a7f9bcd5ba6b404313dce2242393192",
  "merkle_size": "3"
}

These fields are bounded and structurally checked. Counts are canonical decimal strings, hashes are lowercase 64-character hex and clocks are real Gregorian UTC milliseconds. Unknown fields reject, so an unsigned trust label cannot quietly accompany the payload. The source adapter must separately establish that the claimed sequence ends a complete prefix and that group receipts precede checkpoint creation.

Freeze the bytes before signing

Our authored framing uses a four-byte unsigned big-endian length U(n). A string S(t) contains U(number of UTF-8 octets), followed by those exact octets. The checkpoint byte string C begins with the ASCII tag D30-INTEGRITY-CHECKPOINT-V1 and one zero octet, then S of each field in its frozen order.

This is a versioned D30 encoding, not canonical JSON or a Certificate Transparency protocol implementation. JSON property delivery order does not matter. No pretty-printing, locale, trimming or Unicode normalization chooses the bytes. Checkpoint IDs are restricted to the shared ASCII profile; the shared framing vectors separately exercise multi-byte strings and normalization differences.

Pure Ed25519 signs C itself. Passing SHA256(C) as the message would sign a different message. Ed25519ctx and Ed25519ph are also different variants and are outside this envelope. RFC 8032 defines the primitive and supplies the published vectors used in the tests. RFC 8032.

Open the full-size signed-byte and envelope figure.

The envelope E frames its schema, key ID, algorithm, C's length and bytes, and the lowercase signature hex. Ed25519's 64 signature bytes become 128 hex characters in this wire. The independent vector has C length 300 and E length 524 bytes.

The anchor content digest is:

SHA256(E) =
8c3d6bb3a098a957a5b555064cda453528aff09995a63a944fd902076f523972

Changing the key label changes E even if C and its signature remain identical. Hashing C alone, pretty JSON, a bare chain digest or a storage ETag cannot be substituted for this envelope digest. Whether an external service actually retained E is another check in External WORM/Blockchain Anchor.

Use a strict, declared Ed25519 profile

Calling an API named Ed25519 is not a complete validation policy. During this package's investigation, the installed cryptography 40.0.2/OpenSSL, Node/OpenSSL and Chromium WebCrypto backends all accepted an identity-public-key forgery in isolation. The W3C draft documents that implementations differ on small-order checks. This concrete test prompted an additional vetted validation layer; it is not a claim that every Ed25519 implementation behaves identically. W3C Web Cryptography Level 2, section 25.

The executable strict-main-subgroup-ed25519-v1 profile requires canonical nonidentity main-subgroup public key A and signature point R. Python uses pinned PyNaCl 1.6.2's patched libsodium point validator, then detached signature verification. TypeScript uses pinned noble-curves 2.4.0 strict point parsing, subgroup and small-order checks, strict zip215: false verification, and actual WebCrypto verification of C. We write no curve arithmetic or homemade small-order blocklist.

The dependency versions matter. PyNaCl 1.6.2 bundles the stable libsodium build that fixes the earlier mixed-order point-validation issue. An unpatched library with a similar version number is not equivalent. The official release and maintainer's explanation establish the patch provenance. PyNaCl release, libsodium maintainer explanation. The TypeScript profile uses the pinned library's public validation methods and current release. noble-curves 2.4.0.

This stronger profile rejects identity, small-order, mixed-order and noncanonical A/R encodings, and invalid scalar/equation cases. It supports general ordinary public keys, including a tested third generated key; verification is not limited to the two RFC demo keys. Missing required cryptography remains indeterminate, and TypeScript cannot silently pass using a weaker or absent WebCrypto backend.

Separate signature mathematics from current authority

The logical API takes three data inputs:

result = verify_signed_checkpoint(request, envelope, trust_registry)

const result = await verifySignedCheckpoint(request, envelope, trustRegistry);

The request pins stream, ledger, entity, verification time, current-policy profile and an independently expected checkpoint. The trusted registry supplies scoped key IDs, raw public keys, validity intervals, revocation times and its observation receipt. A public key embedded in the submitted envelope is rejected as an unknown field.

Registry trust comes from the host's independent enrollment and policy channel. A caller cannot create that trust merely by supplying strings such as “authorized key” or “independent receipt.” The API checks consistent supplied facts; it does not provision a trust store or authenticate its transport.

This tutorial chooses a conservative current-trust-at-verification policy. The selected key must be authorized at both the requested verification time and the checkpoint's claimed created_at. The interval includes valid_from and excludes valid_until. A revocation at verification equality denies; a future revocation does not apply early. The supplied registry must cover the requested policy observation.

A retired or revoked key can therefore fail current policy even if it might have legitimately signed an older checkpoint. The authority failure is distinct from an invalid mathematical signature. The signed created_at remains the signer's assertion. It cannot independently prove when signing occurred or reconstruct historical revocation knowledge.

Open the full-size layered-evidence figure.

Keep missing evidence different from failed evidence

The complete result preserves three named checks, each with its own status and code:

A verifiable invalid signature remains a failure even if another layer is missing. A valid signature with no expected copy remains overall indeterminate for retained correspondence. All three passes yield TRUSTED_CHECKPOINT_BOUND: exact signed payload authentication under the supplied trusted key policy plus expected-payload equality. The code name does not mean full ledger verification.

Structural failures return no partially validated checkpoint or framing. Otherwise, the result includes exact C and E hex and SHA256(E), plus detached checkpoint/key views. The full data contract specifies every field, boundary and deterministic precedence. The shared byte contract defines the cross-topic C/E wire.

Re-sign a rewrite and watch binding fail

Start with the independent Cedar fixture: signature passes, authority passes and retained binding passes. Change the signed chain head to another well-formed digest while keeping the original signature. Signature and expected binding fail.

Now use the public demo seed to re-sign the changed C. Signature mathematics passes again; retained binding still fails because the independent expected checkpoint was preserved. This is the distinction a one-badge demo would hide. A malicious authorized signer can generate a new valid signature over changed history. Independent retention or another separately trusted observation is needed to expose that disagreement.

Open the guided signed-checkpoint lab. It retains all eleven fields and all three checks across twelve scenario families. Change any signed field, inspect a known revoked key, remove expected evidence, rotate to an authorized key or simulate unavailable WebCrypto. Step changes the inspected layer, not which evidence the verifier evaluates. The re-sign button calls actual WebCrypto with a public fixture seed.

Reproduce the evidence, including the dependencies

The package includes pinned installation and bundle instructions, Python requirements, npm lock, observed artifact hashes and upstream licenses. The standalone lab embeds the actual TypeScript/noble bundle and requires no CDN. The repository's task-local installation preserves global and project manifests; a separately downloaded module can use its own environment with the same declared dependencies.

There are 88 independently authored complete expected outputs. The first 71 preceded code; 17 later independent regressions add scalar boundaries, mixed-order R, a general generated key and strict clock/wire edges. Python and TypeScript agree on all output branches, errors, source scope, key views, layer conclusions and full framing. Root-built C/E vectors match byte for byte. Published RFC 8032 tests verify raw signing and verification separately from our authored framing.

The actual browser also executed all 88 full fixtures and both RFC vectors. Guided checks covered 108 layer observations and 30 signed-field mutations at 390, 768 and 1440 pixels, including actual re-signing, async cancellation, controls, reset, keyboard, reduced motion and touch targets. All 66 available-backend captured lab outputs match Python; three additional captures deliberately simulate missing WebCrypto and stay indeterminate. Validation record and commands.

Carry the conclusion into the next layer

A signed checkpoint can authenticate false accounting, an incomplete source prefix or an internally consistent rewrite if the surrounding independent evidence is wrong or absent. This verifier does not claim otherwise. Keep the chain, Merkle, coverage, accounting, key authority, retained payload and external-anchor results separate when building End-to-End Ledger Integrity Verification.

References and provenance

The primary source roles distinguish RFC primitive definitions, draft WebCrypto APIs, patched library behavior and authored D30 policy. Historical deployment evidence is not useful for this executable example without independently retained bytes and key-policy history. RFC vectors are cryptographic test fixtures; Cedar is synthetic. No production keys, external writes, independent timestamp or encoded/published video are created by this package.