Revocation or Tombstone Check¶
Use-time registry lookup — instantiates Use-Time Referent Validation
Looks a referent up against an authoritative record of things that are still named but deliberately killed — revoked, deleted, merged, or superseded — so a well-formed name is never mistaken for a still-valid one.
A referent can be perfectly well-formed and still be dead. Revocation or Tombstone Check guards against exactly this: at the moment of use it consults an authoritative record of referents that have been deliberately invalidated — revoked, deleted, merged into another, or superseded by a newer version — and refuses to treat "the name still parses and resolves" as "the thing is still valid." Its signature idea is the tombstone: instead of silently removing a killed referent, the system leaves an explicit marker that it was valid and no longer is, so its death is a positive fact you can look up rather than an absence you might misread. The check turns three genuinely different situations — valid, known-dead, and unknown — into three distinct answers instead of collapsing the last two into an accidental yes.
Example¶
A browser opens a TLS connection and receives a server's certificate. The certificate is cryptographically well-formed, unexpired, and chains to a trusted authority — everything a naive check would want. But the site's private key was compromised last month, and the issuing CA has since revoked the certificate. The browser's revocation check looks the certificate's serial number up against the authority's published revocation data — a Certificate Revocation List, or a live OCSP responder — before trusting the connection.[n1] A hit means the certificate is a tombstone: still presentable, deliberately killed.
The subtle part is the third answer. If the revocation responder is unreachable, the browser doesn't actually know — and treating "couldn't check" as "not revoked" is precisely the gap attackers exploit. A disciplined check keeps unknown separate from valid and lets policy, not accident, decide what to do with it.
How it works¶
- Keep death explicit. When a referent is invalidated, record a tombstone — an authoritative marker that this specific identity is revoked/superseded — rather than deleting it silently, so "killed" is distinguishable from "never existed."
- Look up at use time. Resolve the referent's identity against the invalidation record at the moment of reliance, not once at acquisition.
- Return three states, not two. Answer valid, invalid (tombstone hit), or unknown (no record, or the source couldn't be consulted) — and never silently promote unknown to valid.
- Follow supersession. For merged or superseded referents, resolve the tombstone to its replacement (or flag the redirect) rather than failing blindly.
Tuning parameters¶
- Source freshness — live query per use versus a cached revocation list. Live is current but slow and dependent on the responder; a cached list is fast but misses revocations newer than its refresh.
- Fail-open vs fail-closed — what unknown means operationally. Fail-closed (block on unknown) is safe but brittle when the source is flaky; fail-open (allow on unknown) is available but is the classic security hole — set it by stakes.
- Tombstone retention — how long death markers are kept before garbage-collection. Too short and a resurrected ambiguity ("deleted or never existed?") returns; too long and the record bloats.
- Push vs pull — subscribe to invalidation signals versus polling the list. Push shrinks the window between revocation and detection; pull is simpler but lags.
- Granularity — revoke per-item versus by range or batch. Coarse revocation is cheap but can kill valid siblings; fine-grained is precise but larger to store and search.
When it helps, and when it misleads¶
It earns its place wherever referents outlive their validity while keeping a resolvable name: certificates and credentials, recalled part or drug lots, records merged during a migration, API resources deprecated but not yet deleted. In all of these, absence of an error is not evidence of validity — the tombstone supplies the missing positive signal.
Its central trap is the unknown state. Collapsing "couldn't confirm it's revoked" into "it's valid" — soft-fail — quietly defeats the whole check, and it is the most common way revocation checking fails in practice. A stale revocation source is the next hazard: it will happily miss the revocation that mattered most, the recent one. Over-aggressive tombstone garbage-collection reintroduces the very ambiguity the tombstone existed to remove. The disciplines: decide fail-open versus fail-closed deliberately by consequence, keep the source fresh enough to catch recent kills, and preserve tombstones long enough that a dead referent never reads as a stranger.
How it implements the components¶
stale_reference_invalidation_signal— the tombstone/revocation record is the authoritative invalidation signal, published so consumers can detect that a named referent has been killed.invalid_or_unknown_state_semantics— it is the mechanism that draws and enforces the line between known-invalid (tombstone present) and unknown (no record / source unreachable), refusing to merge them.current_validity_predicate— the use-time lookup is the "is this exact referent still valid now?" test, specialized to the revoked/superseded question.
It does not enumerate the operation's full dependency set — that's Preflight Resource Probe; it does not decide what to *do once a referent reads invalid or unknown — that's Safe Missing-Referent Fallback; and it does not track staleness as a recurring pattern over time — that's Stale Reference Monitor.*
Related¶
- Instantiates: Use-Time Referent Validation — Revocation or Tombstone Check supplies the authoritative "has this named thing been killed?" lookup.
- Sibling mechanisms: Safe Missing-Referent Fallback · Stale Reference Monitor · Preflight Resource Probe · Just-in-Time Existence Check · Capability or Authorization Revalidation · Compare-and-Swap or Version Guard · Atomic Check-and-Use Operation · Lease, Lock, or Reservation Token · Transactional Precondition Guard
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Revocation Or Tombstone Check operates by preserves authoritative revocation markers and consults their history so invalid identities cannot silently reappear. That concrete deployed or enacted form is Record, Log & Register under the frozen taxonomy.
Nearest alternative: Control, Automation & Runtime — Although Control, Automation & Runtime can support this mechanism, the frozen evidence makes its operative form the act that preserves authoritative revocation markers and consults their history so invalid identities cannot silently reappear; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Authoritative status records for revoked, merged, deleted, or superseded names descend from authority control and cataloging.
Related originating lineages:
- Computer Science & Software Engineering — Tombstones in distributed and storage systems independently prevent deleted entities from appearing live.
Review resolution: Both blind reviewers agree that library_information_science is the primary historical origin. Explicit reconciliation of origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement starts from reviewer_a’s mechanism-specific evidence: Authoritative status records for revoked, merged, deleted, or superseded names descend from authority control and cataloging. Reviewer A proposed alternates=computer_science, origin_mode=convergent, domain_reach=multi_domain, and encyclopedia_synthesis=true; reviewer B proposed alternates=computer_science, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (computer_science) without an arbitrary cap, selects origin_mode=convergent to represent the combined lineage evidence, and keeps domain_reach=multi_domain and encyclopedia_synthesis=true from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A tombstone check answers whether a referent is dead; it deliberately does not answer what to do about it. Pairing it with Safe Missing-Referent Fallback is what turns a three-valued lookup into an action — and keeping the two separate is what lets the unknown state be routed by policy rather than by whatever the caller happened to assume.
[n1] X.509 certificate revocation is checked against a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP), both real standards. Soft-fail revocation checking — treating an unreachable responder as "not revoked" — is a well-documented weakness of the approach, and the reason unknown must be kept distinct from valid. ↩
[n2] A tombstone is a standard pattern in distributed data stores (for example, Apache Cassandra) in which a deleted record is marked with an explicit death marker rather than physically removed, so that the deletion propagates and "deleted" stays distinguishable from "never existed."