Why does revoking a compromised artifact signing key rarely stop consumers from accepting old artifacts?

## Three separate things people collapse into "revocation" - **The signature** is a mathematical fact about specific bytes and a specific key. It does not decay. A signature made by a key that was later declared untrustworthy still verifies perfectly. - **Revocation** is an assertion published by the key's owner that the key should no longer be trusted. It is data, not enforcement. - **Enforcement** is a verifier actually changing its behaviour. That only happens if the verifier learns about the assertion and acts on it. Most of the pain in this area comes from assuming step two produces step three. ## Why the verifier usually never learns Artifact verification does not look like a browser opening a TLS connection. It looks like: - a build step verifying a downloaded dependency against a public key committed next to the build configuration; - an admission check in a cluster verifying an image against a key or root configured when the cluster was built; - a bootloader on a device verifying firmware against a public key placed there at manufacture. All three are commonly offline, or at least have no reason to reach any network endpoint belonging to the signer. There is no callback, no freshness requirement, and often no expiry on the trusted key at all. A verifier configured with a raw public key has nowhere to even ask. ## The physical extreme: a key you cannot reach Consider an industrial sensor manufacturer that signs firmware with one release key held on a single hardware security module in one office. The matching public key is burned into ROM on roughly four hundred thousand fielded devices. If that private key is compromised, the situation is stark: - **Revocation is physically impossible.** ROM cannot be changed. The devices will verify anything signed by that key for the rest of their service lives. - **Rotation means a recall.** The only way to move to a new key is to touch the hardware — a truck roll, a field engineer, or a factory return. - **The asset at risk is not customer data but availability and safety** of equipment already installed at customer sites, which changes every calculation about acceptable downtime. That case is extreme, but it is only the honest version of a problem every organisation has in weaker form. Ask where your consumers' trusted key actually lives, and count how long it takes to change it everywhere. That number is your true revocation latency. ## What revocation costs even when it does work Even with a revocation mechanism in the verify path, you inherit availability risk: a verifier that hard-fails when it cannot reach the revocation source now has a new outage mode, and one that soft-fails provides no security against an attacker who can simply block the check. This is the reason revocation is quietly disabled or best-effort in many systems — the strict version breaks production, and the lenient version is theatre. ## What to do instead: design so revocation is not the plan 1. **Prefer credentials that expire on their own.** A signing certificate valid for minutes needs no revocation infrastructure — the window closes by itself, and an attacker who steals the credential has minutes rather than years. This is the strongest structural argument for short-lived, per-build signing identities over long-lived keys. 2. **Keep the trusted set small and updatable.** One or two roots that consumers can update through a channel you control is a far better position than a public key pasted into hundreds of independent configurations. 3. **Know your distribution reach before you need it.** Write down, in advance, how a new trusted key gets to every consumer and how long that takes. If the answer is "we would have to ship a new release and hope people take it", say so out loud while it is still cheap to change. 4. **Assume you cannot un-sign.** Everything already signed and distributed remains verifiable to anyone who kept a copy. Custody design has to start from that assumption rather than treating revocation as an undo button. (The separate question of what you *do* on the day a key is actually stolen — which published versions consumers must now distrust, re-releasing, and telling them — is an incident-response topic in its own right.) ## How to say it in an interview "Revocation is a claim, not an enforcement mechanism. Our verifiers check signatures offline against a key they already hold, so the only thing that actually stops acceptance is replacing that trusted key at every consumer — which is a distribution problem, not a cryptographic one. That is why I would rather sign with short-lived credentials that expire on their own than build a revocation path I would end up disabling for availability reasons."