rfc1114.txt

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

   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 co