Public key infrastructure and revocation

Per RFC 4949, a Public Key Infrastructure (PKI) is the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke digital certificates based on asymmetric cryptography. Its objective is enabling secure, convenient and efficient acquisition of public keys.

Trust here is transitive. If certificate authority $I_1$ issues a certificate to a subordinate CA $I_2$, and $I_2$ issues a certificate to Bob, labelled $X$, the chain of trust is $I_1 \to I_2 \to X$. Alice verifies Bob’s certificate $X$ by following that chain from $X$ through $I_2$ up to $I_1$, an authority she already trusts. This is certificate chaining, and it is what lets Alice trust a certificate she has never seen before, as long as it eventually leads back to something she does trust.

Before issuing a certificate at all, the CA has to confirm it is issuing to the right identity. Baseline verification, common for ordinary domains, proves ownership: the CA asks the operator to place a specific file on the web server, or to receive email at that domain. This relies on infrastructure, such as DNS and mail delivery, that is not itself especially secure. Extended verification instead uses legal documents. It costs more and takes longer, but gives a stronger, more “human” guarantee of who is actually behind the certificate.

In every hierarchical PKI, the issuer is called a Certificate Authority (CA). The naive idea is one global CA trusted by everyone. It does not work in practice: too many requests for one authority to handle, no agreement on which single organisation deserves that much trust, inconsistent verification standards across jurisdictions, and no global namespace to distinguish, say, two different people both named “John Smith” without something like a passport number.

The pragmatic fix: allow many CAs and accept them all as equals, rather than anointing one. That still leaves the question of how users come to trust any of those CAs. The answer is that the public keys of “trusted” CAs ship pre-installed with the operating system or browser. Users do not get to individually choose which CAs they trust; that choice is effectively made by agreements between vendors and CAs.

That pre-installed set is the root certificate store. Firefox and Chrome each ship one; Windows, Apple’s platforms and Linux distributions maintain their own too. Any application using X.509 needs a root store to anchor its trust decisions in. A root certificate sits at the top of a chain with nothing above it to sign it, so it signs itself. It cannot be verified through the chain the way every other certificate is; it is trusted by decree, because it is present in the root store, not because any signature check on it succeeded.

Not every CA is in every root store. When a browser shows the familiar certificate warning, one common cause is exactly this: the certificate’s chain terminates at a CA (the notes’ own example names one, “R3”) that is not in that browser’s root store, so the chain of trust cannot be completed.

Certificates signed by the root are called intermediate certificates. Most websites hold a certificate signed by an intermediate, not directly by the root. There are two reasons for this layer:

1. Delegating signing authority. A root can hand signing power to another organisation, department or region, creating a sub-CA, without every user needing to contact the root directly.
2. Protecting the root. The root’s private key can be kept offline, in secure storage, reducing its exposure. Day-to-day issuing runs on the intermediate’s key instead, so if that key is ever compromised, the intermediate can be revoked and replaced without touching the root certificate installed in every root store worldwide.

X.509 itself defines the certificate format: CRLs, and a hierarchical PKI with certificate chains, within a framework the X.500 directory can serve. The PKIX model, from the IETF’s Public Key Infrastructure X.509 working group (RFC 5280, per the slides), standardises how that data actually moves across the internet so different vendors, browsers and operating systems interoperate.

A certificate is only ever a statement that a binding was valid at the time it was issued. The key could be compromised later, so verifying a certificate properly means checking it has not been revoked since.