Public Key Infrastructure (PKI) Reference

Public Key Infrastructure (PKI) is the framework of policies, hardware, software, procedures, and cryptographic standards that enables the issuance, management, and revocation of digital certificates used to authenticate identities and secure communications across networks. This reference describes the structural components of PKI, how certificate-based trust operates in practice, the regulatory and standards environment that governs PKI deployment, and the decision criteria that determine when and how PKI is applicable. PKI underlies a significant portion of internet security, including HTTPS, code signing, email encryption, and federal identity credentialing.

Definition and scope

PKI is formally defined by the National Institute of Standards and Technology in NIST SP 800-32 as an infrastructure that uses public-key cryptography and digital certificates to support authentication and secure communications. The foundational cryptographic mechanism is asymmetric encryption, in which a mathematically linked key pair — one public, one private — allows entities to encrypt, decrypt, sign, and verify data without sharing a secret key.

The scope of PKI extends across four major certificate types, each serving distinct authentication functions:

1. Domain Validation (DV) certificates — verify ownership of a domain name; no organizational identity validation is performed.
2. Organization Validation (OV) certificates — verify both domain ownership and the legal existence of the requesting organization.
3. Extended Validation (EV) certificates — the most rigorous class, requiring documented vetting against the CA/Browser Forum's Baseline Requirements; historically triggered the green address bar in browsers.
4. Client certificates — issued to individuals or devices rather than servers; used for mutual TLS authentication, smart card logon, and S/MIME email signing.

In the federal government context, PKI is governed by the Federal PKI (FPKI) program, administered by the General Services Administration (GSA). FPKI connects over 200 certification authorities across federal agencies and bridges with external trust anchors (GSA FPKI).

How it works

PKI operates through a chain of trust rooted in a Certificate Authority (CA) — an entity trusted to issue and sign digital certificates. The structural hierarchy moves through three tiers:

1. Root CA — the trust anchor; its self-signed certificate is pre-distributed in operating systems and browsers via root store programs (Mozilla, Microsoft, Apple, and Google each maintain distinct root stores).
2. Intermediate CA — subordinate to the Root CA; issues end-entity certificates while the root remains offline to limit exposure.
3. End-entity certificate — issued to a server, user, or device; contains the subject's public key, identity attributes, validity period, and the issuing CA's digital signature.

The certificate lifecycle follows a discrete set of operational phases:

1. Key generation — the requesting entity generates a key pair; the private key is retained securely.
2. Certificate Signing Request (CSR) — the public key and identity information are packaged and submitted to the CA.
3. Validation — the CA verifies the request against its applicable policy (DV, OV, or EV); for federal systems this follows NIST SP 800-57 key management recommendations.
4. Issuance — the CA signs the certificate and returns it to the requester.
5. Deployment — the certificate is installed on the target system.
6. Revocation — if a private key is compromised or the certificate is no longer valid, the CA publishes revocation status via the Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP), defined in RFC 6960.
7. Renewal or replacement — certificates carry a fixed validity period; the CA/Browser Forum capped publicly trusted TLS certificate lifetimes at 398 days as of September 2020 (CA/Browser Forum SC31).

The InfoSec Providers section of this resource covers service providers operating in PKI management and certificate lifecycle automation.

Common scenarios

PKI is deployed across a range of operational contexts, each imposing distinct certificate policy requirements:

TLS/HTTPS web server authentication is the most widespread PKI application. Browsers validate a server's certificate chain against a trusted root store; a broken or expired chain triggers a hard browser warning that blocks most user traffic.

Federal identity and access management relies on PKI credentials issued under the Personal Identity Verification (PIV) standard, defined in FIPS 201-3. PIV cards carry four X.509 certificates supporting authentication, digital signature, key management, and card authentication functions.

Code signing uses certificates issued to software developers or publishers; the signature allows operating systems and app stores to verify that code has not been altered since signing. Microsoft Authenticode and Apple notarization both consume PKI certificate chains.

S/MIME email encryption relies on end-entity certificates issued to individual email addresses. The sending client encrypts with the recipient's public key; only the holder of the corresponding private key can decrypt. This scenario is directly relevant to the of this resource's coverage of identity-security services.

IoT device identity is an emerging PKI domain; the Internet Engineering Task Force (IETF) has standardized Enrollment over Secure Transport (EST) in RFC 7030 for automated certificate provisioning to constrained devices.

Decision boundaries

Selecting or deploying PKI involves structural tradeoffs that differ by use case, control environment, and regulatory requirement:

Public CA vs. Private CA — Publicly trusted CAs are required for browser-facing TLS. Private (enterprise) CAs are appropriate for internal systems, mutual TLS between services, and device authentication where the certificate consumer controls its own trust store. Private CAs carry no third-party audit requirement but require internal certificate lifecycle management infrastructure.

Certificate Authority vs. self-signed certificates — Self-signed certificates have no third-party validation; they are appropriate only in isolated development environments or explicitly trusted machine-to-machine contexts. Any public-facing or multi-party authentication scenario requires a CA-signed certificate.

Hardware Security Module (HSM) requirements — FIPS 140-2 or FIPS 140-3 validated HSMs are mandatory for federal CA key storage under FPKI policy (NIST FIPS 140-3). Commercial CA programs operated under WebTrust standards also require HSM key protection for root and intermediate keys.

Certificate validity period selection — Shorter lifetimes reduce the exposure window for a compromised certificate but increase operational overhead. Automated certificate management (ACME protocol, defined in RFC 8555) mitigates this tradeoff by enabling 90-day or shorter cycles without manual renewal processes. The resource at how to use this infosec resource describes how vendor and tooling comparisons in this space are classified across the provider network.

Compliance-driven CA selection — Payment Card Industry (PCI DSS) requirements mandate strong cryptography and certificate validation practices; HIPAA technical safeguards reference encryption of data in transit; and FedRAMP authorizations require compliance with FPKI or equivalent certificate policies for federal cloud systems.