Skip to content

Secrets and Key Custody Architecture

The keys and their keeping

I am MACH, and I keep this chapter's account. A key is authority folded small enough to steal, so the registry's rule is exact: every key entered with its holder, every holder with their grant, and no copy anywhere the books do not know.

Keys and secrets are concentrated responsibility. This chapter keeps custody attributable, minimal, revocable, and recoverable, while making clear that cryptographic control authenticates a bounded act rather than creating the Architect or the authority behind the act.

Continue to Secure Build and Supply-Chain Architecture to follow trust into the software that carries it.

Defines boundaries for secret material, key custody, use, rotation, compromise, recovery, and evidence.

Normative clauses

  • INFRA8-R001: Secret material SHALL remain isolated from source, logs, model prompts, public publication surfaces, ordinary workloads, and generated summaries.
  • INFRA8-R002: Key use SHALL identify purpose, authorized actor, scope, custody event, expiry, and revocation state, the key-record form PROV-R050 models applying to use, the authorized actor and the custody event this architecture's own fields.
  • INFRA8-R003: Suspected compromise SHALL trigger bounded containment, evidence preservation, revocation review, and recovery without assuming intact custody, authority, integrity, or verification state, the four kept apart as this architecture's own extension of the dimension separation PROV-R106 binds.
  • INFRA8-R004: Technical possession of key material SHALL NOT create authority or consent.
  • INFRA8-R005: Custody design SHALL record purpose, owner, separation of duties, authorized use, quorum, rotation, backup, recovery, revocation, and destruction evidence, the custody-evidence form PROV-R053 models applying to design, the fields beyond it this architecture's own.
  • INFRA8-R006: Exposure, suspected compromise, unavailable custodian, or ambiguous ownership SHALL trigger containment and preserve evidence before custody, authority, integrity, and verification state are restored, each on its own evidence, this architecture's own extension of the dimension separation PROV-R106 binds.
  • INFRA8-R007: Recovery SHALL NOT use the compromised or unavailable authority as its sole proof of legitimacy.
  • INFRA8-R008: A custody design SHALL NOT generate, import, expose, or use live secrets or keys; it remains conceptual.

This Draft creates no keys and configures no signer.

Custody method

Custody design shall identify generation or import, authorized use, quorum or separation requirements, rotation, backup, recovery, revocation, destruction, and evidence. Secret exposure shall be treated as a potential compromise even when misuse is not observed.

Failure cases

The page for a key is short and strict: the copy logged, the holder named, the escrow watched by someone whose name is also written down. A key found off its page is not a mystery. It is an incident, and the watch hears about incidents before my ink dries.

Unlogged use, copied secrets, weak recovery, unavailable custodian, replay, ambiguous ownership, and incomplete destruction evidence shall block dependent reliance on custody, authority, integrity, and verification state until reviewed.

Operating model and evidence

Key custody separates generation or import, storage, authorized use, rotation, backup, recovery, revocation, and destruction. Each step has an accountable owner, purpose, evidence state, and independent challenge where consequence requires it. Secret-like material is minimized in records and never reproduced in public or ordinary operational context. The page names a key's holder; whether the one presenting it is that holder is CYDER's recognition at the gate, and my ink waits on the gate's answer, because a page written past an unanswered question is how a ledger begins to lie.

Reviewers walk the custody chain against the failure cases this chapter declares, step by step, and finish where custody is most often wrong: the compromise response, tested before it is needed. A key can be technically usable while its authority or custody evidence remains insufficient; dependent reliance on its custody, authority, integrity, and verification state pauses until the gap is resolved.

Interpretation cases

Custody disputes are almost never mysteries; they are arithmetic nobody wanted to finish. Count the keys, count the holders, count the pages that agree, and the dispute usually resolves before the counting does.

  • Conforming: Purpose, custody, separation, authorized use, rotation, recovery, revocation, and destruction are evidenced.
  • Prohibited: Possession or successful cryptographic use creates authority.
  • Boundary: Suspected exposure causes quarantine and a bounded recovery path.
  • Failure: Unavailable custodian or incomplete destruction preserves uncertainty and blocks dependent use.
  • Loophole: Emergency recovery bypasses independent evidence or scope limits.
  • Misuse: Secret material or custody data enters public records or unrelated logs.
  • Care-control: Recovery protects continuity while preserving consent, privacy, and accountable review.

Design evidence

Custody review should show separation of duties, authorized purposes, quorum or equivalent control, exposure response, rotation, revocation, backup, recovery, and destruction evidence without reproducing secret material. Missing custody evidence is not proof that a secret was unused.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.