codexproof

glossary / SRL (signed revocation list)

codexproof's revocation mechanism - the anchor signs the ENTIRE sorted set of revoked certificate identifiers as one object, stamped with a freshness window and a monotone version, and verifiers refuse to authorize anything without a fresh one.

merkle lineagedomain separationanchorcrl and ocspsecure-web-objects
SRL (signed revocation list) - The mandatory-fresh regime, side by side with the ancestor that died of optional

The mandatory-fresh regime, side by side with the ancestor that died of optional.

Etymology and backstory

the CRL (certificate revocation list) is the 1980s X.509 original; its web history is a cautionary tale (next entry). The SRL keeps the list shape but changes the failure semantics: the list is whole-set-signed (no partial or delta ambiguity), windowed (issued_at through not_after), and versioned (the anti-rollback knob, so a stateful verifier pins the highest version seen and an attacker cannot re-serve an older, still-unexpired list).

Ecosystem

CRLs and OCSP in WebPKI, CRLite and CRLSets in browsers (compressed revocation), key transparency logs - everyone is still arguing about revocation, which is the tell that it is the hard part.

In codexproof

revoke.rs, lines 40 to 45 (version, issued_at, not_after) and line 70 onward (the signed byte layout). The doctrine line at the top of the file: a missing or stale list makes verification FAIL, not silently pass - "the inversion of the C2PA gap."

"Our revocation list is signed whole, versioned monotone, and mandatory-fresh - the three adjectives WebPKI's revocation never managed to hold at once."
References: RFC 5280 for CRL ancestry. Larisch et al., "CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers," IEEE S&P (2017) - the ecosystem's parallel struggle.

All terms · Questions & answers · The verifier