2. Overview of Approach

This document defines a key management architecture based on the use of public-key certificates, primarily in support of the message encipherment and authentication procedures defined in RFC 1421. The concept of public-key certificates is defined in X.509 and this architecture is a compliant subset of that envisioned in X.509.

Briefly, a (public-key) certificate is a data structure which contains the name of a user (the "subject"), the public component (This document adopts the terms "private component" and "public component" to refer to the quantities which are, respectively, kept secret and made publicly available in asymmetric cryptosystems. This convention is adopted to avoid possible confusion arising from use of the term "secret key" to refer to either the former quantity or to a key in a symmetric cryptosystem.) of that user, and the name of an entity (the "issuer") which vouches that the public component is bound to the named user. This data, along with a time interval over which the binding is claimed to be valid, is cryptographically signed by the issuer using the issuer's private component. The subject and issuer names in certificates are Distinguished Names (DNs) as defined in the directory system (X.500). Once signed, certificates can be stored in directory servers, transmitted via non-secure message exchanges, or distributed via any other means that make certificates easily accessible to message system users, without regard for the security of the transmission medium. Certificates are used in PEM to provide the originator of a message with the (authenticated) public component of each recipient and to provide each recipient with the (authenticated) public component of the originator. The following brief discussion illustrates the procedures for both originator and recipients.

Prior to sending an encrypted message (using PEM), an originator must acquire a certificate for each recipient and must validate these certificates. Briefly, validation is performed by checking the digital signature in the certificate, using the public component of the issuer whose private component was used to sign the certificate. The issuer's public component is made available via some out of band means (for the IPRA) or is itself distributed in a certificate to which this validation procedure is applied recursively. In the latter case, the issuer of a user's certificate becomes the subject in a certificate issued by another certifying authority (or a PCA), thus giving rise to a certification hierarchy. The validity interval for each certificate is checked and Certificate Revocation Lists (CRLs) are checked to ensure that none of the certificates employed in the validation process has been revoked by an issuer.

Once a certificate for a recipient is validated, the public component contained in the certificate is extracted and used to encrypt the data encryption key (DEK), which, in turn, is used to encrypt the message itself. The resulting encrypted DEK is incorporated into the Key-Info field of the message header. Upon receipt of an encrypted message, a recipient employs his private component to decrypt this field, extracting the DEK, and then uses this DEK to decrypt the message.

In order to provide message integrity and data origin authentication, the originator generates a message integrity code (MIC), signs (encrypts) the MIC using the private component of his public-key pair, and includes the resulting value in the message header in the MIC-Info field. The certificate of the originator is (optionally) included in the header in the Certificate field as described in RFC 1421. This is done in order to facilitate validation in the absence of ubiquitous directory services. Upon receipt of a privacy enhanced message, a recipient validates the originator's certificate (using the IPRA public component as the root of a certification path), checks to ensure that it has not been revoked, extracts the public component from the certificate, and uses that value to recover (decrypt) the MIC. The recovered MIC is compared against the locally calculated MIC to verify the integrity and data origin authenticity of the message.