Skip to content

Key Rotation and Revocation Drill

Response ritual — instantiates Transitive Trust Boundary Hardening

Rehearses revoking a trusted signing key and cutting over to a new one, so when a signer is compromised the trust anchor can actually be replaced fast — not just in theory.

The moment a signing key is compromised, every downstream consumer that pins it is trusting an attacker — and stays that way until the key can be revoked, a new one issued and re-signed with, and consumers moved onto the new anchor. Done cold, that cutover is slow and error-prone exactly when speed matters most. Key Rotation and Revocation Drill keeps that path warm: it is a recurring rehearsal of the full revoke-and-rotate sequence against a simulated key compromise. Its defining move is being a response capability, not a check — where its siblings decide whether to admit an artifact, this one keeps the trust anchors those siblings depend on replaceable, and measures how fast that replacement can actually happen.

Example

A software vendor signs its releases with a private key. The drill, run each quarter, begins from the scenario it exists for: assume the key is stolen. It then rehearses the whole cutover — revoke the compromised key, promote a pre-generated backup key, re-sign the current artifacts, update the trust anchor that consumers pin, and notify every downstream consumer to move to the new key — while timing each step and noting where it jams. This run surfaces that roughly a third of shipped clients hardcode the signing key in a way that cannot be updated without a full release, so a real compromise would leave them exposed for weeks. That is precisely the finding you want out of a drill rather than out of an incident, and it is cheap to fix now.

How it works

Periodically exercise the full loop — revoke → rotate → re-sign → re-distribute → confirm — against a simulated compromise, rather than merely documenting it. Along the way it maintains and tests the map of which keys sign what and who custodies them (including backup keys held apart), and it walks the downstream-notification path to see whether consumers can actually be reached and moved. The output is a measured cutover time and a list of rotation-blockers found while they are still cheap. It never verifies an artifact; it keeps the anchors verification depends on able to change.

Tuning parameters

  • Cadence and realism — tabletop walkthrough versus a live cutover in a staging environment. Live drills surface real friction; tabletops are cheaper but understate it.
  • Scope — rehearse a single signer, or the full chain up to the root. Wider scope catches dependencies between keys but costs more to run.
  • Backup-key provisioning — how many spare keys exist, and how separately they are custodied so one compromise cannot take the replacement too.
  • Notification reach and SLA — which downstream consumers are reachable, through what channel, and how fast they are expected to move.
  • Success criteria — the target cutover time and the fraction of consumers that must be migrated for the drill to pass.

When it helps, and when it misleads

Its strength is turning "we could rotate keys" into a measured capability, and surfacing the trust anchors that cannot in practice be rotated — hardcoded keys, offline consumers, third parties you do not control — while fixing them is still cheap.

Its failure mode is that a drill run in a clean staging environment can understate real-world friction: the consumers you do not control and the third parties in the chain are the parts most likely to fail and the hardest to rehearse.[1] And it tests the mechanics of rotation, not whether you would detect the compromise in the first place. The classic misuse is treating a passed tabletop as proof the live cutover works. The discipline: drill the full distribution-and-consumer-update path, not just the re-signing, and keep backup keys genuinely custodied apart so the rehearsal reflects a real recovery.

How it implements the components

  • revocation_and_rotation_path — the drill builds, exercises, and times the actual path to revoke a compromised key and cut over to a new one.
  • signer_key_custody_map — it maintains and tests the map of which keys sign which artifacts and who holds and custodies them, including pre-provisioned backup keys.
  • downstream_notification_obligation — it rehearses notifying every downstream consumer to move to the new trust anchor, and measures whether they can be reached and can actually move.

It does not verify signatures at the point of use (Artifact Signature Verification, which consumes the key custody map this maintains); it does not detect that a key was compromised (intermediary_health_signal, Transparency Log Monitoring; compromise_assumption_model, Trust Chain Red Team); and it does not contain a bad release's spread after admission (blast_radius_boundary, Canary Rollout with Kill Switch).

Notes

The drill maintains the signer_key_custody_map that Artifact Signature Verification reads when it decides which keys are trust anchors. Separating "keep the keys rotatable" (this ritual) from "check the signatures" (that protocol) is what lets a compromised key be revoked and replaced without redesigning verification — the response path and the check evolve independently.

References

[1] Public-key systems provide revocation channels (CRLs, OCSP) to withdraw trust in a key before it expires, but revocation only protects consumers who actually check and act on it. The drill's real purpose is to measure that end-to-end reach — issuing a revocation is easy; getting every downstream consumer off the old anchor is the hard, untested part. ↩