What is Public Key Infrastructure (PKI)?

PKI: definition and scope

NIST defines PKI as a framework established to issue, maintain, and revoke public-key certificates. In the X.509 PKIX architectural model, PKI is not just a certificate database or a cryptographic library. It is a collection of roles and processes supporting certificate users, including end entities, certification authorities, registration authorities, certificate-revocation functions, and repositories. The framework also includes management and operational protocols for enrollment, initialization, certificate delivery, and status distribution.12

Public-key cryptography and PKI solve related but different problems. Public-key cryptography provides mathematical mechanisms based on key pairs; PKI provides a managed way to associate a public key with an entity and to communicate the conditions under which that association may be relied upon. The certificate is the signed binding, while registration, policy, validation, and revocation provide the surrounding assurance.123

Certificates and the main PKI roles

A public-key certificate contains information that binds a public key to an identified entity and is digitally signed by a trusted party. Certificate information can also specify how the key may be used and the certificate’s validity period. Common uses include digital signatures and key establishment, such as key agreement or key transport. In TLS, for example, implementations verify certificate integrity and normally verify that certificates are properly signed by a trusted CA; the certificate type and key-use restrictions also need to be compatible with the negotiated authentication method.34

The end entity is the certificate subject or the user system that uses a certificate. The CA issues certificates and is responsible for indicating the revocation status of certificates it issues. An optional registration authority (RA) performs delegated management functions. In NIST’s description, an RA verifies the identity of applicants and authenticates other information that will appear in certificates. A CRL issuer may generate and sign certificate revocation lists, and a repository stores and distributes certificates and revocation information.23

Registration, identity proofing, and issuance

Registration is the process through which a user first becomes known to a CA, directly or through an RA, before the CA issues a certificate. NIST describes several checks: the RA verifies the applicant’s identity and authorization to obtain a certificate, verifies the information to be inserted into the certificate, and verifies that the applicant possesses the private key corresponding to the public key that will be included. The correctness of this information is described as the linchpin of certificate-based security.23

The identity-proofing method depends on the community and policy. NIST gives an example in which applicants physically prove identity using credentials such as a driver’s license, passport, or birth certificate. That example should not be treated as a universal PKI requirement: the important principle is that the CA’s certificate policy defines the assurance and procedures expected for the relevant relying-party community.

After registration and approval, the CA issues the certificate according to its policy and practices. A certificate policy (CP) is a named set of rules describing applicability to a community or class of applications with common security requirements. A certification practice statement (CPS) describes how a specific CA issues and manages certificates. These documents can address key generation and storage, certificate generation, escrow and recovery, status services, audits, configuration management, and archiving.3

Trust stores, trust anchors, and validation paths

A trust anchor is an authoritative entity for which trust is assumed. In PKI, it is a CA represented by a certificate used to verify the signature on a certificate issued by that trust anchor. The security of validation depends on the authenticity and integrity of the trust-anchor certificate. Trust-anchor certificates are often distributed as self-signed certificates, so their initial installation is a security-sensitive operation rather than an automatic consequence of receiving an end-entity certificate.124

A trust store is the local or application-specific collection of trusted CA information used as validation input. During initialization, a client must be securely installed with the public key and other assured information of the trusted CA or CAs it will use to validate certificates. Once initialized, the validator constructs and verifies a certificate path from the presented certificate through issuing CAs to an accepted trust anchor.214

Path validation is more than checking whether a certificate has a familiar issuer name. The validator needs to verify signatures and certificate integrity, evaluate validity periods and constraints, and confirm that the certificate is appropriate for the intended application and key use. TLS 1.3 guidance also emphasizes careful selection of trust anchors, user visibility into certificate and trust-anchor information, and enforcement of suitable minimum and maximum key sizes.42

Revocation and certificate status

Certificates can need to stop being trusted before their stated expiration—for example, after a private-key compromise, an incorrect certificate, or another event covered by the governing policy. A certificate revocation list (CRL) is a list of revoked but unexpired certificates issued by a CA. The PKIX model also identifies the Online Certificate Status Protocol (OCSP) and other mechanisms as ways to provide revocation status information.23

Status delivery creates operational trade-offs. CRLs must be generated, distributed, and obtained by relying parties. Online checking can reduce the delay between an accepted revocation report and the status seen by a relying party, but it introduces additional security requirements: the validator must trust the online validation service, while the repository itself need not be trusted in the same way. Distribution and availability therefore affect the practical timeliness of revocation decisions.23

Applications should not treat an unvalidated certificate as authenticated merely because it contains a plausible public key. TLS guidance warns that using a public key in a certificate without validating the certificate chain or its contents is vulnerable to man-in-the-middle attacks unless an external authentication mechanism, trust-on-first-use process, or comparable out-of-band validation is deliberately used.4

Lifecycle management, governance, and failure modes

PKI management continues after issuance. A sound lifecycle covers key and certificate generation, secure storage, enrollment, distribution, renewal, replacement, suspension or revocation where applicable, retirement, recovery, and archival. NIST identifies practical continuity concerns including lost tokens, forgotten authenticators, corrupted storage, compromised keys, certificate termination without replacement certificates, corrupted CRLs or compromised-key lists, and failures in generation, registration, or distribution systems.31

Governance translates organizational requirements into enforceable certificate practices. The CP defines expectations for the relying-party community; the CPS explains how a particular CA implements them. Governance can therefore determine who may receive certificates, how keys are generated and protected, what uses are permitted, how status is published, how systems are audited and configured, and how records are archived. The exact controls depend on the community and application; RFC 5280 states that specialized domains may need to supplement or replace portions of its profile.3

Cryptographic choices also require lifecycle planning. NIST recommends planning for transitions to stronger keys and more robust algorithms because of cryptanalytic advances, more powerful computing, or algorithm breaks. PKI operators must therefore account for algorithm and key-length changes, certificate reissuance, compatibility, trust-store updates, and the possibility that protected data collected today could be decrypted later if an algorithm becomes inadequate.53

Common operational failure modes include trusting the wrong root, omitting an intermediate certificate, allowing an expired certificate, failing to enforce key-use restrictions, neglecting revocation distribution, losing private keys, failing to replace terminated certificates, and accepting weak or unsuitable algorithms. These are not solved by CA availability alone. They require secure initialization, configuration management, monitoring, recovery planning, and clear ownership across the PKI roles.2145

Common PKI deployment models

PKI can be organized in different ways depending on the community, application, and trust requirements. A single organizational CA hierarchy may support internal users and systems. Separate CA domains may interoperate when each domain provides assurance about its subscribers and the accuracy of certificate information. Cross-certification can establish a trust relationship between CA domains. NIST’s Federal PKI example uses principal CAs designated by agencies in a bridge arrangement, illustrating that larger communities may need an architecture connecting multiple administrative domains.

• A centralized hierarchy: one administrative community operates a CA structure and distributes its trust anchors to participating clients.
• A delegated model: an RA or other management component performs approved registration functions while the CA remains responsible for certificate issuance under its policy.
• A federated or cross-certified model: separate CA domains establish a trust relationship when their communities need interoperable validation.
• A bridge-style model: multiple principal CAs connect administrative communities through a designated interconnection arrangement.

The deployment model does not determine whether a certificate is appropriate on its own. Relying parties still need a trust-anchor decision and application-specific validation rules. A broad trust store can increase interoperability, but it also expands the set of authorities whose certificates may be accepted; trust-anchor selection should consequently be deliberate and controlled.1

A practical PKI evaluation checklist

1. Define the relying-party community, applications, identities, and decisions that certificates are intended to support.
2. Document the certificate policy and the CA’s operating practices, including identity proofing, authorization, key protection, permitted uses, and status services.
3. Separate registration, issuance, validation, and relying-party responsibilities so that ownership is clear.
4. Securely initialize trust stores and control changes to trust anchors.
5. Validate certificate paths, signatures, validity periods, constraints, key usage, and application-specific requirements.
6. Select and operate revocation or status mechanisms with realistic distribution, availability, and latency expectations.
7. Plan renewal, replacement, compromise response, recovery, retirement, auditing, configuration management, and archiving.
8. Maintain a transition plan for algorithms, key lengths, certificate profiles, and trust-store changes.

This checklist describes control areas supported by the cited NIST and IETF passages; it is not a universal compliance baseline. The applicable requirements depend on the certificate policy, application profile, community, and organizational risk.

Conclusion

PKI is the managed system surrounding public-key certificates: identity registration, CA issuance, trust-anchor distribution, path validation, revocation, lifecycle operations, and governance. Its security depends on the correctness of the identity and certificate information, the integrity of initial trust, the discipline of relying-party validation, and the resilience of ongoing key and certificate management. Treating PKI as merely certificate issuance misses the operational controls that make certificate-based trust useful—and the failure modes that can make an apparently valid certificate unsafe to rely on.1243