As more business transactions occur on the Internet, security services based on cryptography become essential. Public key cryptography plays an important role in providing confidentiality, integrity, authentication, and nonrepudiation. The basic problem with using public-key cryptography is determining who holds the corresponding private key. There are two ways to address this problem. In the first approach, the public key user maintains a local database of the public key and identity pairs.
The public key certificate contains fields for the subject’s identity and public key. The certificate can indicate a company or organization along with a common name. A variety of name forms are supported. Some name forms are abstract, and others are addressed, such as an e-mail address. The certificate also includes two date fields that specify an activation date and an expiration date. The certificate also contains the name of the CA that created the certificate. To clearly identify each certificate that it issues, the CA includes a unique serial number. Finally, the entire contents of the certificate are protected by the CA’s digital signature.
PKI Components and Users
A PKI is often built from three basic functional components: the certification authority (CA), the registration authority (RA), and the repository. A CA is the primary component of the PKI, known by its name and its public key. A CA comprises hardware, software, and the people who operate it. A CA issues certificates maintain certificate status information and issues CRLs and publishes certificates and CRLs. A CA must protect the private key or keys used to sign certificates and CRLs, using physical, procedural, and technical controls.
The hierarchical PKI is the traditional PKI architecture. All users trust the same central root CA. With the exception of the root CA, all of the CAs have a single superior CA. CAS may have subordinate CAs or issue certificates to users or both. A single certificate represents each trust relationship, making certification path construction simple, obvious, and deterministic. The certification paths are usually short. The longest path is equal to the depth of the tree.
The most basic PKI architecture is a single CA that provides all the certificates and CRLs for a community of users. In this configuration, all users trust the CA that issued their certificate. By definition, new CAs cannot be added to the PKI, and all certificates are user certificates. The users accept only certificates and CRLs issued by their CA. Although the simplest to implement, this architecture does not scale easily to support large or diverse user communities. The single CA PKI presents a single point of failure. The compromise of the CA invalidates the trust point information and all certificates that have been issued in this PKI.
Public key certificates
Over time, the focus shifted from supporting the directory to developing a general-purpose PKI. As a result, two upwardly compatible versions have been published since 1988. Version 2 certificates addressed a single issue: reuse of names. The Version 2 enhancements are rarely used today. Version 3 of the X.509 certificate introduces certificate extensions. Extensions are used when the issuer wishes to include information not supported by the basic certificate fields. All modern PKI implementations generate and process X.509 version 3 (X.509 v3) certificates. The set of extensions used by implementations varies widely.
Performance is not the only reason to centralize certification path validation. Some organizations want to impose a centralized management discipline with consistent policy enforcement. If applications use the same trusted path validation server, consistent results across the organization are ensured.