Network Working Group S. Kent
`Request for Comments: 1422 BBN
`Obsoletes: 1114 IAB IRTF PSRG, IETF PEM
` February 1993
`
`
` Privacy Enhancement for Internet Electronic Mail:
` Part II: Certificate-Based Key Management
`
`Status of this Memo
`
` This RFC specifies an IAB standards track protocol for the Internet
` community, and requests discussion and suggestions for improvements.
` Please refer to the current edition of the "IAB Official Protocol
` Standards" for the standardization state and status of this protocol.
` Distribution of this memo is unlimited.
`
`Acknowledgements
`
` This memo is the outgrowth of a series of meetings of the Privacy and
` Security Research Group of the Internet Research Task Force (IRTF)
` and the Privacy-Enhanced Electronic Mail Working Group of the
` Internet Engineering Task Force (IETF). I would like to thank the
` members of the PSRG and the PEM WG for their comments and
` contributions at the meetings which led to the preparation of this
` document. I also would like to thank contributors to the PEM-DEV
` mailing list who have provided valuable input which is reflected in
` this memo.
`
`1. Executive Summary
`
` This is one of a series of documents defining privacy enhancement
` mechanisms for electronic mail transferred using Internet mail
` protocols. RFC 1421 [6] prescribes protocol extensions and
` processing procedures for RFC-822 mail messages, given that suitable
` cryptographic keys are held by originators and recipients as a
` necessary precondition. RFC 1423 [7] specifies algorithms, modes and
` associated identifiers for use in processing privacy-enhanced
` messages, as called for in RFC 1421 and this document. This document
` defines a supporting key management architecture and infrastructure,
` based on public-key certificate techniques, to provide keying
` information to message originators and recipients. RFC 1424 [8]
` provides additional specifications for services in conjunction with
` the key management infrastructure described herein.
`
` The key management architecture described in this document is
` compatible with the authentication framework described in CCITT 1988
` X.509 [2]. This document goes beyond X.509 by establishing
`
`
`
`
`
`
`
`
`Kent [Page 1]
`
`001
`
`Intellectual Ventures Ex. 2016
`Compass v. IV
`IPR2014-00724
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` procedures and conventions for a key management infrastructure for
` use with Privacy Enhanced Mail (PEM) and with other protocols, from
` both the TCP/IP and OSI suites, in the future. There are several
` motivations for establishing these procedures and conventions (as
` opposed to relying only on the very general framework outlined in
` X.509):
`
` -It is important that a certificate management infrastructure
` for use in the Internet community accommodate a range of
` clearly-articulated certification policies for both users
` and organizations in a well-architected fashion.
` Mechanisms must be provided to enable each user to be
` aware of the policies governing any certificate which the
` user may encounter. This requires the introduction
` and standardization of procedures and conventions that are
` outside the scope of X.509.
`
` -The procedures for authenticating originators and recipient in
` the course of message submission and delivery should be
` simple, automated and uniform despite the existence of
` differing certificate management policies. For example,
` users should not have to engage in careful examination of a
` complex set of certification relationships in order to
` evaluate the credibility of a claimed identity.
`
` -The authentication framework defined by X.509 is designed to
` operate in the X.500 directory server environment. However
` X.500 directory servers are not expected to be ubiquitous
` in the Internet in the near future, so some conventions
` are adopted to facilitate operation of the key management
` infrastructure in the near term.
`
` -Public key cryptosystems are central to the authentication
` technology of X.509 and those which enjoy the most
` widespread use are patented in the U.S. Although this
` certification management scheme is compatible with
` the use of different digital signature algorithms, it is
` anticipated that the RSA cryptosystem will be used as
` the primary signature algorithm in establishing the
` Internet certification hierarchy. Special license
` arrangements have been made to facilitate the
` use of this algorithm in the U.S. portion of Internet
` environment.
`
` The infrastructure specified in this document establishes a single
` root for all certification within the Internet, the Internet Policy
` Registration Authority (IPRA). The IPRA establishes global policies,
` described in this document, which apply to all certification effected
`
`
`
`
`
`Kent [Page 2]
`
`002
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` under this hierarchy. Beneath IPRA root are Policy Certification
` Authorities (PCAs), each of which establishes and publishes (in the
` form of an informational RFC) its policies for registration of users
` or organizations. Each PCA is certified by the IPRA. (It is
` desirable that there be a relatively small number of PCAs, each with
` a substantively different policy, to facilitate user familiarity with
` the set of PCA policies. However there is no explicit requirement
` that the set of PCAs be limited in this fashion.) Below PCAs,
` Certification Authorities (CAs) will be established to certify users
` and subordinate organizational entities (e.g., departments, offices,
` subsidiaries, etc.). Initially, we expect the majority of users will
` be registered via organizational affiliation, consistent with current
` practices for how most user mailboxes are provided. In this sense
` the registration is analogous to the issuance of a university or
` company ID card.
`
` Some CAs are expected to provide certification for residential users
` in support of users who wish to register independent of any
` organizational affiliation. Over time, we anticipate that civil
` government entities which already provide analogous identification
` services in other contexts, e.g., driver's licenses, may provide
` this service. For users who wish anonymity while taking advantage of
` PEM privacy facilities, one or more PCAs will be established with
` policies that allow for registration of users, under subordinate CAs,
` who do not wish to disclose their identities.
`
`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).
`
`
`
`
`
`Kent [Page 3]
`
`003
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` 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
`
`
`
`
`
`Kent [Page 4]
`
`004
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` of the message.
`
`3. Architecture
`
` 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
`
`
`
`
`
`Kent [Page 5]
`
`005
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` 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.
`
` 3.2 Relation to X.509 Architecture
`
` CCITT 1988 Recommendation X.509, "The Directory - Authentication
` Framework", defines a framework for authentication of entities
` involved in a distributed directory service. Strong authentication,
` as defined in X.509, is accomplished with the use of public-key
` cryptosystems. Unforgeable certificates are generated by
` certification authorities; these authorities may be organized
` hierarchically, though such organization is not required by X.509.
` There is no implied mapping between a certification hierarchy and the
` naming hierarchy imposed by directory system naming attributes.
`
` This document interprets the X.509 certificate mechanism to serve the
` needs of PEM in the Internet environment. The certification
` hierarchy proposed in this document in support of privacy enhanced
` mail is intentionally a subset of that allowed under X.509. This
` certification hierarchy also embodies semantics which are not
` explicitly addressed by X.509, but which are consistent with X.509
` precepts. An overview of the rationale for these semantics is
` provided in Section 1.
`
` 3.3 Certificate Definition
`
` Certificates are central to the key management architecture for X.509
` and PEM. This section provides an overview of the syntax and a
` description of the semantics of certificates. Appendix A includes
` the ASN.1 syntax for certificates. A certificate includes the
` following contents:
`
`
`
`
`
`
`Kent [Page 6]
`
`006
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` 1. version
`
` 2. serial number
`
` 3. signature (algorithm ID and parameters)
`
` 4. issuer name
`
` 5. validity period
`
` 6. subject name
`
` 7. subject public key (and associated algorithm ID)
`
` 3.3.1 Version Number
`
` The version number field is intended to facilitate orderly changes in
` certificate formats over time. The initial version number for
` certificates used in PEM is the X.509 default which has a value of
` zero (0), indicating the 1988 version. PEM implementations are
` encouraged to accept later versions as they are endorsed by
` CCITT/ISO.
`
` 3.3.2 Serial Number
`
` The serial number field provides a short form, unique identifier for
` each certificate generated by an issuer. An issuer must ensure that
` no two distinct certificates with the same issuer DN contain the same
` serial number. (This requirement must be met even when the
` certification function is effected on a distributed basis and/or when
` the same issuer DN is certified under two different PCAs. This is
` especially critical for residential CAs certified under different
` PCAs.) The serial number is used in CRLs to identify revoked
` certificates, as described in Section 3.4.3.4. Although this
` attribute is an integer, PEM UA processing of this attribute need not
` involve any arithmetic operations. All PEM UA implementations must
` be capable of processing serial numbers at least 128 bits in length,
` and size-independent support serial numbers is encouraged.
`
` 3.3.3 Signature
`
` This field specifies the algorithm used by the issuer to sign the
` certificate, and any parameters associated with the algorithm. (The
` certificate signature is appended to the data structure, as defined
` by the signature macro in X.509. This algorithm identification
` information is replicated with the signature.) The signature is
` validated by the UA processing a certificate, in order to determine
` that the integrity of its contents have not been modified subsequent
`
`
`
`
`
`Kent [Page 7]
`
`007
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` to signing by a CA (IPRA, or PCA). In this context, a signature is
` effected through the use of a Certificate Integrity Check (CIC)
` algorithm and a public-key encryption algorithm. RFC 1423 contains
` the definitions and algorithm IDs for signature algorithms employed
` in this architecture.
`
` 3.3.4 Subject Name
`
` A certificate provides a representation of its subject's identity in
` the form of a Distinguished Name (DN). The fundamental binding
` ensured by the key management architecture is that between the public
` component and the user's identity in this form. A distinguished name
` is an X.500 directory system concept and if a user is already
` registered in an X.500 directory, his distinguished name is defined
` via that registration. Users who are not registered in a directory
` should keep in mind likely directory naming structure (schema) when
` selecting a distinguished name for inclusion in a certificate.
`
` 3.3.5 Issuer Name
`
` A certificate provides a representation of its issuer's identity, in
` the form of a Distinguished Name. The issuer identification is used
` to select the appropriate issuer public component to employ in
` performing certificate validation. (If an issuer (CA) is certified
` by multiple PCAs, then the issuer DN does not uniquely identify the
` public component used to sign the certificate. In such circumstances
` it may be necessary to attempt certificate validation using multiple
` public components, from certificates held by the issuer under
` different PCAs. If the 1992 version of a certificate is employed,
` the issuer may employ distinct issuer UIDs in the certificates it
` issues, to further facilitate selection of the right issuer public
` component.) The issuer is the certifying authority (IPRA, PCA or CA)
` who vouches for the binding between the subject identity and the
` public key contained in the certificate.
`
` 3.3.6 Validity Period
`
` A certificate carries a pair of date and time indications, indicating
` the start and end of the time period over which a certificate is
` intended to be used. The duration of the interval may be constant
` for all user certificates issued by a given CA or it might differ
` based on the nature of the user's affiliation. For example, an
` organization might issue certificates with shorter intervals to
` temporary employees versus permanent employees. It is recommended
` that the UTCT (Coordinated Universal Time) values recorded here
` specify granularity to no more than the minute, even though finer
` granularity can be expressed in the format. (Implementors are warned
` that no DER is defined for UTCT in X.509, thus transformation between
`
`
`
`
`
`Kent [Page 8]
`
`008
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` local and transfer syntax must be performed carefully, e.g., when
` computing the hash value for a certificate. For example, a UTCT
` value which includes explict, zero values for seconds would not
` produce the same hash value as one in which the seconds were
` omitted.) It also recommended that all times be expressed as
` Greenwich Mean Time (Zulu), to simplify comparisons and avoid
` confusion relating to daylight savings time. Note that UTCT
` expresses the value of a year modulo 100 (with no indication of
` century), hence comparisons involving dates in different centuries
` must be performed with care.
`
` The longer the interval, the greater the likelihood that compromise
` of a private component or name change will render it invalid and thus
` require that the certificate be revoked. Once revoked, the
` certificate must remain on the issuer's CRL (see Section 3.4.3.4)
` until the validity interval expires. PCAs may impose restrictions on
` the maximum validity interval that may be elected by CAs operating in
` their certification domain (see Appendix B).
`
` 3.3.7 Subject Public Key
`
` A certificate carries the public component of its associated subject,
` as well as an indication of the algorithm, and any algorithm
` parameters, with which the public component is to be used. This
` algorithm identifier is independent of that which is specified in the
` signature field described above. RFC 1423 specifies the algorithm
` identifiers which may be used in this context.
`
` 3.4 Roles and Responsibilities
`
` One way to explain the architecture proposed by this document is to
` examine the roles which are defined for various entities in the
` architecture and to describe what is required of each entity in order
` for the proposed system to work properly. The following sections
` identify four types of entities within this architecture: users and
` user agents, the Internet Policy Registration Authority, Policy
` Certification Authorities, and other Certification Authorities. For
` each type of entity, this document specifies the procedures which the
` entity must execute as part of the architecture and the
` responsibilities the entity assumes as a function of its role in the
` architecture.
`
` 3.4.1 Users and User Agents
`
` The term User Agent (UA) is taken from CCITT X.400 Message Handling
` Systems (MHS) Recommendations, which define it as follows: "In the
` context of message handling, the functional object, a component of
` MHS, by means of which a single direct user engages in message
`
`
`
`
`
`Kent [Page 9]
`
`009
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` handling." In the Internet environment, programs such as rand mh
` and Gnu emacs rmail are UAs. UAs exchange messages by calling on a
` supporting Message Transfer Service (MTS), e.g., the SMTP mail relays
` used in the Internet.
`
` 3.4.1.1 Generating and Protecting Component Pairs
`
` A UA process supporting PEM must protect the private component of its
` associated entity (e.g., a human user or a mailing list) from
` disclosure, though the means by which this is effected is a local
` matter. It is essential that the user take all available precautions
` to protect his private component as the secrecy of this value is
` central to the security offered by PEM to that user. For example,
` the private component might be stored in encrypted form, protected
` with a locally managed symmetric encryption key (e.g., using DES).
` The user would supply a password or passphrase which would be
` employed as a symmetric key to decrypt the private component when
` required for PEM processing (either on a per message or per session
` basis). Alternatively, the private component might be stored on a
` diskette which would be inserted by the user whenever he originated
` or received PEM messages. Explicit zeroing of memory locations where
` this component transiently resides could provide further protection.
` Other precautions, based on local operating system security
` facilities, also should be employed.
`
` It is recommended that each user employ ancillary software (not
` otherwise associated with normal UA operation) or hardware to
` generate his personal public-key component pair. Software for
` generating user component pairs will be available as part of the
` reference implementation of PEM distributed freely in the U.S.
` portion of the Internet. It is critically important that the
` component pair generation procedure be effected in as secure a
` fashion as possible, to ensure that the resulting private component
` is unpredictable. Introduction of adequate randomness into the
` component pair generation procedure is potentially the most difficult
` aspect of this process and the user is advised to pay particular
` attention to this aspect. (Component pairs employed in public-key
` cryptosystems tend to be large integers which must be "randomly"
` selected subject to mathematical constraints imposed by the
` cryptosystem. Input(s) used to seed the component pair generation
` process must be as unpredictable as possible. An example of a poor
` random number selection technique is one in which a pseudo-random
` number generator is seeded solely with the current date and time. An
` attacker who could determine approximately when a component pair was
` generated could easily regenerate candidate component pairs and
` compare the public component to the user's public component to detect
` when the corresponding private component had been found.)
`
`
`
`
`
`
`Kent [Page 10]
`
`010
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` There is no requirement imposed by this architecture that anyone
` other than the user, including any certification authority, have
` access to the user's private component. Thus a user may retain his
` component pair even if his certificate changes, e.g., due to rollover
` in the validity interval or because of a change of certifying
` authority. Even if a user is issued a certificate in the context of
` his employment, there is generally no requirement that the employer
` have access to the user's private component. The rationale is that
` any messages signed by the user are verifiable using his public
` component. In the event that the corresponding private component
` becomes unavailable, any ENCRYPTED messages directed to the user
` would be indecipherable and would require retransmission.
`
` Note that if the user stores messages in ENCRYPTED form, these
` messages also would become indecipherable in the event that the
` private component is lost or changed. To minimize the potential for
` loss of data in such circumstances messages can be transformed into
` MIC-ONLY or MIC-CLEAR form if cryptographically-enforced
` confidentiality is not required for the messages stored within the
` user's computer. Alternatively, these transformed messages might be
` forwarded in ENCRYPTED form to a (trivial) distribution list which
` serves in a backup capacity and for which the user's employer holds
` the private component.
`
` A user may possess multiple certificates which may embody the same or
` different public components. For example, these certificates might
` represent a current and a former organizational user identity and a
` residential user identity. It is recommended that a PEM UA be
` capable of supporting a user who possess multiple certificates,
` irrespective of whether the certificates associated with the user
` contain the same or different DNs or public components.
`
` 3.4.1.2 User Registration
`
` Most details of user registration are a local matter, subject to
` policies established by the user's CA and the PCA under which that CA
` has been certified. In general a user must provide, at a minimum,
` his public component and distinguished name to a CA, or a
` representative thereof, for inclusion in the user's certificate.
` (The user also might provide a complete certificate, minus the
` signature, as described in RFC 1424.) The CA will employ some means,
` specified by the CA in accordance with the policy of its PCA, to
` validate the user's claimed identity and to ensure that the public
` component provided is associated with the user whose distinguished
` name is to be bound into the certificate. (In the case of PERSONA
` certificates, described below, the procedure is a bit different.) The
` certifying authority generates a certificate containing the user's
` distinguished name and public component, the authority's
`
`
`
`
`
`Kent [Page 11]
`
`011
`
`

`

`RFC 1422 Certificate-Based Key Management February 1993
`
`
` distinguished name and other information (see Section 3.3) and signs
` the result using the private component of the authority.
`
` 3.4.1.3 CRL Management
`
` Mechanisms for managing a UA certificate cache are, in typical
` standards parlance, a local matter. However, proper maintenance of
` such a cache is critical to the correct, secure operation of a PEM UA
` and provides a basis for improved performance. Moreover, use of a
` cache permits a PEM UA to operate in the absence of directories (and
` in circumstances where directories are inaccessible). The following
` discussion provides a paradigm for one aspect of cache