Identity and PKI

Cryptographic inventory

The accepted algorithm set is closed, and the algorithm name is part of the signed material — so a signature produced under one algorithm cannot be reinterpreted under another. On the instruction path Ed25519 is hard-pinned and an HMAC envelope is refused before any key material is touched; the consequence is that a local process holding the shared workspace HMAC key cannot mint standing law or an instruction, even though it can sign records. Version changes are explicit refusals of the unknown version, never a guess.

The trust root is born on paper

The owner root is an Ed25519 key pair created in a ceremony, whose purpose is to produce a root whose private half exists only on paper.

1. The engine generates the key pair using the platform CSPRNG.
2. It renders the private half as a numbered word list over a 2,048-word dictionary embedded in the binary, eleven bits per word. No printer driver, no external tool, no clipboard, no shell-out to any crypto utility.
3. It requires proof of capture: a witness reads the words back from the paper and the engine compares them position by position.
4. Only on an exact match does it erase the private key, its public counterpart and the word list from disk.

A mismatch erases nothing and refuses by name, reporting word counts and positions only, never a word value — so the failure message is safe to paste into a ticket. A scripted read-back pointing the engine at its own word-list file is refused as self-referential.

Root creation uses an exclusive-create file operation and refuses to overwrite an existing root, because re-minting would silently invalidate every prior signature.

After the ceremony, compromising the control plane does not compromise the root, because the root is not on it.

Intermediate authority

The root certifies a P-256 intermediate CA, which issues the short-lived leaf certificates machines use. Intended production custody is an HSM or secure enclave; a software-held key file is documented as the fallback and test configuration, not the recommendation.

Actors and delegation

An actor is a named identity in an append-only registry with a status. A delegation is a root-signed grant naming the delegate, their key identifier, the scope, the specific work streams, and a validity window with a not-before and an expiry. The signature covers every field, so a grant cannot be widened after signing.

• The scope vocabulary is closed — exactly one scope is recognised. A grant naming any other scope authorises nothing; it does not fail open into general authority.
• An expiry is a ceiling, never a trigger. Nothing gains permission through the passage of time.
• Only the root ratifies standing law or issues further delegations.
• Actor status is checked independently of the grant, so a retired actor is refused even with a valid signature and an unexpired grant.

Standing law and instructions

Ratifying law produces a root-signed manifest listing each document with its SHA-256 and a note, carrying a monotonic serial number — the anti-rollback high-water mark, so replaying a superseded body of law is detectable. Given a document the engine walks the full chain: these bytes hash to this ratified entry, in this untampered manifest, signed by this root.

Individual instructions are signed separately and verified back to the same root before a run is composed. Verification is structural: internally, "this document was verified" is a value constructible only by walking the chain, so an unverified document cannot be mistaken for a verified one downstream.

Private key handling

---