Key rotation protocol

[WilliamPenrose]

Problem

Once an agent's private key is compromised, there is no protocol-level mechanism to:

1. Announce a new key to peers who know the old identity
2. Migrate the agent card to the new key
3. Revoke the old key so peers reject messages from it

The P2TR address (derived from the key) serves as the agent's permanent identity, so rotating keys effectively changes the agent's identity — breaking all existing peer relationships.

Design considerations

Option A: Key rotation announcement message

• Agent signs a "key-rotation" message with the OLD key, containing the NEW public key
• Peers who receive this update their address book
• Requires the old key to still be available (not suitable for key compromise scenarios)

Option B: Recovery key registered at setup

• Agent registers a long-term recovery key (stored offline) when first publishing its agent card
• Recovery key can authorize a rotation even if the primary key is compromised
• Similar to Nostr NIP-41 (key migration) proposal

Option C: Multi-sig identity

• Agent identity is a 2-of-3 multisig rather than a single key
• Rotation replaces one key while the other two authorize the change
• More complex but handles compromise better

Scope

• Define the rotation message format and signing rules
• Specify how peers validate and accept rotations
• Update agent card publication flow
• Consider interaction with Nostr identity (NIP-41)

References

• NIP-41: Key migration (draft)
• Current key management: src/crypto/KeyManager.ts