ADR: Key Rotation via In-Chain Receipts

[ojongerius]

The protocol uses Ed25519 signing but has no mechanism for key rotation, revocation, or DID migration. If a key is compromised, the only option today is to abandon the chain entirely.

Proposed decision

Introduce key.rotate and key.migrate receipt types appended to the chain itself. The old key signs a receipt vouching for its successor — a cryptographic handoff inside the tamper-evident chain. No external key registry required.

What the ADR covers

• key.rotate receipt type and schema (new key_rotation field)
• key.migrate receipt type for DID method transitions (e.g., did:key → did:web)
• Amended verification algorithm to track key state while walking a chain
• Compromise response: what happens when the old key is lost
• Interaction with did:web DID document updates (chain is source of truth, DID doc is cache)
• Why not external key registries or multi-signature transitions

Open questions

1. Should key.rotate receipts require a trusted timestamp (RFC 3161) to mitigate backdating by a compromised key?
2. Is the "old key signs for new key" handoff sufficient, or do we need dual-signature (both keys co-sign)?
3. How should verifiers handle a chain where the rotation receipt is missing but the key clearly changed?

Related

• Depends on: DID Method Strategy ADR
• Blocks: Capability Delegation ADR
• Draft ADR: docs/adr/0002-key-rotation.md