Problem
Revocation checks are only as fresh as the cache TTL and fetch-failure policy. A cached “not revoked” result is not the same as a globally fresh revocation check. Operators need exact semantics so they do not overclaim emergency revocation behavior.
What to do
Make revocation freshness explicit:
- document what happens on cache hit, cache miss, stale cache, and fetch failure
- define whether status-source failure is fail-open, fail-closed, or stale-while-error for each path
- test concurrency guard behavior so cache misses do not double-fetch
- add operator guidance for emergency revocation windows
Acceptance criteria
- production docs state the maximum stale window under default TTL
- tests cover cache hit, stale refresh, fetch failure, and concurrent miss behavior
- verifier logs/metrics distinguish fresh status, cached status, and stale/error status
- incident runbook explains local revocation vs remote status-list propagation
Out of scope
- new revocation standards
- blockchain anchoring
- global instant revocation guarantees
Problem
Revocation checks are only as fresh as the cache TTL and fetch-failure policy. A cached “not revoked” result is not the same as a globally fresh revocation check. Operators need exact semantics so they do not overclaim emergency revocation behavior.
What to do
Make revocation freshness explicit:
Acceptance criteria
Out of scope