Files
alknet/docs/architecture/questions/022-key-rotation-mechanism.md
T
glm-5.2 1baa619ce9 docs(arch): decompose open-questions.md into per-OQ files under questions/
The monolithic open-questions.md (1310 lines, 47 OQs) was large enough to be
unmanageable, with high size variance (OQ-42 at 220 lines next to OQ-06 at 8).
Decomposed into one file per OQ under docs/architecture/questions/ (NNN-slug.md,
mirroring the ADR convention), with open-questions.md retained as the index:
theme-grouped tables plus a cross-theme Deferred/Blocked section that surfaces
the 6 deferred OQs with their Blocked-on conditions inline (the safe-exit
visibility surface). Per-OQ content moved verbatim; all 62 inbound links stay
valid (none used anchors). README's curated OQ summary dropped (now redundant
with the index tables).

Also seeds tasks/architecture/ with this task plus two follow-ups found during
the decompose: OQ-09/10 missing structured Blocked-on fields, and the
tasks/architecture/ blocker-task half of the Safe Exit protocol being
unenforced.
2026-07-06 16:07:59 +00:00

985 B

OQ-22: Key Rotation Mechanism

  • Origin: encryption.md
  • Status: resolved
  • Door type: One-way (path scheme), two-way (rotation policy)
  • Priority: medium
  • Resolution: Key rotation uses version-indexed derivation paths. Each key version maps to a distinct SLIP-0010 path: m/74'/2'/0'/{version-2}'. v2 (current) is at m/74'/2'/0'/0'; v3 is at m/74'/2'/0'/1'; etc. The decrypt method derives the key at the path indicated by encrypted.key_version (not always at PATHS::ENCRYPTION). The rotate method decrypts with the old version's key and re-encrypts with the new version's key — no new mnemonic needed. The assembly layer or a migration tool iterates stored blobs and calls rotate on each; the vault does not self-rotate. Partial rotation is safe (old keys remain derivable). See ADR-021.
  • Cross-references: ADR-020, ADR-021, encryption.md, service.md