# Managing signing keys

Open Print only publishes public keys. The matching private key stays with the
artist, gallery, or institution that signs records. It should never appear in a
certificate, issuer record, Git repository, browser bundle, or ordinary
application backup.

Each public key has one of three states:

- `active` means the key may sign new records during its validity window;
- `retired` means it no longer signs, but earlier signatures inside its
  validity window remain trustworthy;
- `revoked` means the key is not trusted at any date.

That last rule is intentionally strict. Someone holding a stolen private key
can put an earlier timestamp on a forged record. Open Print cannot reliably
separate that forgery from a genuine historical signature, so revocation
distrusts the key's whole history.

## Routine rotation

Generate the replacement key in the protected system that will use it. Publish
its public half as a new active key with a new ID and a `validFrom` date. A
short overlap with the old active key gives services time to switch without an
issuance outage.

Once every signer uses the replacement, give the old key a `validUntil` date
and mark it `retired`. Keep that public key in the issuer record permanently.
Deleting it would make old certificates harder to verify.

Open Print accepts historical signatures from a retired key, but its registry
and checkpoint creation functions refuse to make new records with one.

## Compromise

If private signing material may have been exposed:

1. Stop using the key and isolate the system that held it.
2. Create a replacement key in a clean environment.
3. Mark the exposed key `revoked`, with `revokedAt` and a plain description in
   `revocationReason`.
4. Publish the updated issuer record.
5. Review records signed by the exposed key. Use later cancellation or
   supersession events where the issuer needs to correct the public history.
6. Sign a new registry checkpoint with the replacement key.

Do not quietly delete questionable records or edit old events. The incident
response belongs in the append-only history.

## Backups

Public keys, issuer records, and checkpoints belong in the normal public
archive. Private keys need a separate encrypted backup with limited access and
a tested recovery procedure. A backup that has never been restored is only an
assumption.

For a small artist-run setup, an encrypted offline copy stored separately from
the working machine is a reasonable starting point. Institutions should use
their existing key-management system and access review process.