rfc1114.txt

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

   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