RFCs in HTML Format


RFC 1422

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

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]

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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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 management, namely the processing of CRLs, the functional equivalent of which must be embodied in any PEM UA implementation compliant with this document. The specifications for CRLs used with PEM are provided in Section 3.5. X.500 makes provision for the storage of CRLs as directory attributes associated with CA entries. Thus, when X.500 directories become widely available, UAs can retrieve CRLs from directories as required. In the interim, the IPRA will coordinate with PCAs to provide a robust database facility which will contain CRLs issued by the IPRA, by PCAs, and by all CAs. Access to this database will be provided through mailboxes maintained by each PCA. Every PEM UA must provide a facility for requesting CRLs from this database using the mechanisms defined in RFC 1424. Thus the UA must include a configuration parameter which specifies one or more mailbox addresses from which CRLs may be retrieved. Access to the CRL database may be automated, e.g., as part of the certificate validation process (see Section 3.6) or may be user directed. Responses to CRL requests will employ the PEM header format specified in RFC 1421 for CRL propagation. As noted in RFC 1421, every PEM UA must be capable of processing CRLs distributed via such messages. This message format also may be employed to support a "push" (versus a "pull") model of CRL distribution, i.e., to support unsolicited distribution of CRLs. CRLs received by a PEM UA must be validated (A CRL is validated in much the same manner as a certificate, i.e., the CIC (see RFC 1113) is calculated and compared against the decrypted signature value obtained from the CRL. See Section 3.6 for additional details related to validation of certificates.) prior to being processed against any cached certificate information. Any cache entries which match CRL entries should be marked as revoked, but it is not necessary to delete cache entries marked as revoked nor to delete subordinate entries. In processing a CRL against the cache it is important to recall that certificate serial numbers are unique only for each issuer and that multiple, distinct CRLs may be issued under the same CA DN (signed using different private components), so care Kent [Page 12]
RFC 1422 Certificate-Based Key Management February 1993 must be exercised in effecting this cache search. (This situation may arise either because an organizational CA is certified by multiple PCAs, or because multiple residential CAs are certified under different PCAs.) This procedure applies to cache entries associated with PCAs and CAs, as well as user entries. The UA also must retain each CRL to screen incoming messages to detect use of revoked certificates carried in PEM message headers. Thus a UA must be capable of processing and retaining CRLs issued by the IPRA (which will list revoked PCA certificates), by any PCA (which will list revoked CA certificate issued by that PCA), and by any CA (which will list revoked user or subordinate CA certificates issued by that CA). 3.4.1.4 Facilitating Interoperation In the absence of ubiquitous directory services or knowledge (acquired through out-of-band means) that a recipient already possesses the necessary issuer certificates, it is recommended that an originating (PEM) UA include sufficient certificates to permit validation of the user's public key. To this end every PEM UA must be capable of including a full (originator) certification path, i.e., including the user's certificate (using the "Originator-Certificate" field) and every superior (CA/PCA) certificate (using "Issuer- Certificate" fields) back to the IPRA, in a PEM message. A PEM UA may send less than a full certification path, e.g., based on analysis of a recipient list, but a UA which provides this sort of optimization must also provide the user with a capability to force transmission of a full certification path. Optimization for the transmitted originator certification path may be effected by a UA as a side effect of the processing performed during message submission. When an originator submits an ENCRYPTED message (as per RFC 1421, his UA must validate the certificates of the recipients (see Section 3.6). In the course of performing this validation the UA can determine the minimum set of certificates which must be included to ensure that all recipients can process the received message. Submission of a MIC-ONLY or MIC-CLEAR message (as per RFC 1421) does not entail validation of recipient certificates and thus it may not be possible for the originator's UA to determine the minimum certificate set as above. 3.4.2 The Internet Policy Registration Authority (IPRA) The IPRA acts as the root of the certification hierarchy for the Internet community. The public component of the IPRA forms the foundation for all certificate validation within this hierarchy. The IPRA will be operated under the auspices of the Internet Society, an Kent [Page 13]
RFC 1422 Certificate-Based Key Management February 1993 international, non-profit organization. The IPRA certifies all PCAs, ensuring that they agree to abide by the Internet-wide policy established by the IPRA. This policy, and the services provided by the IPRA, are detailed below. 3.4.2.1 PCA Registration The IPRA certifies only PCAs, not CAs or users. Each PCA must file with the IPRA a description of its proposed policy. This document will be published as an informational RFC. A copy of the document, signed by the IPRA (in the form of a PEM MIC-ONLY message) will be made available via electronic mail access by the IPRA. This convention is adopted so that every Internet user has a reference point for determining the policies associated with the issuance of any certificate which he may encounter. The existence of a digitally signed copy of the document ensures the immutability of the document. Authorization of a PCA to operate in the Internet hierarchy is signified by the publication of the policy document, and the issuance of a certificate to the PCA, signed by the IPRA. An outline for PCA policy statements is contained in Section 3.4.3 of this document. As part of registration, each PCA will be required to execute a legal agreement with the IPRA, and to pay a fee to defray the costs of operating the IPRA. Each a PCA must specify its distinguished name. The IPRA will take reasonable precautions to ensure that the distinguished name claimed by a PCA is legitimate, e.g., requiring the PCA to provide documentation supporting its claim to a DN. However, the certification of a PCA by the IPRA does not constitute a endorsement of the PCA's claim to this DN outside of the context of this certification system. 3.4.2.2 Ensuring the Uniqueness of Distinguished Names A fundamental requirement of this certification scheme is that certificates are not issued to distinct entities under the same distinguished name. This requirement is important to the success of distributed management for the certification hierarchy. The IPRA will not certify two PCAs with the same distinguished name and no PCA may certify two CAs with the same DN. However, since PCAs are expected to certify organizational CAs in widely disjoint portions of the directory namespace, and since X.500 directories are not ubiquitous, a facility is required for coordination among PCAs to ensure the uniqueness of CA DNs. (This architecture allows multiple PCAs to certify residential CAs and thus multiple, distinct residential CAs with identical DNs may come into existence, at least until such time as civil authorities assume responsibilities for such certification. Thus, on an interim basis, the architecture explicitly accommodates the potential for duplicate residential CA Kent [Page 14]
RFC 1422 Certificate-Based Key Management February 1993 DNs.) In support of the uniqueness requirement, the IPRA will establish and maintain a database to detect potential, unintended duplicate certification of CA distinguished names. This database will be made accessible to all PCAs via an email interface. Each entry in this database will consist of a 4-tuple. The first element in each entry is a hash value, computed on a canonical, ASN.1 encoded representation of a CA distinguished name. The second element contains the subjectPublicKey that appears in the CA's certificate. The third element is the distinguished name of the PCA which registered the entry. The fourth element consists of the date and time at which the entry was made, as established by the IPRA. This database structure provides a degree of privacy for CAs registered by PCAs, while providing a facility for ensuring global uniqueness of CA DNs certified in this scheme. In order to avoid conflicts, a PCA should query the database using a CA DN hash value as a search key, prior to certifying a CA. The database will return any entries which match the query, i.e., which have the same CA DN. The PCA can use the information contained in any returned entries to determine if any PCAs should be contacted to resolve possible DN conflicts. If no potential conflicts appear, a PCA can then submit a candidate entry, consisting of the first three element values, plus any entries returned by the query. The database will register this entry, supplying the time and date stamp, only if two conditions are met: (1) the first two elements (the CA DN hash and the CA subjectPublicKey) of the candidate entry together must be unique and, (2) any other entries included in the submission must match what the current database would return if the query corresponding to the candidate entry were submitted. If the database detects a conflicting entry (failure of case 1 above), or if the submission indicates that the PCA's perception of possible conflicting entries is not current (failure of case 2), the submission is rejected and the database will return the potential conflicting entry (entries). If the submission is successful, the database will return the timestamped new entry. The database does not, in itself, guarantee uniqueness of CA DNs as it allows for two DNs associated with different public components to be registered. Rather, it is the responsibility of PCAs to coordinate with one another whenever the database indicates a potential DN conflict and to resolve such conflicts prior to certification of CAs. Details of the protocol used to access the database will be provided in another document. As noted earlier, a CA may be certified under more than one PCA, e.g., because the CA wants to issue certificates under two different Kent [Page 15]
RFC 1422 Certificate-Based Key Management February 1993 policies. If a CA is certified by multiple different PCAs, the CA must employ a different public key pair for each PCA. In such circumstances the certificate issued to the CA by each PCA will contain a different subjectPublicKey and thus will represent a different entry in this database. The same situation may arise if multiple, equivalent residential CAs are certified by different PCAs. To complete the strategy for ensuring uniqueness of DNs, there is a DN subordination requirement levied on CAs. In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN. This ensures that certificates issued by a CA are syntactically constrained to refer to subordinate entities in the X.500 directory information tree (DIT), and this further limits the possibility of duplicate DN registration. CAs may sign certificates which do not comply with this requirement if the certificates are "cross-certificates" or "reverse certificates" (see X.509) used with applications other than PEM. The IPRA also will establish and maintain a separate database to detect potential duplicate certification of (residential) user distinguished names. Each entry in this database will consist of 4- tuple as above, but the first components is the hash of a residential user DN and the third component is the DN of the residential CA DN which registered the user. This structure provides a degree of privacy for users registered by CAs which service residential users while providing a facility for ensuring global uniqueness of user DNs certified under this scheme. The same database access facilities are provided as described above for the CA database. Here it is the responsibility of the CAs to coordinate whenever the database indicates a potential conflict and to resolve the conflict prior to (residential) user certification. 3.4.2.3 Accuracy of Distinguished Names As noted above, the IPRA will make a reasonable effort to ensure that PCA DNs are accurate. The procedures employed to ensure the accuracy of a CA distinguished name, i.e., the confidence attached to the DN/public component binding implied by a certificate, will vary according to PCA policy. However, it is expected that every PCA will make a good faith effort to ensure the legitimacy of each CA DN certified by the PCA. Part of this effort should include a check that the purported CA DN is consistent with any applicable national standards for DN assignment, e.g., NADF recommendations within North America [5,9]. Kent [Page 16]
RFC 1422 Certificate-Based Key Management February 1993
RFC 1422 Certificate-Based Key Management February 1993 certificate cache must maintain all of the information contained in a certificate, not just the DNs and the public component. For example the serial number and validity interval must be associated with the cache entry to comply with the checks described above. Also note that these procedures apply to human interaction in message submission and delivery and are not directly applicable to forwarding processes. When non human interaction is involved, a compliant PEM implementation must provide parameters to enable a process to specify whether certificate validation will succeed or fail if any of the conditions arise which would result in warnings to a human user. Finally, in the course of validating certificates as described above, one additional check must be performed: the subject DN of every certificate must be subordinate to the certificate issuer DN, except if the issuer is the IPRA or a PCA (hence another reason to distinguish the IPRA and PCA entries in a certificate cache). This requirement is levied upon all PEM implementations as part of maintaining the certification hierarchy constraints defined in this document. Any certificate which does not comply with these requirements is considered invalid and must be rejected in PEM submission or delivery processing. The user must be notified of the nature of this fatal error. Kent [Page 28]
RFC 1422 Certificate-Based Key Management February 1993 A. Appendix A: ASN.1 Syntax for Certificates and CRLs A.1 Certificate Syntax The X.509 certificate format is defined by the following ASN.1 syntax: Certificate ::= SIGNED SEQUENCE{ version [0] Version DEFAULT v1988, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo} Version ::= INTEGER {v1988(0)} CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE{ notBefore UTCTime, notAfter UTCTime} SubjectPublicKeyInfo ::= SEQUENCE{ algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING} AlgorithmIdentifier ::= SEQUENCE{ algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL} The components of this structure are defined by ASN.1 syntax defined in the X.500 Series Recommendations. RFC 1423 provides references for and the values of AlgorithmIdentifiers used by PEM in the subjectPublicKeyInfo and the signature data items. It also describes how a signature is generated and the results represented. Because the certificate is a signed data object, the distinguished encoding rules (see X.509, section 8.7) must be applied prior to signing. Kent [Page 29]
RFC 1422 Certificate-Based Key Management February 1993 A.2 Certificate Revocation List Syntax The following ASN.1 syntax, derived from X.509 and aligned with the suggested format in recently submitted defect reports, defines the format of CRLs for use in the PEM environment. CertificateRevocationList ::= SIGNED SEQUENCE{ signature AlgorithmIdentifier, issuer Name, lastUpdate UTCTime, nextUpdate UTCTime, revokedCertificates SEQUENCE OF CRLEntry OPTIONAL} CRLEntry ::= SEQUENCE{ userCertificate SerialNumber, revocationDate UTCTime} References [1] CCITT Recommendation X.411 (1988), "Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures". [2] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework". [3] CCITT Recommendation X.520 (1988), "The Directory - Selected Attribute Types". [4] NIST Special Publication 500-183, "Stable Agreements for Open Systems Interconnection Protocols," Version 4, Edition 1, December 1990. [5] North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, NADF, September 1991. [6] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, DEC, February 1993. [7] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, February 1993. [8] Balaski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services", RFC 1424, RSA Laboratories, February 1993. Kent [Page 30]
RFC 1422 Certificate-Based Key Management February 1993 [9] North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, NADF, February 1993. Patent Statement This version of Privacy Enhanced Mail (PEM) relies on the use of patented public key encryption technology for authentication and encryption. The Internet Standards Process as defined in RFC 1310 requires a written statement from the Patent holder that a license will be made available to applicants under reasonable terms and conditions prior to approving a specification as a Proposed, Draft or Internet Standard. The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents: Cryptographic Apparatus and Method ("Diffie-Hellman")............................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle").................... No. 4,218,582 Cryptographic Communications System and Method ("RSA")................................... No. 4,405,829 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig").................... No. 4,424,414 These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal. Public Key Partners has provided written assurance to the Internet Society that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. This assurance is documented in RFC 1170 titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA). The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above Kent [Page 31]
RFC 1422 Certificate-Based Key Management February 1993 have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility.



Back to RFC index

 

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""