Signing key policy · v0.1
One key signs everything. Here is where it lives.
Custody stated honestly (a PEM on one machine today; hardware custody is the funded target), rotation, compromise handling, and the published key history every relying party should pin.
Version 0.1, 21 October 2026.
1. What is signed
Every JSON response from studio.mizan.market carries a provenance block signed with MIZAN's Ed25519 provenance key; allocate-check and work-check tokens, receipts and webhook pushes are signed with the same key. Public keys and their ids are published at https://studio.mizan.market/.well-known/mizan-keys.json (key_id = sha256(pubkey)[:16]).
2. Custody, stated honestly
- Today the active private key is a PEM file on the single production machine, file mode 0600, generated on first boot. There is no hardware security module and no split custody yet. This is the current state, not the target.
- Target (funded in the seed round): hardware-backed key, two-person control for rotation, offline root key signing online operational keys.
3. Rotation
- Keys rotate on compromise, on custody upgrade, and at most every 24 months. A rotation is announced as a log leaf (kind
note) naming the old and new key ids and the effective time. - Old public keys remain published with their validity window so historical signatures verify forever.
- Credentials and tokens signed before a rotation remain valid; a compromised key's window is marked and relying parties are told which signatures fall inside it.
4. Compromise
- Immediate rotation; a log leaf naming the compromised key id and the time window; webhook push to subscribers; a public incident note under /standard/incident-policy/.
5. What a relying party should do
- Pin the key set from .well-known, re-fetch daily, and treat any signature from an unpublished key id as invalid.