Every TLS handshake you initiate — every HTTPS connection your browser silently negotiates — rests on a distributed trust architecture that most practitioners treat as a black box. Public Key Infrastructure isn't just a certificate delivery mechanism. It's a trust distribution protocol with deep cryptographic assumptions, subtle failure modes, and design tradeoffs that cascade through the entire security stack. Understanding PKI at the protocol level means understanding how trust is manufactured, delegated, and — critically — revoked.

The core tension in PKI design has remained constant since its formalization in the X.509 standard: how do you bind a public key to an identity in a way that's both scalable and verifiable without requiring every relying party to personally validate every entity? The hierarchical CA model answers this with delegated trust chains. The PGP web of trust answers it with decentralized attestation. Neither answer is complete, and the failure modes of each reveal something fundamental about the limits of cryptographic trust.

This article dissects PKI from three angles. First, we'll walk through the certificate path validation algorithm — not the hand-wavy version, but the actual verification properties that RFC 5280 demands. Second, we'll analyze the revocation problem, comparing CRL distribution points, OCSP responders, and OCSP stapling with an eye toward their real-world security-efficiency frontiers. Finally, we'll contrast the hierarchical and web-of-trust models, examining their distinct threat surfaces and what each reveals about the structural assumptions baked into cryptographic trust.

X.509 certificate path validation, as specified in RFC 5280, is considerably more nuanced than the simplified "follow the chain to a root" description most engineers internalize. The algorithm must verify a set of interlocking properties at each certificate in the chain: signature validity, temporal validity, name constraints, policy constraints, key usage extensions, and path length constraints. Each of these checks addresses a distinct attack surface, and skipping any one of them has historically led to real-world exploits.

Consider the signature verification step. At each link in the chain, the relying party must confirm that the certificate's signature was produced by the private key corresponding to the issuer's public key. This is straightforward elliptic curve or RSA verification — but the security property it guarantees is non-trivial. It ensures that no intermediate entity has modified the binding between the subject's identity and their public key without detection. The chain of signatures creates a transitive trust path: if you trust the root, and the root signed the intermediate, and the intermediate signed the leaf, then the binding at the leaf inherits credibility from the root.

Name constraints and path length constraints add topological control to this trust delegation. A name constraint on an intermediate CA certificate limits the namespace over which that CA can issue valid certificates. Without this, a compromised intermediate CA for a corporate intranet could issue certificates for arbitrary public domains. Path length constraints prevent trust chains from extending indefinitely, bounding the attack surface of delegation. These are not optional niceties — they are structural controls that prevent the trust model from degenerating into an unbounded authority graph.

Policy processing adds another layer. Certificate policies, expressed as OIDs, allow the issuer to specify under what conditions a certificate should be considered valid. Policy mapping between certificates in the chain allows different CAs to express equivalent policies using different identifiers. The algorithm must track the valid policy tree as it walks the chain, pruning branches that fail to satisfy policy constraints. In practice, policy processing is one of the most under-implemented aspects of path validation, and many TLS libraries handle it incompletely.

The critical insight is that path validation is not a single check — it's a composite verification protocol that enforces structural, temporal, cryptographic, and policy invariants simultaneously. Each invariant addresses a different threat: signature checks prevent forgery, temporal checks prevent use of expired or not-yet-valid credentials, name constraints prevent scope creep, and policy constraints prevent semantic misuse. When implementations cut corners on any of these — and they regularly do — the result isn't a minor gap. It's a categorically different trust model than the one the standard specifies.

Takeaway

Certificate path validation isn't a single trust check — it's a composite protocol enforcing cryptographic, structural, and semantic invariants simultaneously. Weakening any one invariant doesn't slightly reduce security; it fundamentally changes the trust model.

Certificate revocation is arguably PKI's hardest unsolved problem. The fundamental tension is between freshness of revocation data and availability of the relying party's verification path. A certificate that was valid ten minutes ago may have had its private key compromised nine minutes ago. How quickly can the ecosystem propagate that invalidity — and what happens when the revocation infrastructure itself is unreachable?

Certificate Revocation Lists were the original mechanism: a CA periodically publishes a signed list of revoked certificate serial numbers, and relying parties download and cache it. The security properties are clear — the list is signed by the CA, so it can't be tampered with in transit — but the efficiency properties are brutal. CRLs grow monotonically over a CA's lifetime, creating bandwidth and storage burdens. More critically, the freshness window between CRL publications creates a gap during which a revoked certificate remains apparently valid. Delta CRLs mitigate the size problem but not the freshness problem.

OCSP addressed freshness by moving to a real-time query model: the relying party asks an OCSP responder whether a specific certificate is currently valid and receives a signed response. This dramatically improves revocation latency but introduces new failure modes. The responder becomes a single point of failure and a privacy leak — every TLS connection now reveals to the OCSP responder which sites a user is visiting. And the critical design question remains: what should a relying party do when the OCSP responder is unreachable? Most implementations soft-fail — they accept the certificate anyway — which means an attacker who can block OCSP traffic effectively neutralizes the entire revocation system.

OCSP stapling shifts the query burden from the relying party to the certificate holder. The server periodically fetches a signed OCSP response for its own certificate and "staples" it to the TLS handshake. This eliminates the privacy concern and reduces load on OCSP responders, but introduces its own subtlety: the Must-Staple extension (RFC 7633) is required to make this scheme robust. Without it, a server with a revoked certificate can simply omit the stapled response, and the client has no way to distinguish "server chose not to staple" from "server's certificate is revoked." Must-Staple transforms stapling from an optimization into a security control.

The deeper lesson is that revocation exposes a fundamental limit of offline credential systems. A certificate is a static assertion about a dynamic property — the ongoing validity of a key binding. Every revocation mechanism is essentially an attempt to bolt real-time state onto an inherently offline artifact. CRLs accept staleness for simplicity. OCSP trades staleness for availability risk. Stapling with Must-Staple pushes the problem to the server but requires ecosystem-wide adoption. None fully resolves the tension, and the choice between them is ultimately a choice about which failure mode you find most acceptable.

Takeaway

Revocation is the problem of imposing real-time state on an offline credential. Every approach — CRLs, OCSP, stapling — trades one failure mode for another. The architectural question isn't which mechanism is best, but which failure mode is tolerable for your threat model.

The hierarchical CA model and PGP's web of trust represent two fundamentally different answers to the same question: who decides that a public key belongs to a particular entity? The CA model concentrates this authority in a relatively small number of trusted third parties. The web of trust distributes it across the entire user population. Each model embeds distinct assumptions about where trust originates, how it propagates, and how it fails.

In the hierarchical model, trust flows downward from root CAs through intermediates to leaf certificates. The root store — curated by browser vendors and operating system maintainers — is the trust anchor set. This creates a clean, auditable delegation structure, but it also creates concentrated points of failure. The compromise of a single root CA — or even an intermediate — can undermine the entire system's integrity. The DigiNotar incident in 2011 demonstrated this vividly: a single compromised CA allowed the issuance of fraudulent certificates for Google domains, and the entire root had to be excised from trust stores worldwide.

Certificate Transparency logs represent the ecosystem's primary mitigation for CA misbehavior. By requiring CAs to submit certificates to publicly auditable append-only logs before they're considered valid, CT transforms CA trust from "trust but can't verify" to "trust but publicly monitor." This is a significant architectural improvement, but it's detective rather than preventive — it helps you discover that a fraudulent certificate was issued, but doesn't prevent the issuance itself.

The PGP web of trust inverts the authority structure. Instead of a small set of trusted roots, any user can sign any other user's key, and trust propagates through social attestation. You assign trust levels to individuals, and keys are considered valid based on the number and trustworthiness of their signers. The model is more resilient to single-point compromise — there is no one entity whose failure invalidates everything — but it introduces scalability and usability barriers that have prevented widespread adoption. Computing trust paths through a decentralized graph is non-trivial, and the model requires users to make nuanced trust decisions that most people are neither equipped nor motivated to make.

The failure modes are instructive. Hierarchical PKI fails catastrophically but narrowly: a compromised CA can forge any identity, but the damage can be contained by removing the CA from trust stores. The web of trust fails gradually but pervasively: trust erosion through Sybil attacks, social engineering, or key management failures degrades the graph's integrity in ways that are difficult to detect and harder to remediate. Modern systems increasingly explore hybrid approaches — DANE uses DNSSEC to bind certificates to domain names, effectively using the DNS hierarchy as an alternative trust anchor. The broader trajectory suggests that no single trust topology is sufficient, and robust PKI design may ultimately require layered trust models that combine the auditability of hierarchy with the resilience of distribution.

Takeaway

Hierarchical PKI fails catastrophically but containably; the web of trust fails gradually but pervasively. The choice between centralized and decentralized trust isn't about which is more secure — it's about which failure mode your system can survive.

PKI is not a solved problem — it's a set of carefully negotiated tradeoffs between scalability, freshness, resilience, and usability. The path validation algorithm defines the cryptographic invariants that trust chains must satisfy. Revocation mechanisms reveal the inherent tension between offline credentials and real-time validity. And the choice between hierarchical and decentralized trust models reflects a deeper architectural question about where failure is acceptable.

What makes PKI fascinating from a cryptographic theory perspective is that its hardest problems aren't mathematical — they're structural. The cryptographic primitives work. The challenge is designing trust topologies that remain coherent at scale, degrade gracefully under compromise, and remain practically usable by humans and machines alike.

As the ecosystem evolves toward Certificate Transparency, Must-Staple OCSP, and hybrid trust anchors like DANE, the underlying lesson persists: trust distribution is an engineering problem constrained by fundamental information-theoretic limits. No static credential can perfectly represent a dynamic trust relationship. The best PKI designs are the ones that acknowledge this honestly.