9 March 1992 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management STATUS OF THIS MEMO This draft document will be submitted to the RFC editor as a standards document, and is submitted as a proposed successor to RFC 1114. References within the text of this Internet-Draft to this document as an RFC, or to related Internet-Drafts cited as "RFC [1113E]", "RFC [1115C]", and "RFC [FORMS-C]" are not intended to carry any connotation about the progression of these Internet-Drafts through the IAB standards-track review cycle. Distribution of this memo is unlimited. This specification was developed by the PEM Working Group of the IETF, based on work initiated in the Internet Research Task Force's Privacy and Security Research Group. Comments should be sent to . This RFC specifies a key management infrastructure for use the Internet community, and requests discussion and suggestions for improvements. ACKNOWLEDGMENT This RFC is the outgrowth of a series of meetings of the Privacy and Security Research Group of the IRTF and the PEM Work Group of the 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 RFC. I also would like to thank contributors to the PEM-DEV mailing list who have provided valuable input which is reflected in this RFC. 1 Executive Summary This is one of a series of RFCs defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. RFC [1113E] 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 [1115C] specifies algorithms, modes and associated identifiers for use in processing privacy-enhanced Kent (BBN) [Page 1] PEM-1114E Certificate-Based Key Management March 1992 messages, as called for in RFC [1113E] and this RFC. This RFC defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients. RFC [FORMS-C] provides additional specifications for services in conjunction with the key management infrastructure described herein. The key management architecture described in this RFC is compatible with the authentication framework described in CCITT 1988 X.509 [2]. This RFC goes beyond X.509 by establishing 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 Kent (BBN) [Page 2] PEM-1114E Certificate-Based Key Management March 1992 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 RFC establishes a single root for all certification within the Internet, the Internet Certification Authority (ICA). The ICA establishes global policies, described in this RFC, which apply to all certification effected under this hierarchy. Beneath ICA 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 ICA. (1) 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. _______________ (1) 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. Kent (BBN) [Page 3] PEM-1114E Certificate-Based Key Management March 1992 2 Overview of Approach This RFC 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 [1113E]. 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 (2) 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 key of each recipient and to provide each recipient with the (authenticated) public key 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 ICA) or is itself distributed in a certificate to which this validation procedure is applied recursively. In the _______________ (2) Throughout this RFC we have adopted 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. Kent (BBN) [Page 4] PEM-1114E Certificate-Based Key Management March 1992 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 [1113E]. 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 ICA 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. 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 [1113E] describes the Kent (BBN) [Page 5] PEM-1114E Certificate-Based Key Management March 1992 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 [1115C] to facilitate the adoption of additional algorithms in the future. This RFC 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 ICA 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 ICA and every CA must be certified by a PCA. 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. Kent (BBN) [Page 6] PEM-1114E Certificate-Based Key Management March 1992 Although the key management architecture described in this RFC 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 RFC interprets the X.509 certificate mechanism to serve the needs of PEM in the Internet environment. The certification hierarchy proposed in this RFC 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: 1. version Kent (BBN) [Page 7] PEM-1114E Certificate-Based Key Management March 1992 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. 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 processing of this attribute need not involve any arithmetic operations. All PEM implementations must be capable of processing serial numbers up to 48 bits in length and support for larger 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. (3) _______________ (3) The certificate signature is appended to the data structure, Kent (BBN) [Page 8] PEM-1114E Certificate-Based Key Management March 1992 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 to signing by a CA (ICA, 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 [1115C] 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. (4) The issuer is the certifying _______________ as defined by the signature macro in X.509. This algorithm identification information is replicated with the signature. (4) 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. Kent (BBN) [Page 9] PEM-1114E Certificate-Based Key Management March 1992 authority (ICA, 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 values recorded here specify granularity to no more than the minute, even though finer granularity can be expressed in the format. It also recommended that all times be expressed as Greenwhich Mean Time (Zulu), to simplify comparisons and avoid confusion relating to daylight savings time. 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 [1115C] specifies the algorithm identifiers which may be used in this context. Kent (BBN) [Page 10] PEM-1114E Certificate-Based Key Management March 1992 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 Certification Authority, Policy Certification Authorities, and other Certification Authorities. For each type of entity this document the procedures which the entity must execute as part of the architecture and what 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 handling." UAs exchange messages by calling on a supporting Message Transfer Service (MTS), e.g., the SMTP mail relays used in the Interent. 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. Kent (BBN) [Page 11] PEM-1114E Certificate-Based Key Management March 1992 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. 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 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. Kent (BBN) [Page 12] PEM-1114E Certificate-Based Key Management March 1992 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 [FORMS-C].) 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 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, as well as providing a basis for improved performance. 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 RFC. 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, a (replicated) database will be maintained by the ICA which contains CRLs for all PCAs and CAs. Every PEM UA must provide a facility for fetching CRLs from this database using the mechanisms defined in RFC [FORMS-C]. 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. In addition, a "push" (vs. "pull") model of CRL distribution is provided through the definition Kent (BBN) [Page 13] PEM-1114E Certificate-Based Key Management March 1992 of a PEM header format specifically for CRL propagation (see RFC [1113E]). As noted in RFC [1113E], every PEM UA must be capable of processing CRLs distributed via such messages. Upon receipt and validation of a CRL, (5) A PEM UA must compare the CRL entries against any cached certificate information, and must mark as revoked any cache entries which match CRL entries. (Recall that the certificate serial numbers are unique only for each issuer, so care must be exercised in effecting this cache search.) 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 ICA (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 CA certificates issued by that CA). 3.4.1.4 Facilitating Interoperation In the absence of ubiquitous directory services or knowledge that a recipient already possesses the necessary issuer certificates, it is recommended that an originating (PEM) UA include appropriate certificates (using the "Issuer-Certificate" field) when communicating with a recipient who is certified by other that the originator's CA. When an originator submits an ENCRYPTED message (as per RFC [1113E], his UA must validate the certificates of the recipients (see Section 3.6). In the course of performing this validation the UA can determine if any of the recipients are registered under a CA other than the originator's CA. The UA also can determine if any recipients are certified under a PCA other than the one under which the originator is certified. In these circumstances, the originator's UA could include his CA and PCA certificates to facilitate validation of the user's certificate by the recipient's UA. It is recommended that PEM software include a provision for the user to specify the automatic inclusion of the _______________ (5) A CRL is validated in much the same manner as a certificate, i.e., the CIC 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. Kent (BBN) [Page 14] PEM-1114E Certificate-Based Key Management March 1992 minimum set of appropriate certificates (using "Issuer-Certificate" fields in the PEM header) when submitting an ENCRYPTED message, either on a per-message or default basis. Submission of a MIC-ONLY or MIC-CLEAR message (as per RFC [1113D) does not entail validation of recipient certificates and thus it is not possible for the originator's UA to determine automatically that a recipient might require CA or PCA certificates to validate the message signature. Thus it is recommended that PEM software provide an interface to allow the user to explicitly include a certification path back to the ICA root (using "Issuer-Certificate" fields in the PEM header) when submitting MIC-CLEAR or MIC-ONLY messages. Here too it is recommended that this facility be available on either a per- message or default basis. 3.4.2 The Internet Certification Authority (ICA) The ICA acts as the root of the certification hierarchy for the Internet community. The public component of the ICA forms the foundation for all certificate validation within this hierarchy. The ICA will be operated under the auspices of the Internet Society, an international, non-profit organization [ISOC92]. The ICA certifies all PCAs, ensuring that they agree to abide by the Internet-wide policy established by the ICA. This policy, and the services provided by the ICA, are detailed below. 3.4.2.1 PCA Registration The ICA certifies only PCAs, not CAs or users. Each PCA must file with the ICA a description of its proposed policy. This document will be published as an informational RFC. A copy of the document, signed by the ICA (in the form of a PEM MIC-ONLY message) will be made available via electronic mail access by the ICA. 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 ICA. An outline for PCA Kent (BBN) [Page 15] PEM-1114E Certificate-Based Key Management March 1992 policy statements is contained in Section 3.4.3 of this document. As part of registration, a PCA specifies its distinguished name. The ICA 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 ICA 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 crucial to the success of distributed management for the certification hierarchy. The ICA will not certify two PCAs with the same distinguished name. Since PCAs are expected to certify 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. In support of the uniqueness requirement, the ICA 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. 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 public component of the CA. 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 ICA. 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 must 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. A PCA can submit a candidate entry, consisting of the first three tuple values, and the database will register this entry, supplying the time and date stamp, if the first two elements Kent (BBN) [Page 16] PEM-1114E Certificate-Based Key Management March 1992 (the CA DN hash and the CA public component) together are unique. If there is a conflict, the database will return the conflicting 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 are contained in Appendix B. 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 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 public component and thus will represent a different entry in this database. 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 ICA 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, substituting a user's distinguished name and public component in lieu of a CA name and public component. 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. Kent (BBN) [Page 17] PEM-1114E Certificate-Based Key Management March 1992 3.4.2.3 Accuracy of Distinguished Names As noted above, the ICA 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 [RFC-NADF]. 3.4.2.4 Distinguished Name Conventions A few basic DN conventions are included in the ICA policy. The ICA will certify PCAs, but not CAs nor users. PCAs will certify CAs, but not users. These conventions are required to allow simple certificate validation within PEM, as described later. Certificates issued by CAs (for use with PEM) will be for users or for other CAs, either of which must have DNs subordinate to that of the issuing CA. The attributes employed in constructing DNs will be specified in a list maintained by the IANA, to provide a coordinated basis for attribute identification for all applications employing DNs. This list will initially be populated with attributes taken from X.520. This document does not impose detailed restrictions on the attributes used to identify different entities to which certificates are issued, but PCAs may impose such restrictions as part of their policies. PCAs, CAs and users are urged to employ only those DN attributes which have printable representations, to facilitate display and entry. 3.4.2.5 CRL Management Among the procedures articulated by each PCA in its policy statement are procedures for the maintenance and distribution of CRLs by the PCA itself and by its subordinate CAs. The frequency of issue of CRLs may vary according to PCA-specific policy, but every PCA and CA must issue a CRL upon inception to provide a basis for uniform Kent (BBN) [Page 18] PEM-1114E Certificate-Based Key Management March 1992 certificate validation procedures throughout the Internet hierarchy. The format for these CRLs is that specified in Section 3.5.2 of the document. The ICA will maintain a CRL for all the PCAs it certifies and this CRL will be updated monthly. Each PCA will maintain a CRL for all of the CAs which it certifies and these CRLs will be updated biweekly. The ICA will establish and maintain a database to hold CRLs for the Internet hierarchy, i.e., the ICA CRL, PCA CRLs, and CRLs from all CAs. This database will be accessible via email as specified in RFC [FORMS-C], both for retrieval of (current) CRLs and for entering new CRLs. Individual PCAs may elect to maintain CRL archives for their CAs, but this is not required by this policy. 3.4.2.6 Public Key Algorithm Licensing Issues This certification hierarchy is architecturally independent of any specific digital signature (public key) algorithm. Some algorithms, employed for signing certificates and validating certificate signatures, are patented in some countries. The ICA will not grant a license to any PCA for the use of any signature algorithm in conjunction with the management of this certification hierarchy. The ICA will acquire, for itself, any licenses needed for it to sign certificates and CRLs for PCAs, for all algorithms which the ICA supports. Every PCA will be required to represent to the ICA that the PCA has obtained any licenses required to issue (sign) certificates and CRLs in the environment(s) which the PCA will serve. For example, the RSA cryptosystem is patented in the United States and thus any PCA operating in the U.S. and using RSA to sign certificates and CRLs must represent that it has a valid license to employ the RSA algorithm in this fashion. In contrast, a PCA employing RSA and operating outside of the U.S. would represent that it is exempt from these licensing constraints. Kent (BBN) [Page 19] PEM-1114E Certificate-Based Key Management March 1992 3.4.3 Policy Certification Authorities The policy statement submitted by a prospceptive PCA must address the topics in the following outline. Additional policy information may be contained in the statement, but PCAs are requested not to use these statements as advertising vehicles. 1. PCA Identity- The DN of the PCA must be specified. A postal address, an Internet mail address, and telephone (and optional fax) numbers must be provided. The date on which this statement is effective, and its scheduled duration must be specified. 2. PCA Scope- Each PCA must describe the community which the PCA plans to serve. A PCA should indicate if it will certify organizational, residential, and/or PERSONA CAs. There is not a requirement that a single PCA serve only one type of CA, but if a PCA serves multiple types of CAs, the policy statement must specify clearly how a user can distinguish among these classes. If the PCA will operate CAs to directly serve residential or PERSONA users, it must so state. 3. PCA Security & Privacy- Each PCA must specify the technical and procedural security measures it will employ in the generation and protection of its component pair. If any security requirements are imposed on CAs certified by the PCA these must be specified as well. A PCA also must specify what measures it will take to protect the privacy of any information collected in the course of certifying CAs. If the PCA operates one or more CAs directly, to serve residential or PERSONA users, then this statement on privacy measures applies to these CAs as well. 4. Certification Policy- Each PCA must specify the policy and procedures which govern its certification of CAs and how this policy applies transitively to entities (users or subordinate CAs) certified by these CAs. For example, a PCA must state what procedure is employed to verify the claimed identity of a CA, and the CA's right to use a DN. Similarly, if any requirments are imposed on CAs to validate the identity of users, these requirements must be specified. Since all PCAs are required to cooperate in the resolution of potential DN conflicts, each PCA is required to specify the procedure it will employ to resolve such conflicts. If the PCA imposes a maximum validity interval for the CA certificates it issues, and/or for user (or subordinate CA) certifificates issued by the CAs it certifies, then these restrictions must be specified. Kent (BBN) [Page 20] PEM-1114E Certificate-Based Key Management March 1992 5. CRL Management- Each PCA must specifiy any constraints it imposes in the frequency of issue of CRLs by the CAs it certifies, or by entities certified by these CAs. Both maximum and minimum constraints should be specified. Since the ICA policy calls for a copy of each CRL issued by a CA to be forwarded to the cognizant PCA, each PCA must specify a mailbox to which CRLs are to be transmitted. If the PCA offers any additional CRL managmement services, e.g., archiving of old CRLs, then procedures for invoking these services must be specified. If the PCA requires CAs to provide any additional CRL management services, such services must be specified here. 6. Naming Conventions- If the PCA imposes any conventions on DNs used by the CAs it certifies, or by entities certified by these CAs, these conventions must be specified. If any sematics are associated with such conventions, these semantics must be specified. 7. Business Issues- If a legal agreement must be executed between a PCA and the CAs it certifies, reference to that agreement must be noted, but the agreeement itself ought not be a part of the policy statement. Similarly, if any fees are charged by the PCA this should be noted, but the fee structure per se ought not be part of this policy statement. 8. Other- Any other topics the PCA deems relevant to a statement of its policy can be included. However, the PCA should be aware that a policy statement is considered to be an immutable, long lived doucument and thus considerable care should be exercised in deciding what material is to be included in the statement. 3.4.4 Certification Authorities In X.509 the term "certification authority" is defined as "an authority trusted by one or more users to create and assign certificates". X.509 imposes few constraints on CAs, but practical implementation of a worldwide certification system requires establishment of technical and procedural conventions by which all CAs are expected to abide. Such conventions are established throughout this RFC. It is critical that the private component of a CA be afforded a high level of security, otherwise the authenticity guarantee implied by certificates signed by the CA is voided. Some PCAs may impose Kent (BBN) [Page 21] PEM-1114E Certificate-Based Key Management March 1992 stringent requirements on CAs within their purview to ensure that a high level of security is afforded the certificate signing process, but not all PCAs are expected to impose such constraints. 3.4.4.1 Organizational CAs Many of the CAs certified by PCAs are expected to represent organizations. A wide range of organizations are encompassed by this model: commercial, governmental, educational, non-profit, professional societies, etc. The common thread is that the entities certified by these CAs have some form of affiliation with the organization. The object classes for organizations, organizational units, organizational persons, organizational roles, etc., as defined in X.521, form the models for entities certified by such CAs. The affiliation implied by organizational certification motivates the DN subordination requirement cited in Section 3.4.2.4. As an example, an organizational user certificate might contain a subject DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge" O = "Bolt Beranek and Newman" OU = "Communications Division" CN = "Steve Kent". The issuer of this certificate might have a DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek and Newman". Note that the organizational unit attribute is omitted from the issuer DN, implying that there is no CA dedicated to the "Communications Division". 3.4.4.2 Residential CAs Users may wish to obtain certificates which do not imply any organizational affiliation but which do purport to accurately and uniquely identify them. Such users can be registered as residential persons and the DN of such a user should be consistent with the attributes of the corresponding X.521 object class. Over time we anticipate that such users will be accommodated by civil government entities who will assume electronic certification responsibility at geographically designated points in the naming hierarchy. Until civil authorities are prepared to issue certificates of this form, residential user CAs will accommodate such users. Kent (BBN) [Page 22] PEM-1114E Certificate-Based Key Management March 1992 As an example, a residential user certificate might include a subject name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19 North Square" CN = "Paul Revere." The issuer of that certificate might have a DN of the form: C = "US" S = "Massachusetts" L = "Boston". Note that the issuer DN is superior to the subject DN, as required by the ICA policy described earlier. 3.4.4.3 PERSONA CAs One or more CAs will be established to accommodate users who wish to conceal their identities while making use of PEM security features, e.g., to preserve the anonymity offered by "arbitrary" mailbox names in the current mail environment. In this case the certifying authority is explicitly NOT vouching for the identity of the user. All such certificates are issued under a PERSONA CA, subordinate to a PCA with a PESONA policy, to warn users explicitly that the subject DN is NOT a validated user identity. To minimize the possibility of syntactic confusion with certificates which do purport to specify an authenticated user identity, a PERSONA certificate is issued as a form of organizational user certificate, not a residential user certificate. There are no explicit, reserved words used to identify PERSONA user certificates. A CA issuing PERSONA certificates must institute procedures to ensure that it does not issue the same subject DN to multiple users (a constraint required for all certificates of any type issued by any CA). There are no requirements on an issuer of PERSONA certificates to maintain any other records that might bind the true identity of the subject to his certificate. However, a CA issuing such certificates must establish procedures (not specified in this RFC) in order to allow the holder of a PESRONA certificate to request that the certificate be revoked (i.e., listed on a CRL). As an example, a PERSONA user certificate might include a subject DN of the form: C = "US" SP = "Massachusetts" L = "Boston" O = "Pseudonyms R US" CN = "Paul Revere." The issuer of this certificate might have a DN of the form: C = "US" S = "Massachusetts" L = "Boston" O = "Pseudonyms R US". Note the differences between this PERSONA user certificate for "Paul Revere" and the corresponding residential user certificate for the same common name. Kent (BBN) [Page 23] PEM-1114E Certificate-Based Key Management March 1992 3.4.4.4 CA Responsibilities for CRL Management As X.500 directory servers become available, CRLs should be maintained and accessed via these servers. However, prior to widespread deployment of X.500 directories, this RFC adopts some additional requirements for CRL management by CAs and PCAs. As per X.509, each CA is required to maintain a CRL (in the format specified by this RFC in Appendix A) which contains entries for all certificates issued and later revoked by the CA. Once a certificate is entered on a CRL it remains there until the validity interval expires. Each PCA is required to maintain a CRL for revoked CA certificates within its domain. The interval at which a CA issues a CRL is not fixed by this RFC, but the PCAs may establish minimum and maximum intervals for such issuance. As noted earlier, the ICA will operate a database containing CRLs for all PCAs and CAs. In support of this requirement, each CA must supply its current CRL to its PCA in a fashion consistent with CRL issuance rules imposed by the PCA and with the next scheduled issue date specified by the CA (see Section 3.5.1) Each CA will simultaneously forward its CRL to the ICA-maintained database. CAs may transfer CRLs to subordinate UAs using the CRL processing type available in PEM messages (see RFC [1113E]). CAs also may provide access to CRLs via the database mechanism described in RFC [FORMS-C] and alluded to immediately above. 3.5 Certificate Revocation 3.5.1 X.509 CRLs X.509 states that it is a CA's responsibility to maintain: "a time- stamped list of the certificates it issued which have been revoked." There are two primary reasons for a CA to revoke a certificate, i.e., suspected compromise of a private component (invalidating the corresponding public component) or change of user affiliation (invalidating the DN). The use of Certificate Revocation Lists (CRLs) as defined in X.509 is one means of propagating information relative to certificate revocation, though it is not a perfect mechanism. In particular, an X.509 CRL indicates only the age of the information contained in it; it does not provide any basis for determining if the list is the most current CRL available from a given CA. Kent (BBN) [Page 24] PEM-1114E Certificate-Based Key Management March 1992 The proposed architecture establishes a format for a CRL in which not only the date of issue, but also the next scheduled date of issue is specified. Adopting this convention, when the next scheduled issue date arrives a CA (6) will issue a new CRL, even if there are no changes in the list of entries. In this fashion each CA can independently establish and advertise the frequency with which CRLs are issued by that CA. Note that this does not preclude CRL issuance on a more frequent basis, e.g., in case of some emergency, but no system-wide mechanisms are architected for alerting users that such an unscheduled issuance has taken place. This scheduled CRL issuance convention allows users (UAs) to determine whether a given CRL is "out of date," a facility not available from the (1988) X.509 CRL format. The description of CRL management in the text and the format for CRLs specified in X.509 (1988) are inconsistent. For example, the latter associates an issuer distinguished name with each revoked certificate even though the text states that a CRL contains entries for only a single issuer (which is separately specified in the CRL format). The CRL format adopted for PEM is a (simplified) format consistent with the text of X.509, but not identical to the accompanying format. The ASN.1 format for CRLs used with PEM is provided in Appendix A. X.509 also defines a syntax for the "time-stamped list of revoked certificates representing other CAs." This syntax, the "AuthorityRevocationList" (ARL) allows the list to include references to certificates issued by CAs other than the list maintainer. There is no syntactic difference between these two lists except as they are stored in directories. Since PEM is expected to be used prior to widespread directory deployment, this distinction between ARLs and CRLs is not syntactically significant. As a simplification, this RFC specifies the use the CRL format defined below for revocation both of user and of CA certificates. _______________ (6) Throughout this section, when the term "CA" is employed, it should be interpreted broadly, to include the ICA and PCAs as well as organizational, residential, and PERSONA CAs. Kent (BBN) [Page 25] PEM-1114E Certificate-Based Key Management March 1992 3.5.2 PEM CRL Format Appendix A contains the ASN.1 description of CRLs specified by this RFC. This section provides an informal description of CRL components analogous to that provided for certificates in Section 3.3. 1. signature (signature algorithm ID and parameters) 2. issuer 3. last update 4. next update 5. revoked certificates The "signature" is a data item completely analogous to the signature data item in a certificate. Similarly, the "issuer" is the DN of the CA which signed the CRL. The "last update" and "next update" fields contain time and date values (UTCT format) which specify, respectively, when this CRL was issued and when the next CRL is scheduled to be issued. Finally, "revoked certificates" is a sequence of ordered pairs, in which the first element is the serial number of the revoked certificate and the second element is the time and date of the revocation for that certificate. The semantics for this second element are not made clear in X.509. For example, the time and date specified might indicate when a private component was thought to have been compromised or it may reflect when the report of such compromise was reported to the CA. For uniformity, this RFC adopts the latter convention, i.e., the revocation date specifies the time and date at which a CA formally acknowledges a report of a compromise or a change or DN attributes. As with certificates, it is recommended that the UTCT values be of no finer granularity than minutes and that all values be stated in terms of Zulu. Kent (BBN) [Page 26] PEM-1114E Certificate-Based Key Management March 1992 3.6 Certificate Validation 3.6.1 Validation Basics Every UA must contain the public component of the ICA as the root for its certificate validation database. Public components associated with PCAs must be identified as such, so that the certificate validation process described below can operate correctly. Whenever a certificate for a PCA is entered into a UA cache, e.g., if encountered in a PEM message encapsulated header, the certificate must NOT be entered into the cache automatically. Rather, the user must be notified and must explicitly direct the UA to enter any PCA certificate data into the cache. This precaution is essential because introduction of a PCA certificate into the cache implies user recognition of the policy associated with the PCA. Validating a certificate begins with verifying that the signature affixed to the certificate is valid, i.e., that the hash value computed on the certificate contents matches the value that results from decrypting the signature field using the public component of the issuer. In order to perform this operation the user must possess the public component of the issuer, either via some integrity-assured channel, or by extracting it from another (validated) certificate. In order to rapidly terminate this recursive validation process, we recommend each PCA sign certificates for all CAs within its domain, even CAs which are certified by other, superior CAs in the certification hierarchy. The public component needed to validate certificates signed by the ICA is made available to each user as part of the registration or via the PEM installation process. Thus a user will be able to validate any PCA certificate immediately. CAs are certified by PCAs, so validation of a CA certificate requires processing a validation path of length two. User certificates are issued by CAs (either immediately subordinate to PCAs or subordinate to other CAs), thus validation of a user certificate may require three or more steps. Local caching of validated certificates by a UA can be used to speed up this process significantly. Consider the situation in which a user receives a privacy enhanced message from an originator with whom the recipient has never previously corresponded, and assume that the message originator includes all the requisite certificates in the PEM message header. First the recipient can use the ICA's public component to validate a Kent (BBN) [Page 27] PEM-1114E Certificate-Based Key Management March 1992 PCA certificate contained in an Issuer-Certificate field. Using the PCA's public component extracted from this certificate, the CA certificate in an Issuer-Certificate field also can be validated. This process cam be repeated until the certificate for the originator, from the User-Certificate field, is validated. Having performed this certificate validation process, the recipient can extract the originator's public component and use it to decrypt the content of the MIC-Info field. By comparing the decrypted contents of this field against the MIC computed locally on the message the user verifies the data origin authenticity and integrity of the message. It is recommended that implementations of privacy enhanced mail cache validated public components (acquired from incoming mail) to speed up this process. If a message arrives from an originator whose public component is held in the recipient's cache, the recipient can immediately employ that public component without the need for the certificate validation process described here. Also note that the arithmetic required for certificate validation is considerably faster than that involved in digitally signing a certificate, so as to minimize the computational burden on UAs. 3.6.2 Display of Certificate Validation Data PEM provides authenticated identities for message recipients and originators expressed in the form of distinguished names. Mail systems in which PEM is employed may not employ DNs as the primary means of identifying recipients or originators. Thus, in order to benefit from these authentication facilities, each PEM implementation must employ some means of binding native mail system identifiers to distinguished names in a fashion which does not undermine this basic PEM functionality. For example, if a human user interacts directly with PEM, then the full DN of the originator of any message received using PEM should be displayed for the user. Merely displaying the PEM-protected message content, containing an originator name from the native mail system, does not provide equivalent security functionality and could allow spoofing. If the recipient of a message is a forwarding agent such as a list exploder or mail relay, display of the originator's DN is not a relevant requirement. In all cases the essential requirement is that the ultimate recipient of a PEM message be able to ascertain Kent (BBN) [Page 28] PEM-1114E Certificate-Based Key Management March 1992 the identity of the originator based on the PEM certification system, not on unauthenticated identification information, e.g., extracted from the native message system. Conversely, for the originator of an ENCRYPTED message, it is important that recipient identities be linked to the DNs as expressed in PEM certificates. This can be effected in a variety of ways by the PEM implementation, e.g., by display of recipient DNs upon message submission or by a tightly controlled binding between local aliases and the DNs. Here too, if the originator is a forwarding process this linkage might be effected via various mechanisms not applicable to direct human interaction. Again, the essential requirement is to avoid procedures which might undermine the authentication services provided by PEM. As described above, it is a local matter how and what certification information is displayed for a human user in the course of submission or delivery of a PEM message. Nonetheless all PEM implementations must provide a user with the ability to display a full certification path for any certificate employed in PEM upon demand. Implementors are urged to not overwhelm the user with certification path information which might confuse him or distract him from the critical information cited above. 3.6.3 Validation Procedure Details Every PEM implementation is required to perform the following validation steps for every public component employed in the submission of an ENCRYPTED PEM message or the delivery of an ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message. Each public component may be acquired from an internal source, e.g., from a (secure) cache at the originator/recipient or it may be obtained from an external source, e.g., the PEM header of an incoming message or a directory. The following procedures applies to the validation of certificates from either type of source. Validation of a public component involves constructing a certification path between the component and the public component of the ICA. The validity interval for every certificate in this path must be checked. PEM software must, at a minimum, warn the user if any certificate in the path fails the validity interval check, though the form of this warning is a local matter. For example, the warning Kent (BBN) [Page 29] PEM-1114E Certificate-Based Key Management March 1992 might indicate which certificate in the path was expired. Local security policy may prohibit use of expired certificates. Each certificate also must be checked against the current CRL from the certificate's issuer to ensure that revoked certificates are not employed. If the UA does not have access to the current CRL for any certificate in the path, the user must be warned. Again, the form of the warning is a local matter. For example, the warning might indicate whether the CRL is unavailable or, if available but not current, the CRL issue date should be displayed. Local policy may prohibit use of a public component which cannot be checked against a current CRL, and in such cases the user should receive the same information provided by the warning indications described above. If any revoked certificates are encountered in the construction of a certification path, the user must be warned. The form of the warning is a local matter, but it is recommended that this warning be more stringent than those previously alluded to above. For example, this warning might display the issuer and subject DNs from the revoked certificate and the date of revocation and require the user to provide a positive response before the submission or delivery process may proceed. In the case of message submission, the warning might display the identity of the recipient affected by this validation failure and the user might be provided with the option to specify that this recipient be dropped from recipient list processing without affecting PEM processing for the remaining recipients. Local policy may prohibit PEM processing if a revoked certificate is encountered in the course of constructing a certification path. Note that in order to comply with these validation procedures, a 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 Kent (BBN) [Page 30] PEM-1114E Certificate-Based Key Management March 1992 if the issuer is a PCA (hence another reasons to distinguish PCA entries in a certificate cache). This requirement is levied upon all PEM implementations as part 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 (BBN) [Page 31] PEM-1114E Certificate-Based Key Management March 1992 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 [1115C] provides references for and the values of AlgortihmIdentifiers used by PEM in the subjectPublicKeyInfo the signature data items. There is also some ambiguity in X.509 with regard to the representation of a signed value, e.g., a certificate signature. The interpretation selected in PEM requires that the data to be signed is first ASN.1 encoded as an OCTET STRING and the result is encrypted to form the signed quantity, which is then ASN.1 encoded as an OCTET STRING. 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 (BBN) [Page 32] PEM-1114E Certificate-Based Key Management March 1992 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} B 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". CCITT [4] NIST Special Publication 500-183, "Stable Agreements for Open Systems Interconnection Protocols," Version 4, Edition 1, December 1990. [5] North American Directory Forum, ... [6] RFC 1113E, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, J. Linn, ?, 1992. [7] RFC 1115C, Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, D. Balenson, ?, 1992. Kent (BBN) [Page 33] PEM-1114E Certificate-Based Key Management March 1992 [8] RFC FROMS-C, Privacy Enhancement for Internet Electronic Mail: Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services, B. Kalaski, ?, 1992. Kent (BBN) [Page 34]