rfc1114.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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]