rfc1114.txt

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


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