doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc1114.txt b/doc/rfc/rfc1114.txt
new file mode 100644
index 0000000..e784e1c
--- /dev/null
+++ b/doc/rfc/rfc1114.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                            S. Kent
+Request for Comments:  1114                                        BBNCC
+                                                                 J. Linn
+                                                                     DEC
+                                                  IAB Privacy Task Force
+                                                             August 1989
+
+
+           Privacy Enhancement for Internet Electronic Mail:
+              Part II -- Certificate-Based Key Management
+
+STATUS OF THIS MEMO
+
+   This RFC suggests a draft standard elective protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+ACKNOWLEDGMENT
+
+   This RFC is the outgrowth of a series of IAB Privacy Task Force
+   meetings and of internal working papers distributed for those
+   meetings.  We would like to thank the members of the Privacy Task
+   Force for their comments and contributions at the meetings which led
+   to the preparation of this RFC: David Balenson, Curt Barker, Matt
+   Bishop, Morrie Gasser, Russ Housley, Dan Nessett, Mike Padlipsky, Rob
+   Shirey, and Steve Wilbur.
+
+Table of Contents
+
+   1.  Executive Summary                                               2
+   2.  Overview of Approach                                            3
+   3.  Architecture                                                    4
+   3.1  Scope and Restrictions                                         4
+   3.2  Relation to X.509 Architecture                                 7
+   3.3  Entities' Roles and Responsibilities                           7
+   3.3.1  Users and User Agents                                        8
+   3.3.2  Organizational Notaries                                      9
+   3.3.3  Certification Authorities                                   11
+   3.3.3.1  Interoperation Across Certification Hierarchy Boundaries  14
+   3.3.3.2  Certificate Revocation                                    15
+   3.4  Certificate Definition and Usage                              17
+   3.4.1  Contents and Use                                            17
+   3.4.1.1  Version Number                                            18
+   3.4.1.2  Serial Number                                             18
+   3.4.1.3  Subject Name                                              18
+   3.4.1.4  Issuer Name                                               19
+   3.4.1.5  Validity Period                                           19
+   3.4.1.6  Subject Public Component                                  20
+
+
+
+Kent & Linn                                                     [Page 1]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   3.4.1.7  Certificate Signature                                     20
+   3.4.2  Validation Conventions                                      20
+   3.4.3  Relation with X.509 Certificate Specification               22
+   NOTES                                                              24
+
+1.  Executive Summary
+
+   This is one of a series of RFCs defining privacy enhancement
+   mechanisms for electronic mail transferred using Internet mail
+   protocols.  RFC-1113 (the successor to RFC 1040) 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-1115 specifies
+   algorithms for use in processing privacy-enhanced messages, as called
+   for in RFC-1113.  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.  A subsequent RFC, the fourth in this series, will
+   provide detailed specifications, paper and electronic application
+   forms, etc. for the key management infrastructure described herein.
+
+   The key management architecture described in this RFC is compatible
+   with the authentication framework described in X.509.  The major
+   contributions of this RFC lie not in the specification of computer
+   communication protocols or algorithms but rather in procedures and
+   conventions for the key management infrastructure.  This RFC
+   incorporates numerous conventions to facilitate near term
+   implementation.  Some of these conventions may be superceded in time
+   as the motivations for them no longer apply, e.g., when X.500 or
+   similar directory servers become well established.
+
+   The RSA cryptographic algorithm, covered in the U.S. by patents
+   administered through RSA Data Security, Inc. (hereafter abbreviated
+   RSADSI) has been selected for use in this key management system.
+   This algorithm has been selected because it provides all the
+   necessary algorithmic facilities, is "time tested" and is relatively
+   efficient to implement in either software or hardware.  It is also
+   the primary algorithm identified (at this time) for use in
+   international standards where an asymmetric encryption algorithm is
+   required.  Protocol facilities (e.g., algorithm identifiers) exist to
+   permit use of other asymmetric algorithms if, in the future, it
+   becomes appropriate to employ a different algorithm for key
+   management.  However, the infrastructure described herein is specific
+   to use of the RSA algorithm in many respects and thus might be
+   different if the underlying algorithm were to change.
+
+   Current plans call for RSADSI to act in concert with subscriber
+   organizations as a "certifying authority" in a fashion described
+
+
+
+Kent & Linn                                                     [Page 2]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   later in this RFC.  RSADSI will offer a service in which it will sign
+   a certificate which has been generated by a user and vouched for
+   either by an organization or by a Notary Public.  This service will
+   carry a $25 biennial fee which includes an associated license to use
+   the RSA algorithm in conjunction with privacy protection of
+   electronic mail.  Users who do not come under the purview of the RSA
+   patent, e.g., users affiliated with the U.S. government or users
+   outside of the U.S., may make use of different certifying authorities
+   and will not require a license from RSADSI.  Procedures for
+   interacting with these other certification authorities, maintenance
+   and distribution of revoked certificate lists from such authorities,
+   etc. are outside the scope of this RFC.  However, techniques for
+   validating certificates issued by other authorities are contained
+   within the RFC to ensure interoperability across the resulting
+   jurisdictional boundaries.
+
+2.  Overview of Approach
+
+   This RFC defines a key management architecture based on the use of
+   public-key certificates, in support of the message encipherment and
+   authentication procedures defined in RFC-1113.  In the proposed
+   architecture, a "certification authority" representing an
+   organization applies a digital signature to a collection of data
+   consisting of a user's public component, various information that
+   serves to identify the user, and the identity of the organization
+   whose signature is affixed.  (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 publically
+   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.)  This establishes a binding between these user
+   credentials, the user's public component and the organization which
+   vouches for this binding.  The resulting signed, data item is called
+   a certificate.  The organization identified as the certifying
+   authority for the certificate is the "issuer" of that certificate.
+
+   In signing the certificate, the certification authority vouches for
+   the user's identification, especially as it relates to the user's
+   affiliation with the organization.  The digital signature is affixed
+   on behalf of that organization and is in a form which can be
+   recognized by all members of the privacy-enhanced electronic mail
+   community.  Once generated, certificates can be stored in directory
+   servers, transmitted via unsecure message exchanges, or distributed
+   via any other means that make certificates easily accessible to
+   message originators, without regard for the security of the
+   transmission medium.
+
+
+
+
+Kent & Linn                                                     [Page 3]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   Prior to sending an encrypted message, 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
+   (described later) or is itself distributed in a certificate to which
+   this validation procedure is applied recursively.
+
+   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) that is used to encrypt the message itself.
+
+   The resulting encrypted DEK is incorporated into the X-Key-Info field
+   of the message header.  Upon receipt of an encrypted message, a
+   recipient employs his secret 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 secret component of his public-key pair,
+   and includes the resulting value in the message header in the X-MIC-
+   Info field.  The certificate of the originator is also included in
+   the header in the X-Certificate field as described in RFC-1113, 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, 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 (see RFC-1113) in the Internet environment.
+   The architecture describes procedures for ordering certificates from
+   issuers, for generating and distributing certificates, and for "hot
+   listing" of revoked certificates.  Concurrent with the issuance of
+   this RFC, RFC 1040 has been updated and reissued as RFC-1113 to
+   describe the syntax and semantics of new or revised header fields
+   used to transfer certificates, represent the DEK and MIC in this
+   public-key context, and to segregate algorithm definitions into a
+   separate RFC to facilitate the addition of other algorithms in the
+   future.  This RFC focuses on the management aspects of certificate-
+
+
+
+Kent & Linn                                                     [Page 4]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   based, public-key cryptography for privacy enhanced mail while RFC-
+   1113 addresses representation and processing aspects of such mail,
+   including changes required by this key management technology.
+
+   The proposed architecture imposes conventions for certification paths
+   which are not strictly required by the X.509 recommendation nor by
+   the technology itself.  The decision to impose these conventions is
+   based in part on constraints imposed by the status of the RSA
+   cryptosystem within the U.S. as a patented algorithm, and in part on
+   the need for an organization to assume operational responsibility for
+   certificate management in the current (minimal) directory system
+   infrastructure for electronic mail.  Over time, we anticipate that
+   some of these constraints, e.g., directory service availability, will
+   change and the procedures specified in the RFC will be reviewed and
+   modified as appropriate.
+
+   At this time, we propose a system in which user certificates
+   represent the leaves in a shallow (usually two tier) certification
+   hierarchy (tree).  Organizations which act as issuers are represented
+   by certificates higher in the tree.  This convention minimizes the
+   complexity of validating user certificates by limiting the length of
+   "certification paths" and by making very explicit the relationship
+   between a certificate issuer and a user.  Note that only
+   organizations may act as issuers in the proposed architecture; a user
+   certificate may not appear in a certification path, except as the
+   terminal node in the path.  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.
+
+   The RFC proposes that RSADSI act as a "co-issuer" of certificates on
+   behalf of most organizations.  This can be effected in a fashion
+   which is "transparent" so that the organizations appear to be the
+   issuers with regard to certificate formats and validation procedures.
+   This is effected by having RSADSI generate and hold the secret
+   components used to sign certificates on behalf of organizations.  The
+   motivation for RSADSI's role in certificate signing is twofold.
+   First, it simplifies accounting controls in support of licensing,
+   ensuring that RSADSI is paid for each certificate.  Second, it
+   contributes to the overall integrity of the system by establishing a
+   uniform, high level of protection for the private-components used to
+   sign certificates.  If an organization were to sign certificates
+   directly on behalf of its affiliated users, the organization would
+   have to establish very stringent security and accounting mechanisms
+   and enter into (elaborate) legal agreements with RSADSI in order to
+   provide a comparable level of assurance.  Requests by organizations
+   to perform direct certificate signing will be considered on a case-
+   by-case basis, but organizations are strongly urged to make use of
+   the facilities proposed by this RFC.
+
+
+
+Kent & Linn                                                     [Page 5]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   Note that the risks associated with disclosure of an organization's
+   secret component are different from those associated with disclosure
+   of a user's secret component.  The former component is used only to
+   sign certificates, never to encrypt message traffic.  Thus the
+   exposure of an organization's secret component could result in the
+   generation of forged certificates for users affiliated with that
+   organization, but it would not affect privacy-enhanced messages which
+   are protected using legitimate certificates.  Also note that any
+   certificates generated as a result of such a disclosure are readily
+   traceable to the issuing authority which holds this component, e.g.,
+   RSADSI, due to the non-repudiation feature of the digital signature.
+   The certificate registration and signing procedures established in
+   this RFC would provide non-repudiable evidence of disclosure of an
+   organization's secret component by RSADSI.  Thus this RFC advocates
+   use of RSADSI as a co-issuer for certificates until such time as
+   technical security mechanisms are available to provide a similar,
+   system-wide level of assurance for (distributed) certificate signing
+   by organizations.
+
+   We identify two classes of exceptions to this certificate signing
+   paradigm.  First, the RSA algorithm is patented only within the U.S.,
+   and thus it is very likely that certificate signing by issuers will
+   arise outside of the U.S., independent of RSADSI.  Second, the
+   research that led to the RSA algorithm was sponsored by the National
+   Science Foundation, and thus the U.S. government retains royalty-free
+   license rights to the algorithm.  Thus the U.S. government may
+   establish a certificate generation facilities for its affiliated
+   users.  A number of the procedures described in this document apply
+   only to the use of RSADSI as a certificate co-issuer; all other
+   certificate generation practices lie outside the scope of this RFC.
+
+   This RFC specifies procedures by which users order certificates
+   either directly from RSADSI or via a representative in an
+   organization with which the user holds some affiliation (e.g., the
+   user's employer or educational institution).  Syntactic provisions
+   are made which allow a recipient to determine, to some granularity,
+   which identifying information contained in the certificate is vouched
+   for by the certificate issuer.  In particular, organizations will
+   usually be vouching for the affiliation of a user with that
+   organization and perhaps a user's role within the organization, in
+   addition to the user's name.  In other circumstances, as discussed in
+   section 3.3.3, a certificate may indicate that an issuer vouches only
+   for the user's name, implying that any other identifying information
+   contained in the certificate may not have been validated by the
+   issuer.  These semantics are beyond the scope of X.509, but are not
+   incompatible with that recommendation.
+
+   The key management architecture described in this RFC has been
+
+
+
+Kent & Linn                                                     [Page 6]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   designed to support privacy enhanced mail as defined in this RFC,
+   RFC-1113, and their successors.  Note that this infrastructure also
+   supports X.400 mail security facilities (as per X.411) and thus paves
+   the way for transition to the OSI/CCITT Message Handling System
+   paradigm in the Internet in the future.  The certificate issued to a
+   user for the $25 biennial fee will grant to the user identified by
+   that certificate a license from RSADSI to employ the RSA algorithm
+   for certificate validation and for encryption and decryption
+   operations in this electronic mail context.  No use of the algorithm
+   outside the scope defined in this RFC is authorized by this license
+   as of this time.  Expansion of the license to other Internet security
+   applications is possible but not yet authorized.  The license granted
+   by this fee does not authorize the sale of software or hardware
+   incorporating the RSA algorithm; it is an end-user license, not a
+   developer's license.
+
+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.  The
+   public-key certificate approach defined in X.509 has also been
+   adopted in CCITT 1988 X.411 in support of the message handling
+   application.
+
+   This RFC interprets the X.509 certificate mechanism to serve the
+   needs of privacy-enhanced mail 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.
+   In large part constraints have been levied in order to simplify
+   certificate validation in the absence of a widely available, user-
+   level directory service.  The certification hierarchy proposed here
+   also embodies semantics which are not explicitly addressed by X.509,
+   but which are consistent with X.509 precepts.  The additional
+   semantic constraints have been adopted to explicitly address
+   questions of issuer "authority" which we feel are not well defined in
+   X.509.
+
+3.3  Entities' Roles and Responsibilities
+
+   One way to explain the architecture proposed by this RFC is to
+   examine the various roles which are defined for various entities in
+
+
+
+Kent & Linn                                                     [Page 7]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   the architecture and to describe what is required of each entity in
+   order for the proposed system to work properly.  The following
+   sections identify three different types of entities within this
+   architecture: users and user agents, organizational notaries, and
+   certification authorities.  For each class of entity we describe the
+   (electronic and paper) 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.  Note that the
+   infrastructure described here applies to the situation wherein RSADSI
+   acts as a co-issuer of certificates, sharing the role of
+   certification authority as described later.  Other certifying
+   authority arrangements may employ different procedures and are not
+   addressed by this RFC.
+
+3.3.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).
+
+   A UA process supporting privacy-enhanced mail processing must protect
+   the private component of its associated entity (ordinarily, a human
+   user) from disclosure.  We anticipate that a user will employ
+   ancillary software (not otherwise associated with the UA) to generate
+   his public/private component pair and to compute the (one-way)
+   message hash required by the registration procedure.  The public
+   component, along with information that identifies the user, will be
+   transferred to an organizational notary (see below) for inclusion in
+   an order to an issuer.  The process of generating public and private
+   components is a local matter, but we anticipate Internet-wide
+   distribution of software suitable for component-pair generation to
+   facilitate the process.  The mechanisms used to transfer the public
+   component and the user identification information must preserve the
+   integrity of both quantities and bind the two during this transfer.
+
+   This proposal establishes two ways in which a user may order a
+   certificate, i.e., through the user's affiliation with an
+   organization or directly through RSADSI.  In either case, a user will
+   be required to send a paper order to RSADSI on a form described in a
+   subsequent RFC and containing the following information:
+
+      1.  Distinguished Name elements (e.g., full legal name,
+          organization name, etc.)
+
+      2.  Postal address
+
+
+
+Kent & Linn                                                     [Page 8]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+      3.  Internet electronic mail address
+
+      4.  A message hash function, binding the above information to the
+          user's public component
+
+   Note that the user's public component is NOT transmitted via this
+   paper path.  In part the rationale here is that the public component
+   consists of many (>100) digits and thus is prone to error if it is
+   copied to and from a piece of paper.  Instead, a message hash is
+   computed on the identifying information and the public component and
+   this (smaller) message hash value is transmitted along with the
+   identifying information.  Thus the public component is transferred
+   only via an electronic path, as described below.
+
+   If the user is not affiliated with an organization which has
+   established its own "electronic notary" capability (an organization
+   notary or "ON" as discussed in the next section), then this paper
+   registration form must be notarized by a Notary Public.  If the user
+   is affiliated with an organization which has established one or more
+   ONs, the paper registration form need not carry the endorsement of a
+   Notary Public.  Concurrent with the paper registration, the user must
+   send the information outlined above, plus his public component,
+   either to his ON, or directly to RSADSI if no appropriate ON is
+   available to the user.  Direct transmission to RSADSI of this
+   information will be via electronic mail, using a representation
+   described in a subsequent RFC.  The paper registration must be
+   accompanied by a check or money order for $25 or an organization may
+   establish some other billing arrangement with RSADSI.  The maximum
+   (and default) lifetime of a certificate ordered through this process
+   is two years.
+
+   The transmission of ID information and public component from a user
+   to his ON is a local matter, but we expect electronic mail will also
+   be the preferred approach in many circumstances and we anticipate
+   general distribution of software to support this process.  Note that
+   it is the responsibility of the user and his organization to ensure
+   the integrity of this transfer by some means deemed adequately secure
+   for the local computing and communication environment.  There is no
+   requirement for secrecy in conjunction with this information
+   transfer, but the integrity of the information must be ensured.
+
+3.3.2  Organizational Notaries
+
+   An organizational notary is an individual who acts as a clearinghouse
+   for certificate orders originating within an administrative domain
+   such as a corporation or a university.  An ON represents an
+   organization or organizational unit (in X.500 naming terms), and is
+   assumed to have some independence from the users on whose behalf
+
+
+
+Kent & Linn                                                     [Page 9]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   certificates are ordered.  An ON will be restricted through
+   mechanisms implemented by the issuing authority, e.g., RSADSI, to
+   ordering certificates properly associated with the domain of that ON.
+   For example, an ON for BBN should not be able to order certificates
+   for users affiliated with MIT or MITRE, nor vice versa.  Similarly,
+   if a corporation such as BBN were to establish ONs on a per-
+   subsidiary basis (corresponding to organization units in X.500 naming
+   parlance), then an ON for the BBN Communications subsidiary should
+   not be allowed to order a certificate for a user who claims
+   affiliation with the BBN Software Products subsidiary.
+
+   It can be assumed that the set of ONs changes relatively slowly and
+   that the number of ONs is relatively small in comparison with the
+   number of users.  Thus a more extensive, higher assurance process may
+   reasonably be associated with ON accreditation than with per-user
+   certificate ordering.  Restrictions on the range of information which
+   an ON is authorized to certify are established as part of this more
+   elaborate registration process.  The procedures by which
+   organizations and organizational units are established in the RSADSI
+   database, and by which ONs are registered, will be described in a
+   subsequent RFC.
+
+   An ON is responsible for establishing the correctness and integrity
+   of information incorporated in an order, and will generally vouch for
+   (certify) the accuracy of identity information at a granularity finer
+   than that provided by a Notary Public.  We do not believe that it is
+   feasible to enforce uniform standards for the user certification
+   process across all ONs, but we anticipate that organizations will
+   endeavor to maintain high standards in this process in recognition of
+   the "visibility" associated with the identification data contained in
+   certificates.  An ON also may constrain the validity period of an
+   ordered certificate, restricting it to less than the default two year
+   interval imposed by the RSADSI license agreement.
+
+   An ON participates in the certificate ordering process by accepting
+   and validating identification information from a user and forwarding
+   this information to RSADSI.  The ON accepts the electronic ordering
+   information described above (Distinguished Name elements, mailing
+   address, public component, and message hash computed on all of this
+   data) from a user.  (The representation for user-to-ON transmission
+   of this data is a local matter, but we anticipate that the encoding
+   specified for ON-to-RSADSI representation of this data will often be
+   employed.)  The ON sends an integrity-protected (as described in
+   RFC-1113) electronic message to RSADSI, vouching for the correctness
+   of the binding between the public component and the identification
+   data.  Thus, to support this function, each ON will hold a
+   certificate as an individual user within the organization which he
+   represents.  RSADSI will maintain a database which identifies the
+
+
+
+Kent & Linn                                                    [Page 10]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   users who also act as ONs and the database will specify constraints
+   on credentials which each ON is authorized to certify.  The
+   electronic mail representation for a user's certificate data in an ON
+   message to RSADSI will be specified in a subsequent RFC.
+
+3.3.3  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".  This alternate expansion for the acronym "CA" is
+   roughly equivalent to that contemplated as a "central authority" in
+   RFC-1040 and RFC-1113.  The only difference is that in X.509 there is
+   no requirement that a CA be a distinguished entity or that a CA serve
+   a large number of users, as envisioned in these RFCs.  Rather, any
+   user who holds a certificate can, in the X.509 context, act as a CA
+   for any other user.  As noted above, we have chosen to restrict the
+   role of CA in this electronic mail environment to organizational
+   entities, to simplify the certificate validation process, to impose
+   semantics which support organizational affiliation as a basis for
+   certification, and to facilitate license accountability.
+
+   In the proposed architecture, individuals who are affiliated with
+   (registered) organizations will go through the process described
+   above, in which they forward their certificate information to their
+   ON for certification.  The ON will, based on local procedures, verify
+   the accuracy of the user's credentials and forward this information
+   to RSADSI using privacy-enhanced mail to ensure the integrity and
+   authenticity of the information.  RSADSI will carry out the actual
+   certificate generation process on behalf of the organization
+   represented by the ON.  Recall that it is the identity of the
+   organization which the ON represents, not the ON's identity, which
+   appears in the issuer field of the user certificate.  Therefore it is
+   the private component of the organization, not the ON, which is used
+   to sign the user certificate.
+
+   In order to carry out this procedure RSADSI will serve as the
+   repository for the private components associated with certificates
+   representing organizations or organizational units (but not
+   individuals).  In effect the role of CA will be shared between the
+   organizational notaries and RSADSI.  This shared role will not be
+   visible in the syntax of the certificates issued under this
+   arrangement nor is it apparent from the validation procedure one
+   applies to these certificates.  In this sense, the role of RSADSI as
+   the actual signer of certificates on behalf of organizations is
+   transparent to this aspect of system operation.
+
+   If an organization were to carry out the certificate signing process
+   locally, and thus hold the private component associated with its
+
+
+
+Kent & Linn                                                    [Page 11]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   organization certificate, it would need to contact RSADSI to discuss
+   security safeguards, special legal agreements, etc.  A number of
+   requirements would be imposed on an organization if such an approach
+   were persued.  The organization would be required to execute
+   additional legal instruments with RSADSI, e.g., to ensure proper
+   accounting for certificates generated by the organization.  Special
+   software will be required to support the certificate signing process,
+   distinct from the software required for an ON.  Stringent procedural,
+   physical, personnel and computer security safeguards would be
+   required to support this process, to maintain a relatively high level
+   of security for the system as a whole.  Thus, at this time, it is not
+   recommended that organizations pursue this approach although local
+   certificate generation is not expressly precluded by the proposed
+   architecture.
+
+   RSADSI has offered to operate a service in which it serves as a CA
+   for users who are not affiliated with any organization or who are
+   affiliated with an organization which has not opted to establish an
+   organizational notary.  To distinguish certificates issued to such
+   "non-affiliated" users the distinguished string "Notary" will appear
+   as the organizational unit name of the issuer of the certificate.
+   This convention will be employed throughout the system.  Thus not
+   only RSADSI but any other organization which elects to provide this
+   type of service to non-affiliated users may do so in a standard
+   fashion.  Hence a corporation might issue a certificate with the
+   "Notary" designation to students hired for the summer, to
+   differentiate them from full-time employees.  At least in the case of
+   RSADSI, the standards for verifying user credentials that carry this
+   designation will be well known and widely recognized (e.g., Notary
+   Public endorsement).
+
+   To illustrate this convention, consider the following examples.
+   Employees of RSADSI will hold certificates which indicate "RSADSI" as
+   the organization in both the issuer field and the subject field,
+   perhaps with no organizational unit specified.  Certificates obtained
+   directly from RSADSI, by user's who are not affiliated with any ON,
+   will also indicate "RSADSI" as the organization and will specify
+   "Notary" as an organizational unit in the issuer field.  However,
+   these latter certificates will carry some other designation for
+   organization (and, optionally, organizational unit) in the subject
+   field.  Moreover, an organization designated in the subject field for
+   such a certificate will not match any for which RSADSI has an ON
+   registered (to avoid possible confusion).
+
+   In all cases described above, when a certificate is generated RSADSI
+   will send a paper reply to the ordering user, including two message
+   hash functions:
+
+
+
+
+Kent & Linn                                                    [Page 12]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+      1.  a message hash computed on the user's identifying information
+          and public component (and sent to RSADSI in the registration
+          process), to guarantee its integrity across the ordering
+          process, and
+
+      2.  a message hash computed on the public component of RSADSI, to
+          provide independent authentication for this public component
+          which is transmitted to the user via email (see below).
+
+   RSADSI will send to the user via electronic mail (not privacy
+   enhanced) a copy of his certificate, a copy of the organization
+   certificate identified in the issuer field of the user's certificate,
+   and the public component used to validate certificates signed by
+   RSADSI.  The "issuer" certificate is included to simplify the
+   validation process in the absence of a user-level directory system;
+   its distribution via this procedure will probably be phased out in
+   the future.  Thus, as described in RFC-1113, the originator of a
+   message is encouraged, though not required, to include his
+   certificate, and that of its issuer, in the privacy enhanced message
+   header (X-Issuer-Certificate) to ensure that each recipient can
+   process the message using only the information contained in this
+   header.  The organization (organizational unit) identified in the
+   subject field of the issuer certificate should correspond to that
+   which the user claims affiliation (as declared in the subject field
+   of his certificate).  If there is no appropriate correspondence
+   between these fields, recipients ought to be suspicious of the
+   implied certification path.  This relationship should hold except in
+   the case of "non-affiliated" users for whom the "Notary" convention
+   is employed.
+
+   In contrast, the issuer field of the issuer's certificate will
+   specify "RSADSI" as the organization, i.e., RSADSI will certify all
+   organizational certificates.  This convention allows a recipient to
+   validate any originator's certificate (within the RSADSI
+   certification hierarchy) in just two steps.  Even if an organization
+   establishes a certification hierarchy involving organizational units,
+   certificates corresponding to each unit can be certified both by
+   RSADSI and by the organizational entity immediately superior to the
+   unit in the hierarchy, so as to preserve this short certification
+   path feature.  First, the public component of RSADSI is employed to
+   validate the issuer's certificate.  Then the issuer's public
+   component is extracted from that certificate and is used to validate
+   the originator's certificate.  The recipient then extracts the
+   originator's public component for use in processing the X-Mic-Info
+   field of the message (see and RFC-1113).
+
+   The electronic representation used for transmission of the data items
+   described above (between an ON and RSADSI) will be contained in a
+
+
+
+Kent & Linn                                                    [Page 13]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   subsequent RFC.  To verify that the registration process has been
+   successfully completed and to prepare for exchange of privacy-
+   enhanced electronic mail, the user should perform the following
+   steps:
+
+      1.  extract the RSADSI public component, the issuer's certificate
+          and the user's certificate from the message
+
+      2.  compute the message hash on the RSADSI public component and
+          compare the result to the corresponding message hash that was
+          included in the paper receipt
+
+      3.  use the RSADSI public component to validate the signature on
+          the issuer's certificate (RSADSI will be the issuer of this
+          certificate)
+
+      4.  extract the organization public component from the validated
+          issuer's certificate and use this public component to
+          validate the user certificate
+
+      5.  extract the identification information and public component
+          from the user's certificate, compute the message hash on it
+          and compare the result to the corresponding message hash
+          value transmitted via the paper receipt
+
+   For a user whose order was processed via an ON, successful completion
+   of these steps demonstrates that the certificate issued to him
+   matches that which he requested and which was certified by his ON.
+   It also demonstrates that he possesses the (correct) public component
+   for RSADSI and for the issuer of his certificate.  For a user whose
+   order was placed directly with RSADSI, this process demonstrates that
+   his certificate order was properly processed by RSADSI and that he
+   possesses the valid issuer certificate for the RSADSI Notary.  The
+   user can use the RSADSI public component to validate organizational
+   certificates for organizations other than his own.  He can employ the
+   public component associated with his own organization to validate
+   certificates issued to other users in his organization.
+
+3.3.3.1  Interoperation Across Certification Hierarchy Boundaries
+
+   In order to accommodate interoperation with other certification
+   authorities, e.g., foreign or U.S. government CAs, two conventions
+   will be adopted.  First, all certifying authorities must agree to
+   "cross-certify" one another, i.e., each must be willing to sign a
+   certificate in which the issuer is that certifying authority and the
+   subject is another certifying authority.  Thus, RSADSI might generate
+   a certificate in which it is identified as the issuer and a
+   certifying authority for the U.S. government is indentified as the
+
+
+
+Kent & Linn                                                    [Page 14]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   subject.  Conversely, that U.S. government certifying authority would
+   generate a certificate in which it is the issuer and RSADSI is the
+   subject.  This cross-certification of certificates for "top-level"
+   CAs establishes a basis for "lower level" (e.g., organization and
+   user) certificate validation across the hierarchy boundaries.  This
+   avoids the need for users in one certification hierarchy to engage in
+   some "out-of-band" procedure to acquire a public-key for use in
+   validating certificates from a different certification hierarchy.
+
+   The second convention is that more than one X-Issuer-Certificate
+   field may appear in a privacy-enhanced mail header.  Multiple issuer
+   certificates can be included so that a recipient can more easily
+   validate an originator's certificate when originator and recipient
+   are not part of a common CA hierarchy.  Thus, for example, if an
+   originator served by the RSADSI certification hierarchy sends a
+   message to a recipient served by a U.S. government hierarchy, the
+   originator could (optionally) include an X-Issuer-Certificate field
+   containing a certificate issued by the U.S. government CA for RSADSI.
+   In this fashion the recipient could employ his public component for
+   the U.S. government CA to validate this certificate for RSADSI, from
+   which he would extract the RSADSI public component to validate the
+   certificate for the originator's organization, from which he would
+   extract the public component required to validate the originator's
+   certificate.  Thus, more steps can be required to validate
+   certificates when certification hierarchy boundaries are crossed, but
+   the same basic procedure is employed.  Remember that caching of
+   certificates by UAs can significantly reduce the effort required to
+   process messages and so these examples should be viewed as "worse
+   case" scenarios.
+
+3.3.3.2  Certificate Revocation
+
+   X.509 states that it is a CA's responsibility to maintain:
+
+      1.  a time-stamped list of the certificates it issued which have
+          been revoked
+
+      2.  a time-stamped list of revoked certificates representing
+          other CAs
+
+   There are two primary reasons for a CA to revoke a certificate, i.e.,
+   suspected compromise of a secret component (invalidating the
+   corresponding public component) or change of user affiliation
+   (invalidating the Distinguished Name).  As described in X.509, "hot
+   listing" is one means of propagating information relative to
+   certificate revocation, though it is not a perfect mechanism.  In
+   particular, an X.509 Revoked Certificate List (RCL) indicates only
+   the age of the information contained in it; it does not provide any
+
+
+
+Kent & Linn                                                    [Page 15]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   basis for determining if the list is the most current RCL available
+   from a given CA.  To help address this concern, the proposed
+   architecture establishes a format for an RCL in which not only the
+   date of issue, but also the next scheduled date of issue is
+   specified.  This is a deviation from the format specified in X.509.
+
+   Adopting this convention, when the next scheduled issue date arrives
+   a CA must issue a new RCL, 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 RCLs are issued by that CA.  Note
+   that this does not preclude RCL issuance on a more frequent basis,
+   e.g., in case of some emergency, but no Internet-wide mechanisms are
+   architected for alerting users that such an unscheduled issuance has
+   taken place.  This scheduled RCL issuance convention allows users
+   (UAs) to determine whether a given RCL is "out of date," a facility
+   not available from the standard RCL format.
+
+   A recent (draft) version of the X.509 recommendation calls for each
+   RCL to contain the serial numbers of certificates which have been
+   revoked by the CA administering that list, i.e., the CA that is
+   identified as the issuer for the corresponding revoked certificates.
+   Upon receipt of a RCL, a UA should compare the entries against any
+   cached certificate information, deleting cache entries which match
+   RCL entries.  (Recall that the certificate serial numbers are unique
+   only for each issuer, so care must be exercised in effecting this
+   cache search.)  The UA should also retain the RCL to screen incoming
+   messages to detect use of revoked certificates carried in these
+   message headers.  More specific details for processing RCL are beyond
+   the scope of this RFC as they are a function of local certificate
+   management techniques.
+
+   In the architecture defined by this RFC, a RCL will be maintained for
+   each CA (organization or organizational unit), signed using the
+   private component of that organization (and thus verifiable using the
+   public component of that organization as extracted from its
+   certificate).  The RSADSI Notary organizational unit is included in
+   this collection of RCLs.  CAs operated under the auspices of the U.S.
+   government or foreign CAs are requested to provide RCLs conforming to
+   these conventions, at least until such time as X.509 RCLs provide
+   equivalent functionality, in support of interoperability with the
+   Internet community.  An additional, "top level" RCL, will be
+   maintained by RSAD-SI, and should be maintained by other "top level"
+   CAs, for revoked organizational certificates.
+
+   The hot listing procedure (expect for this top level RCL) will be
+   effected by having an ON from each organization transmit to RSADSI a
+   list of the serial numbers of users within his organization, to be
+   hot listed.  This list will be transmitted using privacy-enhanced
+
+
+
+Kent & Linn                                                    [Page 16]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   mail to ensure authenticity and integrity and will employ
+   representation conventions to be provided in a subsequent RFC.
+   RSADSI will format the RCL, sign it using the private component of
+   the organization, and transmit it to the ON for dissemination, using
+   a representation defined in a subsequent RFC.  Means for
+   dissemination of RCLs, both within the administrative domain of a CA
+   and across domain boundaries, are not specified by this proposal.
+   However, it is anticipated that each hot list will also be available
+   via network information center databases, directory servers, etc.
+
+   The following ASN.1 syntax, derived from X.509, defines the format of
+   RCLs for use in the Internet privacy enhanced email environment.  See
+   the ASN.1 definition of certificates (later in this RFC or in X.509,
+   Annex G) for comparison.
+
+      revokedCertificateList  ::=     SIGNED SEQUENCE {
+              signature       AlgorithmIdentifier,
+              issuer          Name,
+              list            SEQUENCE RCLEntry,
+              lastUpdate      UTCTime,
+              nextUpdate      UTCTime}
+
+      RCLEntry        ::=     SEQUENCE {
+              subject         CertificateSerialNumber,
+              revocationDate  UTCTime}
+
+3.4  Certificate Definition and Usage
+
+3.4.1  Contents and Use
+
+   A certificate contains the following contents:
+
+      1.  version
+
+      2.  serial number
+
+      3.  certificate signature (and associated algorithm identifier)
+
+      4.  issuer name
+
+      5.  validity period
+
+      6.  subject name
+
+      7.  subject public component (and associated algorithm identifier)
+
+   This section discusses the interpretation and use of each of these
+   certificate elements.
+
+
+
+Kent & Linn                                                    [Page 17]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+3.4.1.1  Version Number
+
+   The version number field is intended to facilitate orderly changes in
+   certificate formats over time.  The initial version number for
+   certificates is zero (0).
+
+3.4.1.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 RCLs to identify revoked certificates instead of including entire
+   certificates.  Thus each certificate generated by an issuer must
+   contain a unique serial number.  It is suggested that these numbers
+   be issued as a compact, monotonic increasing sequence.
+
+3.4.1.3  Subject Name
+
+   A certificate provides a representation of its subject's identity and
+   organizational affiliation in the form of a Distinguished Name.  The
+   fundamental binding ensured by the privacy enhancement mechanisms is
+   that between public-key and the user identity.  CCITT Recommendation
+   X.500 defines the concept of Distinguished Name.
+
+   Version 2 of the U.S. Government Open Systems Interconnection Profile
+   (GOSIP) specifies maximum sizes for O/R Name attributes.  Since most
+   of these attributes also appear in Distinguished Names, we have
+   adopted the O/R Name attribute size constraints specified in GOSIP
+   and noted below.  Using these size constraints yields a maximum
+   Distinguished Name length (exclusive of ASN encoding) of two-hundred
+   fifty-nine (259) characters, based on the required and optional
+   attributes described below for subject names.  The following
+   attributes are required in subject Distinguished Names for purposes
+   of this RFC:
+
+      1.  Country Name in standard encoding (e.g., the two-character
+          Printable String "US" assigned by ISO 3166 as the identifier
+          for the United States of America, the string "GB" assigned as
+          the identifier for the United Kingdom, or the string "NQ"
+          assigned as the identifier for Dronning Maud Land).  Maximum
+          ASCII character length of three (3).
+
+      2.  Organizational Name (e.g., the Printable String "Bolt Beranek
+          and Newman, Inc.").  Maximum ASCII character length of
+          sixty-four (64).
+
+      3.  Personal Name (e.g., the X.402/X.411 structured Printable
+          String encoding for the name John Linn).  Maximum ASCII
+          character length of sixty-four (64).
+
+
+
+Kent & Linn                                                    [Page 18]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   The following attributes are optional in subject Distinguished Names
+   for purposes of this RFC:
+
+      1.  Organizational Unit Name(s) (e.g., the Printable String "BBN
+          Communications Corporation")  A hierarchy of up to four
+          organizational unit names may be provided; the least
+          significant member of the hierarchy is represented first.
+          Each of these attributes has a maximum ASCII character length of
+          thirty-two (32), for a total of one-hundred and twenty-eight
+          (128) characters if all four are present.
+
+3.4.1.4  Issuer Name
+
+   A certificate provides a representation of its issuer's identity, in
+   the form of a Distinguished Name.  The issuer identification is
+   needed in order to determine the appropriate issuer public component
+   to use in performing certificate validation.  The following
+   attributes are required in issuer Distinguished Names for purposes of
+   this RFC:
+
+      1.  Country Name (e.g., encoding for "US")
+
+      2.  Organizational Name
+
+   The following attributes are optional in issuer Distinguished Names
+   for purposes of this RFC:
+
+      1.  Organizational Unit Name(s).  (A hierarchy of up to four
+          organizational unit names may be provided; the least significant
+          member of the hierarchy is represented first.)  If the
+          issuer is vouching for the user identity in the Notary capacity
+          described above, then exactly one instance of this field
+          must be present and it must consist of the string "Notary".
+
+   As noted earlier, only organizations are allowed as issuers in the
+   proposed authentication hierarchy.  Hence the Distinguished Name for
+   an issuer should always be that of an organization, not a user, and
+   thus no Personal Name field may be included in the Distinguished Name
+   of an issuer.
+
+3.4.1.5  Validity Period
+
+   A certificate carries a pair of time specifiers, indicating the start
+   and end of the time period over which a certificate is intended to be
+   used.  No message should ever be prepared for transmission with a
+   non-current certificate, but recipients should be prepared to receive
+   messages processed using recently-expired certificates.  This fact
+   results from the unpredictable (and sometimes substantial)
+
+
+
+Kent & Linn                                                    [Page 19]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   transmission delay of the staged-delivery electronic mail
+   environment.  The default and maximum validity period for
+   certificates issued in this system will be two years.
+
+3.4.1.6  Subject Public Component
+
+   A certificate carries the public component of its associated entity,
+   as well as an indication of the algorithm with which the public
+   component is to be used.  For purposes of this RFC, the algorithm
+   identifier will indicate use of the RSA algorithm, as specified in
+   RFC-1115.  Note that in this context, a user's public component is
+   actually the modulus employed in RSA algorithm calculations.  A
+   "universal" (public) exponent is employed in conjunction with the
+   modulus to complete the system.  Two choices of exponents are
+   recommended for use in this context and are described in section
+   3.4.3.  Modulus size will be permitted to vary between 320 and 632
+   bits.
+
+3.4.1.7  Certificate Signature
+
+   A certificate carries a signature algorithm identifier and a
+   signature, applied to the certificate by its issuer.  The signature
+   is validated by the user of a certificate, in order to determine that
+   the integrity of its contents have not been compromised subsequent to
+   generation by a CA.  An encrypted, one-way hash will be employed as
+   the signature algorithm.  Hash functions suitable for use in this
+   context are notoriously difficult to design and tend to be
+   computationally intensive.  Initially we have adopted a hash function
+   developed by RSADSI and which exhibits performance roughly equivalent
+   to the DES (in software).  This same function has been selected for
+   use in other contexts in this system where a hash function (message
+   hash algorithm) is required, e.g., MIC for multicast messages.  In
+   the future we expect other one-way hash functions will be added to
+   the list of algorithms designated for this purpose.
+
+3.4.2  Validation Conventions
+
+   Validating a certificate involves 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 the proposed architecture this recursive operation is terminated
+   quickly by adopting the convention that RSADSI will certify the
+   certificates of all organizations or organizational units which act
+   as issuers for end users.  (Additional validation steps may be
+
+
+
+Kent & Linn                                                    [Page 20]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   required for certificates issued by other CAs as described in section
+   3.3.3.1.)
+
+   Certification means that RSADSI will sign certificates in which the
+   subject is the organization or organizational unit and for which
+   RSADSI is the issuer, thus implying that RSADSI vouches for the
+   credentials of the subject.  This is an appropriate construct since
+   each ON representing an organization or organizational unit must have
+   registered with RSADSI via a procedure more rigorous than individual
+   user registration.  This does not preclude an organizational unit
+   from also holding a certificate in which the "parent" organization
+   (or organizational unit) is the issuer.  Both certificates are
+   appropriate and permitted in the X.509 framework.  However, in order
+   to facilitate the validation process in an environment where user-
+   level directory services are generally not available, we will (at
+   this time) adopt this certification convention.
+
+   The public component needed to validate certificates signed by RSADSI
+   (in its role as a CA for issuers) is transmitted to each user as part
+   of the registration process (using electronic mail with independent,
+   postal confirmation via a message hash).  Thus a user will be able to
+   validate any user certificate (from the RSADSI hierarchy) in at most
+   two steps.  Consider the situation in which a user receives a privacy
+   enhanced message from an originator with whom the recipient has never
+   previously corresponded.  Based on the certification convention
+   described above, the recipient can use the RSADSI public component to
+   validate the issuer's certificate contained in the X-Issuer-
+   Certificate field.  (We recommend that, initially, the originator
+   include his organization's certificate in this optional field so that
+   the recipient need not access a server or cache for this public
+   component.)  Using the issuer's public component (extracted from this
+   certificate), the recipient can validate the originator's certificate
+   contained in the X-Certificate field of the header.
+
+   Having performed this certificate validation process, the recipient
+   can extract the originator's public component and use it to decrypt
+   the content of the X-MIC-Info field and thus verify the data origin
+   authenticity and integrity of the message.  Of course,
+   implementations of privacy enhanced mail should cache validated
+   public components (acquired from incoming mail or via the message
+   from a user registration process) 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 users.
+
+
+
+Kent & Linn                                                    [Page 21]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   A separate issue associated with validation of certificates is a
+   semantic one, i.e., is the entity identified in the issuer field
+   appropriate to vouch for the identifying information in the subject
+   field.  This is a topic outside the scope of X.509, but one which
+   must be addressed in any viable system.  The hierarchy proposed in
+   this RFC is designed to address this issue.  In most cases a user
+   will claim, as part of his identifying information, affiliation with
+   some organization and that organization will have the means and
+   responsibility for verifying this identifying information.  In such
+   circumstances one should expect an obvious relationship between the
+   Distinguished Name components in the issuer and subject fields.
+
+   For example, if the subject field of a certificate identified an
+   individual as affiliated with the "Widget Systems Division"
+   (Organizational Unit Name) of "Compudigicorp" (Organizational Name),
+   one would expect the issuer field to specify "Compudigicorp" as the
+   Organizational Name and, if an Organizational Unit Name were present,
+   it should be "Widget Systems Division."  If the issuer's certificate
+   indicated "Compudigicorp" as the subject (with no Organizational Unit
+   specified), then the issuer should be "RSADSI."  If the issuer's
+   certificate indicated "Widget Systems Division" as Organizational
+   Unit and "Compudigicorp" as Organization in the subject field, then
+   the issuer could be either "RSADSI" (due to the direct certification
+   convention described earlier) or "Compudigicorp" (if the organization
+   elected to distribute this intermediate level certificate).  In the
+   later case, the certificate path would involve an additional step
+   using the certificate in which "Compudigicorp" is the subject and
+   "RSADSI" is the issuer.  One should be suspicious if the validation
+   path does not indicate a subset relationship for the subject and
+   issuer Distinguished Names in the certification path, expect where
+   cross-certification is employed to cross CA boundaries.
+
+   It is a local matter whether the message system presents a human user
+   with the certification path used to validate a certificate associated
+   with incoming, privacy-enhanced mail.  We note that a visual display
+   of the Distinguished Names involved in that path is one means of
+   providing the user with the necessary information.  We recommend,
+   however, that certificate validation software incorporate checks and
+   alert the user whenever the expected certification path relationships
+   are not present.  The rationale here is that regular display of
+   certification path data will likely be ignored by users, whereas
+   automated checking with a warning provision is a more effective means
+   of alerting users to possible certification path anomalies.  We urge
+   developers to provide facilities of this sort.
+
+3.4.3  Relation with X.509 Certificate Specification
+
+   An X.509 certificate can be viewed as two components: contents and an
+
+
+
+Kent & Linn                                                    [Page 22]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+   encrypted hash.  The encrypted hash is formed and processed as
+   follows:
+
+      1.  X, the hash, is computed as a function of the certificate
+          contents
+
+      2.  the hash is signed by raising X to the power e (modulo n)
+
+      3.  the hash's signature is validated by raising the result of
+          step 2 to the power d (modulo n), yielding X, which is
+          compared with the result computed as a function of certificate
+          contents.
+
+   Annex C to X.509 suggests the use of Fermat number F4 (65537 decimal,
+   1 + 2 **16 ) as a fixed value for e which allows relatively efficient
+   authentication processing, i.e., at most seventeen (17)
+   multiplications are required to effect exponentiation).  As an
+   alternative one can employ three (3) as the value for e, yielding
+   even faster exponentiation, but some precautions must be observed
+   (see RFC-1115).  Users of the algorithm select values for d (a secret
+   quantity) and n (a non-secret quantity) given this fixed value for e.
+   As noted earlier, this RFC proposes that either three (3) or F4 be
+   employed as universal encryption exponents, with the choice specified
+   in the algorithm identifier.  In particular, use of an exponent value
+   of three (3) for certificate validation is encouraged, to permit
+   rapid certificate validation.  Given these conventions, a user's
+   public component, and thus the quantity represented in his
+   certificate, is actually the modulus (n) employed in this computation
+   (and in the computations used to protect the DEK and MSGHASH, as
+   described in RFC-1113).  A user's private component is the exponent
+   (d) cited above.
+
+   The X.509 certificate format is defined (in X.509, Annex G) 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
+
+
+
+
+Kent & Linn                                                    [Page 23]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+         Validity ::=    SEQUENCE{
+                 notBefore       UTCTime,
+                 notAfter        UTCTime}
+
+         SubjectPublicKeyInfo ::=        SEQUENCE{
+                 algorithm               AlgorithmIdentifier,
+                 subjectPublicKey        BIT STRING}
+
+
+         AlgorithmIdentifier ::= SEQUENCE{
+                 algorithm       OBJECT IDENTIFIER,
+                 parameters      ANY DEFINED BY algorithm OPTIONAL}
+
+   All components of this structure are well defined by ASN.1 syntax
+   defined in the 1988 X.400 and X.500 Series Recommendations, except
+   for the AlgorithmIdentifier.  An algorithm identifier for RSA is
+   contained in Annex H of X.509 but is unofficial.  RFC-1115 will
+   provide detailed syntax and values for this field.
+
+NOTES:
+
+  [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".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Linn                                                    [Page 24]
+
+RFC 1114              Mail Privacy: Key Management           August 1989
+
+
+Authors' Addresses
+
+       Steve Kent
+       BBN Communications
+       50 Moulton Street
+       Cambridge, MA 02138
+
+       Phone: (617) 873-3988
+
+       EMail: kent@BBN.COM
+
+
+       John Linn
+       Secure Systems
+       Digital Equipment Corporation
+       85 Swanson Road, BXB1-2/D04
+       Boxborough, MA  01719-1326
+
+       Phone: 508-264-5491
+
+       EMail: Linn@ultra.enet.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Linn                                                    [Page 25]
+
\ No newline at end of file