Revocation & independent verification

Compare revocation strategies — expiry, allow/deny lists, and status endpoints — with their honest trade-offs, and understand why authority should be verifiable independently by the party that acts on it.

Track

Engineering

Module

3 · Cryptographic delegation

Prerequisites

Signed short-lived credentials · Delegation chains

A signature tells you a credential was genuinely issued; it tells you nothing about whether the issuer has since changed their mind. Keys get compromised, employees leave, grants get issued in error — and you need a way to say "this credential, though cryptographically valid and not yet expired, should no longer be honoured." That is revocation, and it is genuinely one of the harder problems in applied cryptography because it fights the very property that makes credentials useful: they are meant to be verifiable offline, without asking the issuer every time.

There is no single correct answer. Every revocation strategy is a particular compromise between how quickly a revocation takes effect, how available the system stays if the revocation infrastructure is down, how much it leaks about who is checking what, and whether it scales. Understanding the strategies means understanding exactly which of those you are trading away.

The public-key infrastructure world has lived this problem for decades. Certificate Revocation Lists (CRLs, RFC 5280) distribute a signed list of revoked serials; the Online Certificate Status Protocol (OCSP, RFC 6960) answers per-certificate status queries; OCSP stapling lets the presenter attach a recent signed status so the verifier need not query the responder directly; and the industry has steadily shortened certificate lifetimes precisely because timely revocation proved so hard to guarantee. These same patterns — list, query, staple, or just expire soon — are what agent credential systems reach for.

Expiry (TTL)

Letting a credential simply become invalid after a short time — "revocation by waiting." Needs no network, but is only as timely as the TTL.

Deny list (blocklist/CRL)

A maintained, signed list of credentials revoked before expiry; verifiers consult it. Timeliness depends on how often the list is refreshed and propagated.

Allow list

The inverse: only credentials explicitly present on a current list are honoured — fails closed by default, but requires the list to be authoritative and current.

Status endpoint (OCSP-style)

An online service queried for a credential's current status. Most timely, but adds availability, latency, and privacy costs.

Stapling

The presenter attaches a recent signed status proof so the verifier gets freshness without contacting the status service itself.

Independent verification

The acting party verifies the credential and its status itself against a trust anchor, rather than trusting an intermediary's claim that it is valid.

Lay the strategies against four axes and the compromises become clear. Nothing wins on all of them.

revocation strategies vs properties (honest trade-offs)
strategy        timeliness        availability        privacy          scale
---------       ------------      ---------------     -----------      ----------
short expiry    bounded by TTL    excellent           excellent        excellent
(no revocation) (not instant)     (offline, local)    (no queries)     (nothing to
                                                                        distribute)

deny list /     refresh-period    good if cached      good             list grows with
CRL             lag (minutes-     (stale list risk)   (no per-use      revocations;
                hours)                                 query)           distribution cost

status          near real-time    WEAK: responder     WEAK: issuer     per-use query
endpoint        (per query)       down => fail        learns who       load on responder
(OCSP-style)                      open or shut?       checks what

stapling        as fresh as the   good (no live       good             responder signs
                stapled proof     query at verify)                     periodically

The uncomfortable cell is the status endpoint under failure: if the responder is unreachable, the verifier must choose between fail-open (accept, ignoring possible revocation — a security hole) and fail-closed (reject, turning a responder outage into a full outage). This dilemma is a core reason short expiry is often the better primary control: there is no responder to be down.

1. 1Set the default lifetime as short as your operations tolerate — this makes expiry your baseline revocation and bounds every exposure window for free.
2. 2Decide which events need faster-than-TTL revocation (key compromise, urgent offboarding) — only these justify extra machinery.
3. 3For those, add a deny list refreshed at an interval short enough to meet your timeliness target, signed so verifiers can trust it independently.
4. 4If you need near-real-time status and can accept the availability/privacy cost, use a status endpoint — and decide, explicitly and in advance, whether it fails open or closed.
5. 5Prefer stapling where possible so verifiers get freshness without a live query and without a hard dependency on the responder.
6. 6Ensure every verifier checks independently against a trust anchor — never honour a credential solely because an upstream component said it was fine.

synthetic — layered revocation, verified independently
# Baseline: all agent credentials are 5-minute, signed, audience-bound.
# => routine "revocation" is just waiting <=5 min. No infrastructure needed.

# Exception: agent-7's key is reported compromised NOW. 5 min is too long.
deny_list = sign(issuer_key, {
  revoked: ["agent-7.pub"],
  issued_at: now,
  next_update: now + 60s        # verifiers refresh at least this often
})

# Each verifier, INDEPENDENTLY, before honouring a credential:
def honour(cred):
    if not verify_sig(cred, trust_anchor): reject()     # genuine?
    if now > cred.exp: reject()                          # expired?
    dl = latest_deny_list()
    if now > dl.next_update: reject()   # stale deny list -> FAIL CLOSED
    if cred.subject in dl.revoked: reject()              # revoked early?
    accept()
# Note: verifier trusts the SIGNED deny list + its own anchor, not an
# intermediary's assurance. A stale deny list fails closed, not open.

The short TTL carries the common case; the signed deny list handles the urgent exception; and every verifier reaches its own verdict against the trust anchor. The fail-closed choice on a stale list is explicit, not accidental.

Agent systems issue and delegate credentials rapidly and often run where connectivity to a central service is not guaranteed. That pushes strongly toward short expiry as the primary mechanism: it needs no network, degrades gracefully, and bounds the damage from a leaked or misused agent credential without a revocation message having to arrive anywhere. Deny lists and status endpoints are then reserved for the genuine emergencies — a compromised signing key, an agent discovered to be misbehaving — where TTL alone is too slow.

Independent verification is especially important in multi-agent and cross-domain settings: an executor must verify the authority it is about to act on against its own trust anchor, not accept "the orchestrator already checked it." Trusting an intermediary's assurance re-introduces ambient authority and a confused-deputy path — the executor ends up acting on authority it never actually verified.

• ▸Fail-open vs fail-closed is a real, unavoidable decision for any online status check. Fail-open silently ignores revocations under outage; fail-closed turns a responder outage into a service outage. Decide deliberately, per action's stakes.
• ▸Deny lists are only as timely as their refresh/propagation; a stale list can honour a credential that was revoked minutes ago. Treat a too-old list as untrustworthy (fail closed).
• ▸Status endpoints leak metadata: the responder learns which credentials are being checked, by whom and when. This is a genuine privacy cost, not a detail.
• ▸Revoking an intermediate in a delegation chain must invalidate everything beneath it — long-lived chains make this expensive and easy to get wrong; short TTLs mitigate it.
• ▸Trusting an intermediary instead of verifying independently defeats the point: the acting party must check against a trust anchor itself, or it is exercising unverified authority.
• ▸No revocation mechanism is instant and free; the honest engineering move is usually short lifetimes plus a narrow, explicit emergency path — not a universal real-time status check.

Expected direction: Fail-open: verifiers accept credentials without a status check while the endpoint is down, so any credential revoked-but-not-yet-expired is silently honoured — a security hole. Fail-closed: verifiers reject everything, so the responder outage becomes a full service outage (availability loss). A short-expiry-first design makes expiry the primary revocation: most credentials self-invalidate within minutes with no network needed, so routine revocation does not depend on the endpoint at all; the status endpoint (if kept) is reserved for rare emergencies, shrinking both the blast radius of its outage and how often its fail-open/closed dilemma even arises.

Why is revocation fundamentally in tension with offline verifiability?

Offline verifiability means a verifier can check a credential without contacting the issuer; revocation wants the verifier to confirm current status, which pushes toward a live query. The more real-time the status check, the less offline-checkable the credential.

What is the fail-open vs fail-closed dilemma for status endpoints?

When the status service is unreachable, the verifier must either accept (fail-open, ignoring possible revocations — a security risk) or reject (fail-closed, turning a responder outage into a service outage). Both have real costs; the choice must be deliberate.

What does independent verification require of an acting party?

That it verifies the credential (and its revocation status) itself against its own trust anchor, rather than trusting an intermediary's assurance — otherwise it is exercising unverified authority and re-introduces a confused-deputy path.