rfc1422.txt

<VC++网络游戏建摸与实现>源代码

   handling."   In the Internet environment, programs such as rand mh
   and Gnu emacs rmail are UAs.  UAs exchange messages by calling on a
   supporting Message Transfer Service (MTS), e.g., the SMTP mail relays
   used in the Internet.

   3.4.1.1  Generating and Protecting Component Pairs

   A UA process supporting PEM must protect the private component of its
   associated entity (e.g., a human user or a mailing list) from
   disclosure, though the means by which this is effected is a local
   matter.  It is essential that the user take all available precautions
   to protect his private component as the secrecy of this value is
   central to the security offered by PEM to that user.   For example,
   the private component might be stored in encrypted form, protected
   with a locally managed symmetric encryption key (e.g., using DES).
   The user would supply a password or passphrase which would be
   employed as a symmetric key to decrypt the private component when
   required for PEM processing (either on a per message or per session
   basis).  Alternatively, the private component might be stored on a
   diskette which would be inserted by the user whenever he originated
   or received PEM messages.  Explicit zeroing of memory locations where
   this component transiently resides could provide further protection.
   Other precautions, based on local operating system security
   facilities, also should be employed.

   It is recommended that each user employ ancillary software (not
   otherwise associated with normal UA operation) or hardware to
   generate his personal public-key component pair.  Software for
   generating user component pairs will be available as part of the
   reference implementation of PEM distributed freely in the U.S.
   portion of the Internet.  It is critically important that the
   component pair generation procedure be effected in as secure a
   fashion as possible, to ensure that the resulting private component
   is unpredictable.  Introduction of adequate randomness into the
   component pair generation procedure is potentially the most difficult
   aspect of this process and the user is advised to pay particular
   attention to this aspect.  (Component pairs employed in public-key
   cryptosystems tend to be large integers which must be "randomly"
   selected subject to mathematical constraints imposed by the
   cryptosystem.  Input(s) used to seed the component pair generation
   process must be as unpredictable as possible.  An example of a poor
   random number selection technique is one in which a pseudo-random
   number generator is seeded solely with the current date and time.  An
   attacker who could determine approximately when a component pair was
   generated could easily regenerate candidate component pairs and
   compare the public component to the user's public component to detect
   when the corresponding private component had been found.)




Kent                                                           [Page 10]

RFC 1422           Certificate-Based Key Management        February 1993


   There is no requirement imposed by this architecture that anyone
   other than the user, including any certification authority, have
   access to the user's private component.  Thus a user may retain his
   component pair even if his certificate changes, e.g., due to rollover
   in the validity interval or because of a change of certifying
   authority.  Even if a user is issued a certificate in the context of
   his employment, there is generally no requirement that the employer
   have access to the user's private component.  The rationale is that
   any messages signed by the user are verifiable using his public
   component.   In the event that the corresponding private component
   becomes unavailable, any ENCRYPTED messages directed to the user
   would be indecipherable and would require retransmission.

   Note that if the user stores messages in ENCRYPTED form, these
   messages also would become indecipherable in the event that the
   private component is lost or changed.  To minimize the potential for
   loss of data in such circumstances messages can be transformed into
   MIC-ONLY or MIC-CLEAR form if cryptographically-enforced
   confidentiality is not required for the messages stored within the
   user's computer.  Alternatively, these transformed messages might be
   forwarded in ENCRYPTED form to a (trivial) distribution list which
   serves in a backup capacity and for which the user's employer holds
   the private component.

   A user may possess multiple certificates which may embody the same or
   different public components.  For example, these certificates might
   represent  a current and a former organizational user identity and a
   residential user identity.  It is recommended that a PEM UA be
   capable of supporting a user who possess multiple certificates,
   irrespective of whether the certificates associated with the user
   contain the same or different DNs or public components.

   3.4.1.2  User Registration

   Most details of user registration are a local matter, subject to
   policies established by the user's CA and the PCA under which that CA
   has been certified.  In general a user must provide, at a minimum,
   his public component and distinguished name to a CA, or a
   representative thereof, for inclusion in the user's certificate.
   (The user also might provide a  complete certificate, minus the
   signature, as described in RFC 1424.)  The CA will employ some means,
   specified by the CA in accordance with the policy of its PCA, to
   validate the user's claimed identity and to ensure that the public
   component provided is associated with the user whose distinguished
   name is to be bound into the certificate.  (In the case of PERSONA
   certificates, described below, the procedure is a bit different.) The
   certifying authority generates a certificate containing the user's
   distinguished name and public component, the authority's



Kent                                                           [Page 11]

RFC 1422           Certificate-Based Key Management        February 1993


   distinguished name and other information (see Section 3.3) and signs
   the result using the private component of the authority.

   3.4.1.3  CRL Management

   Mechanisms for managing a UA certificate cache are, in typical
   standards parlance, a local matter.  However, proper maintenance of
   such a cache is critical to the correct, secure operation of a PEM UA
   and provides a basis for improved performance.  Moreover, use of a
   cache permits a PEM UA to operate in the absence of directories (and
   in circumstances where directories are inaccessible).  The following
   discussion  provides a paradigm for one aspect of cache management,
   namely the processing of CRLs, the functional equivalent of which
   must be embodied in any PEM UA implementation compliant with this
   document.  The specifications for CRLs used with PEM are provided in
   Section 3.5.

   X.500 makes provision for the storage of CRLs as directory attributes
   associated with CA entries.  Thus, when X.500 directories become
   widely available, UAs can retrieve CRLs from directories as required.
   In the interim, the IPRA will coordinate with PCAs to provide a
   robust database facility which will contain CRLs issued by the IPRA,
   by PCAs, and by all CAs.  Access to this database will be provided
   through mailboxes maintained by each PCA.  Every PEM UA must provide
   a facility for requesting CRLs from this database using the
   mechanisms defined in RFC 1424.  Thus the UA must include a
   configuration parameter which specifies one or more mailbox addresses
   from which CRLs may be retrieved.  Access to the CRL database may be
   automated, e.g., as part of the certificate validation process (see
   Section 3.6) or may be user directed.  Responses to CRL requests will
   employ the PEM header format specified in RFC 1421 for CRL
   propagation.  As noted in RFC 1421, every PEM UA must be capable of
   processing CRLs distributed via such messages.  This message format
   also may be employed to support a "push" (versus a "pull") model of
   CRL distribution, i.e., to support unsolicited distribution of CRLs.

   CRLs received by a PEM UA must be validated (A CRL is validated in
   much the same manner as a certificate, i.e., the CIC (see RFC 1113)
   is calculated and compared against the decrypted signature value
   obtained from the CRL.  See Section 3.6 for additional details
   related to validation of certificates.) prior to being processed
   against any cached certificate information.  Any cache entries which
   match CRL entries should be marked as revoked, but it is not
   necessary to delete cache entries marked as revoked nor to delete
   subordinate entries.  In processing a CRL against the cache it is
   important to recall that certificate serial numbers are unique only
   for each issuer and that multiple, distinct CRLs may be issued under
   the same CA DN (signed using different private components), so care



Kent                                                           [Page 12]

RFC 1422           Certificate-Based Key Management        February 1993


   must be exercised in effecting this cache search.  (This situation
   may arise either because an organizational CA is certified by
   multiple PCAs, or because multiple residential CAs are certified
   under different PCAs.)

   This procedure applies to cache entries associated with PCAs and CAs,
   as well as user entries.  The UA also must retain each CRL to screen
   incoming messages to detect use of revoked certificates carried in
   PEM message headers.  Thus a UA must be capable of processing and
   retaining CRLs issued by the IPRA (which will list revoked PCA
   certificates), by any PCA (which will list revoked CA certificate
   issued by that PCA), and by any CA (which will list revoked user or
   subordinate CA certificates issued by that CA).

   3.4.1.4  Facilitating Interoperation

   In the absence of ubiquitous directory services or knowledge
   (acquired through out-of-band means) that a recipient already
   possesses the necessary issuer certificates, it is recommended that
   an originating (PEM) UA include sufficient certificates to permit
   validation of the user's public key.  To this end every PEM UA must
   be capable of including a full (originator) certification path, i.e.,
   including the user's certificate (using the "Originator-Certificate"
   field) and every superior (CA/PCA) certificate (using "Issuer-
   Certificate" fields) back to the IPRA, in a PEM message.  A PEM UA
   may send less than a full certification path, e.g., based on analysis
   of a recipient list, but a UA which provides this sort of
   optimization must also provide the user with a capability to force
   transmission of a full certification path.

   Optimization for the transmitted originator certification path may be
   effected by a UA as a side effect of the processing performed during
   message submission.  When an originator submits an ENCRYPTED message
   (as per RFC 1421, his UA must validate the certificates of the
   recipients (see Section 3.6).  In the course of performing this
   validation the UA can determine the minimum set of certificates which
   must be included to ensure that all recipients can process the
   received message.  Submission of a MIC-ONLY or MIC-CLEAR message (as
   per RFC 1421) does not entail validation of recipient certificates
   and thus it may not be possible for the originator's UA to determine
   the minimum certificate set as above.

   3.4.2  The Internet Policy Registration Authority (IPRA)

   The IPRA acts as the root of the certification hierarchy for the
   Internet community.  The public component of the IPRA forms the
   foundation for all certificate validation within this hierarchy.  The
   IPRA will be operated under the auspices of the Internet Society, an



Kent                                                           [Page 13]

RFC 1422           Certificate-Based Key Management        February 1993


   international, non-profit organization.  The IPRA certifies all PCAs,
   ensuring that they agree to abide by the Internet-wide policy
   established by the IPRA.  This policy, and the services provided by
   the IPRA, are detailed below.

   3.4.2.1  PCA Registration

   The IPRA certifies only PCAs, not CAs or users.  Each PCA must file
   with the IPRA a description of its proposed policy.  This document
   will be published as an informational RFC.  A copy of the document,
   signed by the IPRA (in the form of a PEM MIC-ONLY message) will be
   made available via electronic mail access by the IPRA.  This
   convention is adopted so that every Internet user has a reference
   point for determining the policies associated with the issuance of
   any certificate which he may encounter.  The existence of a digitally
   signed copy of the document ensures the immutability of the document.
   Authorization of a PCA to operate in the Internet hierarchy is
   signified by the publication of the policy document, and the issuance
   of a certificate to the PCA, signed by the IPRA.  An outline for PCA
   policy statements is contained in Section 3.4.3 of this document.

   As part of registration, each PCA will be required to execute a legal
   agreement with the IPRA, and to pay a fee to defray the costs of
   operating the IPRA.  Each a PCA must specify its distinguished name.
   The IPRA will take reasonable precautions to ensure that the
   distinguished name claimed by a PCA is legitimate, e.g., requiring
   the PCA to provide documentation supporting its claim to a DN.
   However, the certification of a PCA by the IPRA does not constitute a
   endorsement of the PCA's claim to this DN outside of the context of
   this certification system.