codexproof

glossary / Certificate chain

the sequence of signed statements linking a working key back to a trust anchor - each certificate saying "the holder of key A vouches that key B holds name N" - so trust flows from the axiom to the edge.

anchorx509 and webpkifail closed
Certificate chain - The paperwork under judgment: signer to intermediate to anchor, depth-fenced

The paperwork under judgment: signer to intermediate to anchor, depth-fenced.

Hand-authored SVG for this glossary, 2026. Fences per trust.rs (depth 16, steps 4096); freshness window per revoke.rs.

Etymology and backstory

chains come from X.509's delegation model (ITU-T, 1988): roots are too precious to sign everything, so they license intermediates, which license end entities. Path validation - walking the chain checking signatures, validity, and constraints - is specified in RFC 5280 and is notoriously where PKI implementations grow bugs.

Ecosystem

every TLS handshake ships a chain; SSH certificates, Sigstore's Fulcio issuance, and NDN certificates all reuse the shape.

In codexproof

certificates bind keys to names under an anchor, and authorize (in trust.rs, line 145) walks candidate chains from the signer toward an anchor with two fences - MAX_CHAIN_DEPTH 16 hops, MAX_WALK_STEPS 4096 total - so certificate spam exhausts the budget rather than the verifier (the starvation runbook's check 4). Distinctive simplification: codexproof certificates carry NO expiry; the only clock anywhere is revocation-list freshness (Q21).

"A chain is trust doing paperwork - and our paperwork has exactly one rule, name containment, plus a step budget so spam can only cause denial, never forgery."
References: ITU-T Recommendation X.509 (1988). RFC 5280 (2008), path validation.

All terms · Questions & answers · The verifier