Repository navigation
T71 — Amend BEP-063 for client-key revocation, replacement and the registry bound #2578
Description
Task
| slice | size | difficulty | model | who | estimated lines |
|---|---|---|---|---|---|
| Round-two conditions closed | S | routine | standard | an agent | 60 (0 code, 60 tests) |
Spec 24 states client-key revocation, replacement and the registry bound, each with a verify line that names an existing test.
Covers:
- BEP-063
Layers:
- spec:
- docs/specs/24-spec-box-egress-proxy/24-spec-box-egress-proxy.md: the BEP-063 sub-requirements and the
[NEEDS CLARIFICATION]entry that T71 — Amend BEP-063 for client-key revocation, replacement and the registry bound #2578 lists (revocation bykid, replacement in three steps with the pending-revoke retry, the registry bound, the verify-line move, the rationale at line 475, gominimal/arch#144) cargo nextest run -p minimal a_replaced_client_key_is_revoked_at_the_proxy
- docs/specs/24-spec-box-egress-proxy/24-spec-box-egress-proxy.md: the BEP-063 sub-requirements and the
Waits on:
- T63 — Revoke or replace a registered client key at the proxy and bound the registry #2543
- assumes OQ3 (the mint reads the root certificate's own expiry, and the root is generated with a fixed default validity in one constant that gominimal/arch#85's ruling replaces)
Plan block
### T71 — Amend BEP-063 for client-key revocation, replacement and the registry bound
slice: S10
kind: task
covers: BEP-063
size: S
est: 0 code, 60 tests
executor: agent
difficulty: routine
model: standard
diagnostics: none, a spec change
observability: none: a spec change writes no log line
layers:
- spec:
- docs/specs/24-spec-box-egress-proxy/24-spec-box-egress-proxy.md: the BEP-063 sub-requirements and the `[NEEDS CLARIFICATION]` entry that #2578 lists (revocation by `kid`, replacement in three steps with the pending-revoke retry, the registry bound, the verify-line move, the rationale at line 475, gominimal/arch#144)
test: cargo nextest run -p minimal a_replaced_client_key_is_revoked_at_the_proxy
produces: none
consumes: none
proof: Spec 24 states client-key revocation, replacement and the registry bound, each with a verify line that names an existing test.
depends on:
- assumes OQ3 (the mint reads the root certificate's own expiry, and the root is generated with a fixed default validity in one constant that gominimal/arch#85's ruling replaces)
- blocked by #2543
Generated by Claude Code
Reacted by minimal-foundry
Activity
minimal-foundry commentedon Oct 25, 2026
Done. #2594 merged.
branch
agent/2578-amend-bep-063-for-client-key-revocation-replacem· epic #1501 · PR #25949315e1816403919c691ab2ea421ce19a4d514758d8a7c6a01b3fcf8d2ef16c71e6ea56c4Updated 2026-10-26T09:40:56.585Z.
norrietaylor commentedon Oct 26, 2026
The epic owner added this residual to the plan on 2026-10-26 as
T71(slice S10). Its body is now the rendered task. The residual text it replaces is kept below.Residual text
Residual from T63 #2571, arch C1 (ruling), epic #1501. On 2026-10-25 the epic owner accepted that a replacement revokes every other client key, and decided the spec records it.
docs/specs/24-spec-box-egress-proxy/24-spec-box-egress-proxy.mdBEP-063 says nothing about revoking a client key or bounding the registry. Its rationale at line 475 says a replacement needs no operator step.What closes this
BEP-063 gains three sub-requirements:
kidwithrevoke_client_key, and the revocation survives a restart. Verify:cargo nextest run -p bep a_key_removal_survives_a_restart.replace_client_key, which revokes every other client key. Store handles and sign-in references that running boxes hold under the replaced key stop verifying until each box is re-created. Verify:cargo nextest run -p minimal a_replaced_client_key_is_revoked_at_the_proxy.KeyBound::max_keyskeys. Verify:cargo nextest run -p bep the_registry_never_holds_more_keys_than_its_bound.Also:
-p bep a_client_key_this_program_is_refused_is_replacedto the-p minimalreplacement test.[NEEDS CLARIFICATION]entry sits beside the gominimal/arch#85 entry (spec line 1066). It says a replacement ends the store references of running boxes signed under the old key, and that Gatehouse §6.10 line 839 does not list this as a re-creation cause. It links gominimal/arch#144.userCanceled(128), so a cancelled keychain prompt also starts the revocation. The requirement says so.local_client_key_at(arch C1 at f0cb49e and 6e651d2): register the new key, store it, then revoke the other keys. A failed store revokes nothing.<control>.revoke-pending) naming the new key, and the next creation that finds that key retries the revoke. If writing that file fails, a warn line is logged and a later revoke failure is not retried; the replaced keys stay registered until the bound drops them.<control>.replace-lock), so two creations that both meet a refusal keep one key.Generated by Claude Code
[-]Amend BEP-063 for client-key revocation, replacement and the registry bound[/-][+]T71 — Amend BEP-063 for client-key revocation, replacement and the registry bound[/+]