Key and certificate rotation

Luvion treats authorization-key rotation and transport-certificate rotation as separate changes. A certificate change does not create a new threshold key, and a new threshold key epoch does not silently authorize new network identities.

Controlled validation

The lifecycle and rollback checks described here are implemented and tested in the non-production pilot. Certificate issuance, secure delivery, private-key destruction, HSM/KMS custody, and multi-operator production approval remain external responsibilities.

Rotation types

Change	Use	Required lifecycle effect
Same-epoch registry update	Endpoint, enabled state, or signer identity maintenance without a new group key	Preserve key epoch, group key ID, public package, and threshold
New authorization key	Replace the distributed group key	Advance exactly from epoch N to N + 1 and use a new group key ID
mTLS certificate rotation	Renew or replace coordinator or signer transport identity	Stage complete old/new pin sets, validate overlap, then remove old pins
Emergency certificate revocation	Remove a compromised transport certificate	Revoke exact certificate, install reviewed replacement coverage, preserve evidence
Adapter or Lit credential rotation	Replace external service access	Keep request and adapter identities stable; verify old access is removed

Planned rotation procedure

1. Declare the scope. Record the affected key epoch, registry, signer roles, certificate slots, adapters, owner, maintenance window, and rollback boundary.
2. Preserve evidence. Verify current lifecycle and witness heads, take a state backup, and record the active configuration digests. Backups must not combine signer shares, TLS private keys, or provider secrets.
3. Stage the candidate. Create a signed proposal with an exact candidate, not_before time, and expiry time. A staged candidate cannot accept new work.
4. Validate overlap. Exercise connectivity, identity pins, health, request binding, and a non-production authorization using the complete authorized old/new set.
5. Activate exactly. Activate the recorded proposal during its review window. Wrong, premature, expired, skipped-epoch, or reused-key proposals must fail without changing the active state.
6. Verify the new head. Confirm new requests bind to the new epoch or certificate generation. Existing in-flight authorization may finish only with its original registry digest and participants.
7. Retire old access. Remove old certificate pins and credentials, verify old clients are rejected, retain public lifecycle evidence, and destroy private material under the approved procedure.
8. Close the change. Export evidence, confirm witness receipt and alert health, and record acceptance results and remaining exceptions.

Emergency revocation

When a signer transport certificate or external credential is suspected compromised:

1. stop new requests that depend on the affected identity;
2. preserve current evidence and alert the incident owner;
3. revoke the exact identity rather than deleting lifecycle history;
4. stage replacement coverage and validate that quorum still exists;
5. atomically publish the reviewed manifest;
6. confirm the old identity is rejected and the replacement succeeds; and
7. reconcile in-flight operations before reopening intake.

Do not reuse a revoked private key, lower a key epoch, skip an epoch, overwrite the lifecycle journal, or copy all participant secrets into one recovery file.

Acceptance evidence

A completed drill should include the proposal and lifecycle digests, authorized old/new identity sets, rejected-old and accepted-new test results, witness receipts, health snapshots, and the operator approval record. Evidence proves the tested transition; it does not prove secure key destruction or independent administration unless those controls were separately observed.