Skip to content

CONCEPT Cited by 6 sources

Chain of trust

Definition

A chain of trust is a sequence of cryptographic vouching links by which a verifier extends trust from a single preconfigured trust anchor down to a leaf it has never seen before. Each link is a parent that signs (or publishes a fingerprint of) its child's public key; the verifier starts at the anchor it already trusts and walks downward, verifying each signature in turn. The leaf is trusted only if every link above it verifies.

This is the structure shared by DNSSEC, the Web PKI, and code-signing: trust is not flat (you don't trust every key individually) and not global (there is no universal authority); it is delegated from a small set of anchors.

Canonical instances

  • Web PKI (TLS certificates) — a browser trusts a set of root CAs in its root store; roots sign intermediate CAs; intermediates sign leaf server certs. The chain the server presents is leaf → intermediate(s) → (root in the store). See systems/web-pki, systems/certificate-transparency.
  • DNSSEC — the chain is root KSK → root ZSK → TLD DS → TLD key → … → zone key → RRSIG. Each parent publishes a DS (Delegation Signer) record fingerprinting its child's key. The root KSK is the anchor; it has no parent, so it must be preconfigured. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)
  • Code signing / secure boot — a hardware/root key vouches for firmware signing keys, which vouch for the shipped artifact.

Break-once, forge-everywhere

The defining risk of a chain of trust: compromising a key high in the chain compromises everything below it. A forged root CA key makes every certificate under it forgeable; a recovered root DNSSEC KSK forges a validation path to any zone. This is why the top of the chain gets the heaviest protection (offline HSMs, air-gapped ceremonies, rare and carefully-staged rollovers) and why rotating a leaf or zone key more frequently does not defend against an attacker who targets a key further up: they forge every delegation below the compromised link. This property drives post-quantum migration order — the highest keys (root CAs, root KSK) are the highest-value targets. (Source: sources/2026-09-10-cloudflare-1111-post-quantum-dnssec)

The eMudhra intermediate-CA compromise (2026-10-20) is a concrete non-quantum instance one level below the root: the private keys of eight intermediate CAs were weak enough to derive, so an attacker could forge a leaf certificate for any domain and have it chain to a still-trusted root. "High in the chain" doesn't have to mean the root — an intermediate is high enough that its compromise forges everything beneath it. The response is the revocation half of chain management: the compromised links must be untrusted everywhere fast (browser quick-revocation like Chrome CRLSets; updatable trust stores à la upki), which is exactly the "changing the chain is easy below the anchor, hard at/near the top" asymmetry seen from the panic end. (Source: sources/2026-10-20-cloudflare-emudhra-certificates-compromised)

Transition mechanics: cross-signing and the anchor problem

Chains make routine key changes easy below the anchor — a parent simply signs the new child key. The hard problem is always changing the anchor itself, because nothing above it can vouch for the new one. Two standard moves:

  • Cross-signing — during a CA transition, both the old and new roots sign the intermediates, so clients trusting either root validate the chain. Lets the client base migrate at its own pace.
  • Preconfigured anchor rotation — for anchors with no parent (DNSSEC root KSK, browser root stores) the new anchor must be distributed out of band: RFC 5011 automatic update, resolver/OS software updates with built-in anchors, or browser root-store updates. See concepts/trust-anchor and the KSK-2024 rollover in concepts/key-rotation.

Seen in

Last updated · 854 distilled / 2,448 read