Identity & Key Operations

Protecting the Entity root is an operational responsibility. ENTITY separates operational signing keys from recovery keys and supports continuity proofs for rotation/recovery.

Create

Create an Entity only in the intended state directory. Record the Entity ID and the purpose/type of the identity. Do not use a temporary working directory for a production sovereign root.

Private material

The reference vault stores key material under the identity state directory and attempts restrictive file permissions. Treat the state directory as sensitive. Never commit *.key, recovery secrets, pairwise secrets or operational backups to Git.

Sign

Applications should request a scoped action and let the Entity sign the defined payload/record. Do not hand private keys to applications that only need signatures.

Rotate

Use rotation when replacing the operational signing key without replacing the Entity. Rotation retires the previous key, creates a new active key, increments the manifest revision and binds the transition with a proof signed by the old key.

Recover

Recovery is for restoring operational control using a designated recovery authority. Verify the recovered manifest and continuity proof before resuming sensitive operations. Recovery must preserve the same Entity ID; creating a fresh Entity is not equivalent.

Hardware custody

The implementation can use a key-protector interface for hardware-wrapped private keys. The v3.4.2 release does not claim the hardware-backed custody promotion gate complete; deployers must qualify their own hardware integration.

Incident response

If a signing key may be exposed: stop new signing, preserve evidence, rotate/recover from a trusted authority as appropriate, revoke/retire the compromised method, verify the new manifest, then audit records produced during the exposure window.