Anchor service keys
The anchor service signs one thing: the receipt for each anchored checkpoint of an IsoKron Evidence Pack. These are the keys it has used. The independent RFC 3161 timestamps on each receipt are signed by Sectigo and DigiCert, not by these keys (see TSA CAs).
Keys
Key chain intact — 1 key(s), each verified back to the pinned genesis key.
| Key ID | Status | Valid (UTC) | Chain check | SHA-256 of public key (SPKI DER) |
|---|---|---|---|---|
| anchor-ed25519-3dca1ecf66c2993e | active | 2026-11-01T02:29:25.705Z → now | genesis key; SHA-256(SPKI) matches the pinned fingerprint; valid_from 2026-11-01T02:29:25.705Z (pinned); current key | 3dca1ecf66c2993e534ff08fe350dc9368ca52042e38b20a9d58cd7c2b7b3367 |
Pinned genesis key: fingerprint 3dca1ecf66c2993e534ff08fe350dc9368ca52042e38b20a9d58cd7c2b7b3367, valid from 2026-11-01T02:29:25.705Z (both compiled in; the listed valid_from of the genesis key is not used). Checked on this page, for the listed keys: exactly one key has no predecessor and its fingerprint equals the pinned genesis fingerprint; every other key has a successor signature by its predecessor, verified back to the genesis; no key has more than one successor; each predecessor ended (valid_to) no later than its successor's valid_from; a retired key's status is signed by its successor; a revoked key's revocation statement is signed by the key itself or an earlier key; keys after a revoked key are not trusted; the newest key is active or revoked. Machine-readable: /.well-known/anchor-keys.json.
Custody
Each key is an Ed25519 key generated on IsoKron's operator workstation (scripts/keygen.mjs), never on shared infrastructure and never in a source repository. The private key is installed only as an encrypted Cloudflare Worker secret; two passphrase-encrypted offline copies are kept on separate media in separate locations. The service reads it from the ANCHOR_SERVICE_KEY Worker secret; it is not stored in D1 or in R2. The key ID is derived from the public key: anchor-ed25519- + the first 16 hex characters of SHA-256(SPKI DER).
Rotation
The keys form one linear chain. A new key is published with a successor_signature (the previous key's Ed25519 signature over the canonical JSON {"key_id","public_key_pem","valid_from"} of the new key) and signed_by naming the previous key. The previous key is then listed as retired, with a valid_to no later than the new key's valid_from, and a retirement_signature over {"key_id","status","valid_to"} made by the new key, so the old key alone cannot change its own status. Receipts issued under a retired key verify only inside its window. Because a receipt's received_at is signed by its own key, the command-line client accepts a retired key's receipt only as the exact receipt it verified itself while that key was current, and this verification page weighs the receipt's RFC 3161 timestamps. The genesis fingerprint is compiled into this service, the verification page and the client; it is not taken from the published list.
Revocation
A key is revoked by listing it with status: "revoked", a valid_to, a compromised_since time, and a revocation statement (retirement_signature over {"key_id","status","valid_to","compromised_since"}) signed by the key itself or an earlier key on its chain, never by a later key.
From compromised_since on, the key must be treated as held by someone else, who can sign a receipt with any received_at. A receipt signed by a revoked key therefore counts on the verification page only when a third-party RFC 3161 timestamp (Sectigo or DigiCert) over that receipt is earlier than compromised_since minus 5 minutes; without one it is shown as INVALID. The command-line client does not check RFC 3161 tokens and rejects every receipt signed by a revoked key, referring to this verification page: the receipt's own received_at is signed by the revoked key and can be backdated by whoever holds it.
Receipts of keys before the revoked key are not affected. Keys after it are shown as NOT TRUSTED: the revoked key signed their successor statements, and nothing shows those were signed before compromised_since. Service resumes under a new genesis key pinned in a new release of the service, the verification page and the client. Independently of revocation, a timestamp issued after the signing key's valid_to is rejected.
Check a key yourself
curl -s https://anchor.isokron.ai/.well-known/anchor-keys.json | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{for(const k of JSON.parse(s).keys)process.stdout.write(k.public_key_pem)})'
# save one of the printed PEM blocks as key.pem, then: SHA-256 of its SPKI DER
# (compare with the table above and with the anchor-keys.json in your Evidence Pack)
openssl pkey -pubin -in key.pem -outform DER | shasum -a 256
anchor.isokron.ai · verification page · anchor-keys.json · TSA CAs