notes: research/papers/why-anchored-signatures

This data as json

path title type status classification words body
research/papers/why-anchored-signatures Why Anchored Signatures? summary v0.1 — 2026-10-14: drafted by Claude from the web page (full text); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only partner 518 # Why Anchored Signatures? **Abstract.** A short paper by Daniel Hardman explaining why a bare digital signature is weak evidence once a key may be stolen or rotated, and how anchoring each signing event in a tamper-evident record of key state closes the window for backdated forgeries. It uses KERI key event logs and transaction event logs as the worked solution. For practitioners designing evidence that must survive key rotation. ## Summary The paper starts from the point that a digital signature, by itself, is weaker evidence than it seems. A private key can be stolen and later revoked, but an ordinary signature carries no trustworthy order relative to those events. An attacker holding a stolen key can therefore sign documents dated to any time the key was valid, a retrograde attack, and can keep doing so after revocation. The example follows Alice, whose key is created, stolen a month later and revoked a week after that. Three mitigations are examined and set aside. The first relies on contextual clues that would expose a backdated document; the author finds this unreliable. The second, retroactive revocation, lets Alice declare signatures first seen after a date invalid; the paper argues she cannot reach every relying party, cannot force compliance, and could use the rule to repudiate her own genuine acts. The third accepts that signatures are only checked against current key state, which the paper says is how X.509 with CRL (certificate revocation list) and OCSP (Online Certificate Status Protocol), JWT (JSON Web Token), OAuth2, OIDC (OpenID Connect), SD-JWT and many DID (decentralized identifier) methods behave: rotating a key then invalidates past evidence, and "After-the-fact audits are impossible" (section Mitigation 3). The Solution section introduces anchored signatures: a tamper-evident record showing when each signing event occurred relative to key changes. KERI (Key Event Receipt Infrastructure) does this by anchoring digests of transaction event log (TEL) events in the controller's key event log (KEL). A blockchain or a randomness beacon with timestamped publication can also serve, provided events are linked properly; only the order between each event and key state matters, so no global consensus is needed. The conclusion says that with anchoring "Retrograde attacks become impossible", historical audits become possible and evidence survives rotation, while ephemeral evidence stays acceptable for simple login. ## Key terms retrograde attack, retroactive revocation, ephemeral evidence, anchored signature, key event log (KEL), transaction event log (TEL), key rotation, randomness beacon ## Claims and their evidence - Without anchoring, a stolen key lets an attacker backdate signatures indefinitely [informative] - Retroactive revocation cannot be enforced across all relying parties and enables self-repudiation [informative] - Systems that check signatures only against current key state lose past evidence on rotation (X.509, JWT, OIDC, SD-JWT, many DID methods) [informative] - Anchoring TEL events in a KEL prevents retrograde attacks without total ordering or consensus [informative] ## Related - Why X.509 Certs are Problematic (keri.one title) - Comparing ACDC with SD-JWT (keri.one title) - KERI white paper ## Provenance Drafted by Claude on 2026-10-14 from the web page at dhh1128.github.io, read in full as text. Not yet read by Mark.

Links from other tables