3.1 Scope and Restrictions

The architecture described below is intended to provide a basis for managing public-key cryptosystem values in support of privacy enhanced electronic mail in the Internet environment. The architecture describes procedures for registering certification authorities and users, for generating and distributing certificates, and for generating and distributing CRLs. RFC 1421 describes the syntax and semantics of header fields used to transfer certificates and to represent the DEK and MIC in this public-key context. Definitions of the algorithms, modes of use and associated identifiers are separated in RFC 1423 to facilitate the adoption of additional algorithms in the future. This document focuses on the management aspects of certificate-based, public-key cryptography for privacy enhanced mail.

The proposed architecture imposes conventions for the certification hierarchy which are not strictly required by the X.509 recommendation nor by the technology itself. These conventions are motivated by several factors, primarily the need for authentication semantics compatible with automated validation and the automated determination of the policies under which certificates are issued.

Specifically, the architecture proposes a system in which user (or mailing list) certificates represent the leaves in a certification hierarchy. This certification hierarchy is largely isomorphic to the X.500 directory naming hierarchy, with two exceptions: the IPRA forms the root of the tree (the root of the X.500 DIT is not instantiated as a node), and a number of Policy Certification Authorities (PCAs) form the "roots" of subtrees, each of which represents a different certification policy.

Not every level in the directory hierarchy need correspond to a certification authority. For example, the appearance of geographic entities in a distinguished name (e.g., countries, states, provinces, localities) does not require that various governments become certifying authorities in order to instantiate this architecture. However, it is anticipated that, over time, a number of such points in the hierarchy will be instantiated as CAs in order to simplify later transition of management to appropriate governmental authorities.

These conventions minimize the complexity of validating user certificates, e.g., by making explicit the relationship between a certificate issuer and the user (via the naming hierarchy). Note that in this architecture, only PCAs may be certified by the IPRA, and every CA's certification path can be traced to a PCA, through zero or more CAs. If a CA is certified by more than one PCA, each certificate issued by a PCA for the CA must contain a distinct public component. These conventions result in a certification hierarchy which is a compatible subset of that permitted under X.509, with respect to both syntax and semantics.

Although the key management architecture described in this document has been designed primarily to support privacy enhanced mail, this infrastructure also may, in principle, be used to support X.400 mail security facilities (as per 1988 X.411) and X.500 directory authentication facilities. Thus, establishment of this infrastructure paves the way for use of these and other OSI protocols in the Internet in the future. In the future, these certificates also may be employed in the provision of security services in other protocols in the TCP/IP and OSI suites as well.