Public-Key Infrastructure

PUBLIC-KEY INFRASTRUCTURE

RFC 2822 (Internet Security Glossary) defines public-key infrastructure (PKI) as the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography. The principal objective for developing a PKI is to enable secure, conve- nient, and efficient acquisition of public keys. The Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX) working group has been the dri- ving force behind setting up a formal (and generic) model based on X.509 that is suitable for deploying a certificate-based architecture on the Internet. This section describes the PKIX model.

Figure 14.16 shows the interrelationship among the key elements of the PKIX model. These elements are

•                          End entity: A generic term used to denote end users, devices (e.g., servers, routers), or any other entity that can be identified in the subject field of a pub- lic key certificate. End entities typically consume and/or support PKI-related services.

•                          Certification authority (CA): The issuer of certificates and (usually) certificate revocation lists (CRLs). It may also support a variety of administrative functions, although these are often delegated to one or more Registration Authorities.

•                          Registration authority (RA): An optional component that can assume a num- ber of administrative functions from the CA. The RA is often associated with the end entity registration process but can assist in a number of other areas as well.

•                          CRL issuer: An optional component that a CA can delegate to publish CRLs.

•                          Repository: A generic term used to denote any method for storing certificates and CRLs so that they can be retrieved by end entities.

PKIX Management Functions

PKIX identifies a number of management functions that potentially need to be sup- ported by management protocols. These are indicated in Figure 14.16 and include the following:

•                          Registration: This is the process whereby a user first makes itself known to a CA (directly or through an RA), prior to that CA issuing a certificate or cer- tificates for that user. Registration begins the process of enrolling in a PKI. Registration usually involves some offline or online procedure for mutual authentication. Typically, the end entity is issued one or more shared secret keys used for subsequent authentication.

Initialization: Before a client system can operate securely, it is necessary to install key materials that have the appropriate relationship with keys  stored elsewhere in the infrastructure. For example, the client needs to be securely initialized with the public key and other assured information of the trusted CA(s), to be used in validating certificate paths.

•                          Certification: This is the process in which a CA issues a certificate for a user’s public key, returns that certificate to the user’s client system, and/or posts that certificate in a repository.

•                          Key pair recovery: Key pairs can be used to support digital signature creation and verification, encryption and decryption, or both. When a key pair is used for encryption/decryption, it is important to provide a mechanism to recover the nec- essary decryption keys when normal access to the keying material is no longer possible, otherwise it will not be possible to recover the encrypted data. Loss of access to the decryption key can result from forgotten passwords/PINs, corrupted disk drives, damage to hardware tokens, and so on. Key pair recovery allows end entities to restore their encryption/decryption key pair from an authorized key backup facility (typically, the CA that issued the end entity’s certificate).

•                          Key pair update: All key pairs need to be updated regularly (i.e., replaced with a new key pair) and new certificates issued. Update is required when the cer- tificate lifetime expires and as a result of certificate revocation.

•                          Revocation request: An authorized person advises a CA of an abnormal situa- tion requiring certificate revocation. Reasons for revocation include private- key compromise, change in affiliation, and name change.

•                          Cross certification: Two CAs exchange information used in establishing a cross-certificate. A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing   certificates.

PKIX Management Protocols

The PKIX working group has defines two alternative management protocols between PKIX entities that support the management functions listed in the preced- ing subsection. RFC 2510 defines the certificate management protocols (CMP). Within CMP, each of the management functions is explicitly identified by specific protocol exchanges. CMP is designed to be a flexible protocol able to accommodate a variety of technical, operational, and business models.

RFC 2797 defines certificate management messages over CMS (CMC), where CMS refers to RFC 2630, cryptographic message syntax. CMC is built on earlier work and is intended to leverage existing implementations. Although all of the PKIX func- tions are supported, the functions do not all map into specific protocol exchanges.