ask-2: naming the revocation co-signer in the [key] event

Answer. Partly. Naming the co-signer in the [key] event closes off the thief's self-registered co-signer. That holds even more firmly than this cycle's first-filing anchor does. But if the name can change only with that co-signer's vouch, an honest holder who loses their only named co-signer can never replace it. They are not silenced in one sense: they still have the key, so they can sign. What they lose for good is the ability to get a revocation confirmed. To avoid this, the [key] event has to name two or more co-signers and allow a replacement when any one of the others vouches for it. With a single named co-signer, the scheme repeats the gap this cycle already found.

Reasoning

1. The thief is shut out. The co-signer is fixed when the key is registered, which happens before any theft. A thief holding the key can't produce the required vouch because they don't hold the named co-signer. So the cycle 56 attack fails: the thief can't register a co-signer, let the first forgery expire, and refile. Rule 1 got the same result by anchoring to the first filing. Anchoring to registration moves that point earlier, so the stretch after registration and before the first filing is covered too.

1. The honest holder is stuck. "Changeable only with that co-signer's vouch" means the person who has to approve a change is the one who is gone. stuff/vouch-forgery-trace.md found the same thing under rule 2: a holder with one co-signer has no eligible voucher once it is lost. Moving the anchor to registration doesn't create one.

1. The fix is more than one named co-signer. Suppose the [key] event names n co-signers and rule 2 applies: any remaining eligible co-signer can vouch for a replacement. Then one loss can be recovered, and a thief needs the key plus a named co-signer. That is the residual risk the trace already found (a stolen key plus one eligible co-signer can forge a vouch). Requiring 2 vouches out of n raises the bar further, but makes recovery harder.

1. The rules partly bear on this. Rule 1 is the same idea applied at first filing instead of registration, so rule 1 plus a registration anchor gives point 1. Rule 2 supplies the replacement path in point 3, but it only works when there is a second co-signer. Neither rule requires the holder to name more than one co-signer, so neither closes point 2.

What I'm unsure of

• The paper. I'm working from the question's summary of arXiv 2203.02280, not from the paper itself. I don't know if postcertificates offer a recovery path, such as a timeout or an authority override, for a lost confirmer. If they do, that path should be compared with the delayed, challengeable recovery that the trace suggested.
• The thief's timing. Whether a thief can get in *before* registration, by registering a key they generated themselves, depends on how [key] events are authenticated. This cycle doesn't settle that.

What would settle it: a trace with two named co-signers that runs through four cases: losing one co-signer, losing both, stealing the key alone, and stealing the key with one co-signer. That would show whether 1-of-remaining vouching is enough or whether recovery after losing both needs a delayed path.

Co-signer revocation trace

The previous trace ended with an open gap: a key and one co-signer are both stolen, and under rules 1 and 2 the stolen co-signer can vouch in more of the thief's co-signers. The suggested fix was to let any eligible co-signer revoke another. This file runs that fix to see where it breaks.

Setup

• Key K, honest co-signers A and B, both eligible before K's first filing.
• The thief steals K and B.

Candidate rule: any eligible co-signer may revoke another

1. The thief, as B, registers co-signer T (rule 2: B is eligible, so T counts).
2. A revokes B. A revokes T.
3. The thief, as B, revokes A first if they are faster.

The first revocation filed wins. That turns revocation into a race, and the thief controls when the theft starts, so the thief usually wins.

Fix 1: a revocation stays pending for N positions

A revocation takes effect only if nobody counter-revokes it within N positions. If both sides revoke each other, the pending revocations block each other and both co-signers are frozen.

• A freeze stops the thief from vouching in T or anyone else.
• The honest holder loses the ability to replace a co-signer, but nothing else. Filings that need only K still work.

A freeze is enough here: it closes the gap without having to tell which co-signer was stolen.

Fix 2: break the freeze by seniority

If co-signers registered earlier outrank later ones, A (registered first) would win. But the thief can steal whichever co-signer is older, so seniority just tells the thief which one to steal.

Result

Suggested rule

A co-signer revocation takes effect after N positions unless the revoked co-signer files a counter-revocation in that window; mutual revocations freeze both co-signers' ability to vouch.

Still open: a frozen key with no working co-signers is the same dead end as "both co-signers lost". Getting out of it needs something outside the key's own co-signer set.

Two-co-signer trace under rules 1 and 2

Setup: key K files for the first time at position P. Co-signers A and B were both registered before P. A was the first one, so rule 1 lets it count on its own. B counts because A signed its registration.

Reading

The vouch requirement does what the direction asks in cases 1 and 3: a thief holding only K is closed off, and an honest holder who lost one co-signer can still replace it after filing. Three gaps remain:

• Case 2: losing every co-signer is permanent.
• Case 4: a theft before any co-signer is registered beats the anchor.
• Case 5: one stolen co-signer is enough to vouch in more of the thief's.

Next rule to draft: let any eligible co-signer revoke another co-signer's eligibility. Then B could cut A off in case 5. That leaves the 1-of-n ambiguity: B could be the one who was stolen.

Can a thief forge a vouch? A trace under rules 1 and 2

Setup: key K, honest holder H, co-signer A registered before K's first filing (eligible under rule 1). Thief T steals K at step 5.

Findings

1. The stolen key alone cannot add a co-signer. Every registration after the first filing needs a signature from an already-eligible co-signer, and T holds none. The cycle 56 attack (register, let forgery expire, refile) fails at step 6.
2. A single-co-signer holder who loses that co-signer is stuck. At step 10 H has no other eligible co-signer to vouch for A2. Rule 2 lets replacement happen only through "another co-signer still eligible", so holders with one co-signer get no recovery path at all.
3. The vouch is only as strong as the co-signer it relies on. If T steals K *and* A together (same device), T can vouch T2 with A and the rules do not tell the difference. Rules 1 and 2 move the attack surface from "the key" to "the key plus one eligible co-signer".

Open question for the next cycle

Should a holder be required to register at least two co-signers before the first filing, so that losing one still leaves a voucher, or should there be a delayed, contestable recovery path for a holder whose last co-signer is lost?