PKI Components

PKIs employ a suite of cryptographic devices that ensure that public keys are managed securely. These devices work in tandem with to perform a wide array of functions relevant to managing public key distribution, including the following:

1.	Authenticating and registering cryptographic endpoints
2.	Verifying the integrity of public keys
3.	Authenticating requests for stored public keys
4.	Securely issuing public key certificates
5.	Revoking public keys that are no longer valid
6.	Maintaining public key revocation information (CRL) and distributing the information (via CRL issuance or responding to Online Certificate Status Protocol [OCSP] messages)
7.	Securely storing valid public keys

We will now explore the function of each of these PKI elements, and then we will walk through the life of a PKI certificate and explore some working scenarios involving cryptographic endpoints and PKI.

Public Key Certificates

The goal of an asymmetric key exchange is to securely distribute the public key to a party who wants to transmit (encrypt) data to the receiving (decrypting) party. A PKI helps to facilitate this key exchange securely while ensuring authenticity of both exchanging parties. The first step in this exchange is the creation of a public key certificate. A public key certificate can correspond to any node that can be referenced in the subject field of the public key certificate.

Note

PKI certificates in today's cryptographic network follow the ITU-T standard formatting for X.509v3 certificates. X.509v3 certificates will be used when discussing PKI examples throughout the remainder of this chapter.

The public key certificate is generated by the certificate authority (CA). In order for the CA to generate the public key certificate for the corresponding cryptographic endpoint, the endpoint must first enroll with the CA. The process of enrollment includes registration, initialization, and certification of the cryptographic endpoint with nodes in the PKI, such as registration authorities (RAs) and CAs. We will use the following list to explore the process of enrollment within a PKI:

1.	The cryptographic endpoint registers with the CA or RA. During this process, the cryptographic endpoint makes its identity known to the certificate cuthority. The certificate cuthority will authenticate the cryptographic endpoint, issuing its public key to the cryptographic endpoint pending the success of that authentication.
2.	The cryptographic endpoint begins the initialization phase by generating a public/private keypair (if it has not already done so). The public key of that keypair is forwarded to the certificate authority.
3.	The CA signs the public key certificate with its private key to create a public key certificate for the cryptographic endpoint. Note In public key cryptography, the private key is normally used for decryption, and the public key is normally used for encryption. When applying a digital signature, the opposite is trueprivate keys are used for encryption and public keys are used for decryption.
4.	Cryptographic endpoints can now request the public key certificate from the cryptographic endpoint described above. They can use the CAs public key (obtained in Step 1) to decrypt the public key certificate to obtain the appropriate public key.

Registration Authorities

In many instances, the CA in a PKI will provide all of the PKI services needed to manage the public keys within the network. However, there are instances in which a CA may delegate tasks to one or more registration ruthorities (RA). The primary task that a CA may delegate to an RA is the verification and validation of the identity of the cryptographic endpoint that is attempting to use the PKI. There are, however, other functions that a CA may also delegate to an RA, including the following:

• Verification that a cryptographic endpoint attempting to enroll a public key with the CA also has the appropriate private key that is to be used in conjunction with the public key (proof of possession)

• Generation of the public/private keypairs to be used in the initialization phase of the enrollment process

  Note

  Cisco cryptographic endpoints support the RSA signature method for PKI. In this process, the RSA keypair is generated locally on the cryptographic endpoint, after which the endpoint attempts to enroll the public key with the CA.

  
  

• Validation of public key parameters

• Indirect issuance of Certificate Revocation Lists (CRL)

Although the RA is capable of offloading many critical PKI functions from the CA, an RA can only compliment a CAit can never replace it. The CA is the central focus of a PKI, and it is the only device in the PKI that is capable of signing public key certificates from cryptographic endpoints.

Certificate Revocation Lists and CRL Issuers

CRLs exist to tell cryptographic endpoints which public key certificates are no longer valid within a PKI. This function is critical to maintaining the integrity of the PKI, especially as it pertains to the freshness of the public keys used by cryptographic endpoints. Public keys that are renewed or expire periodically provide an additional measure of security to the PKI, since they give attackers less time to compromise a public key and deploy it maliciously.

Public key certificates can be rendered invalid for a variety of different reasons. For example, an administrator can manually instruct a CA to revoke a public key certificate, or a certificate could be rendered invalid before the expiry of the timeout field within the certificate itself.

Tip

ITU-T X.509v3-compliant certificates must include a field called "validity period." This field specifies the time range in which the certificate is considered valid. It is critical that the network time settings on the routers, CAs, and RAs are synchronized such that the validity period is accurately populated within the PKI's public key certificates. Otherwise, problems relating to PKI usage could arise. The format of an X.509v3-formatted certificate is illustrated in Figure 11-2 later in this chapter.

Figure 11-2. An ITU-T X.509 Certificate

CAs normally maintain the CRL in a PKI. The maintenance and issuance of the CRL, however, can be delegated to another entity within the PKI, such as an RA. Once issued to a cryptographic endpoint, the CRL is stored locally on that endpoint. The endpoint can then make the appropriate decisions regarding public key certificate usage by cross-referencing the locally stored CRL.

Tip

CRLs can grow to be quite large, which presents a problem on cryptographic endpoints that are memory constrained. OCSP was developed to help mitigate this issue on memory-constrained devices. OCSP is covered in further detail later in this chapter.

Certificate Authorities

A CA represents the central resource of trust in a PKI. This is because the CA is the only element within the PKI that can issue public key certificates to cryptographic endpoints. A PKI does not have to have only one CA. PKIs can set up CAs redundantly or in a hierarchy of trust, in which multiple CAs are branched off of a trusted root CA. These two PKI topologies are illustrated in case studies at the end of this chapter.

CAs are also usually responsible for maintaining the CRL and typically serve as the CRL Issuer. Although a CA may delegate CRL issuance or one of many more responsibilities to one or more RAs, the CA can assume responsibility for all of these functions such that an RA is not needed; the CA is capable of performing all of the tasks that we have discussed previously.

PKI Cryptographic Endpoints

PKI was designed to scale asymmetric key encryption networks to include a variety of different cryptographic endpoints. As such, not only will network nodes oftentimes serve as cryptographic endpoints in a PKI, but workstations, applications, and other devices that live on the periphery of an IP network will also subscribe to the PKI. Therefore, a PKI cryptographic endpoint can be any host, server, network element, or peripheral device that wants to talk to another IP-enabled PKI cryptographic endpoint. Of course, these cryptographic endpoints must all be enrolled with the CA of the PKI, and they must also be able to obtain public key certificates for the PKI cryptographic endpoints that they want to encrypt data towards. We will now explore the process that cryptographic endpoints follow when setting up encrypted communications between one another in a PKI, by stepping through the life of a certificate.