rfc1422.txt

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

   validate the identity of users, these requirements must be specified.
   Since all PCAs are required to cooperate in the resolution of
   potential DN conflicts, each PCA is required to specify the procedure
   it will employ to resolve such conflicts.  If the PCA imposes a
   maximum validity interval for the CA certificates it issues, and/or
   for user (or subordinate CA) certificates issued by the CAs it
   certifies, then these restrictions must be specified.

   5. CRL Management-  Each PCA must specify the frequency with which it
   will issue scheduled CRLs.  It also must specify any constraints it
   imposes on the frequency of scheduled issue of CRLs by the CAs it
   certifies, and by subordinate CAs.  Both maximum and minimum
   constraints should be specified.  Since the IPRA policy calls for
   each CRL issued by a CA to be forwarded to the cognizant PCA, each
   PCA must specify a mailbox address to which CRLs are to be
   transmitted.  The PCA also must specify a mailbox address for CRL
   queries.  If the PCA offers any additional CRL management services,
   e.g., archiving of old CRLs, then procedures for invoking these
   services must be specified.  If the PCA requires CAs to provide any
   additional CRL management services, such services must be specified
   here.

   6. Naming Conventions- If the PCA imposes any conventions on DNs used
   by the CAs it certifies, or by entities certified by these CAs, these
   conventions must be specified.  If any semantics are associated with
   such conventions, these semantics must be specified.

   7. Business Issues- If a legal agreement must be executed between a
   PCA and the CAs it certifies, reference to that agreement must be
   noted, but the agreement itself ought not be a part of the policy
   statement.  Similarly, if any fees are charged by the PCA this should
   be noted, but the fee structure per se ought not be part of this
   policy statement.

   8. Other- Any other topics the PCA deems relevant to a statement of
   its policy can be included.  However, the PCA should be aware that a
   policy statement is considered to be an immutable, long lived
   document and thus considerable care should be exercised in deciding
   what material is to be included in the statement.






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


   3.4.4  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".  X.509 imposes few constraints on CAs, but practical
   implementation of a worldwide certification system requires
   establishment of technical and procedural conventions by which all
   CAs are expected to abide.  Such conventions are established
   throughout this document.  All CAs are required to maintain a
   database of the DNs which they have certified and to take measures to
   ensure that they do not certify duplicate DNs, either for users or
   for subordinate CAs.

   It is critical that the private component of a CA be afforded a high
   level of security, otherwise the authenticity guarantee implied by
   certificates signed by the CA is voided.  Some PCAs may impose
   stringent requirements on CAs within their purview to ensure that a
   high level of security is afforded the certificate signing process,
   but not all PCAs are expected to impose such constraints.

   3.4.4.1  Organizational CAs

   Many of the CAs certified by PCAs are expected to represent
   organizations.  A wide range of organizations are encompassed by this
   model: commercial, governmental, educational, non-profit,
   professional societies, etc.  The common thread is that the entities
   certified by these CAs have some form of affiliation with the
   organization.  The object classes for organizations, organizational
   units, organizational persons, organizational roles, etc., as defined
   in X.521, form the models for entities certified by such CAs.  The
   affiliation implied by organizational certification motivates the DN
   subordination requirement cited in Section 3.4.2.4.

   As an example, an organizational user certificate might contain a
   subject DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge"
   O = "Bolt Beranek and Newman" OU = "Communications Division" CN =
   "Steve Kent".  The issuer of this certificate might have a DN of the
   form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek
   and Newman".  Note that the organizational unit attribute is omitted
   from the issuer DN, implying that there is no CA dedicated to the
   "Communications Division".

   3.4.4.2  Residential CAs

   Users may wish to obtain certificates which do not imply any
   organizational affiliation but which do purport to accurately and
   uniquely identify them.  Such users can be registered as residential
   persons and the DN of such a user should be consistent with the



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


   attributes of the corresponding X.521 object class.  Over time we
   anticipate that such users will be accommodated by civil government
   entities who will assume electronic certification responsibility at
   geographically designated points in the naming hierarchy.  Until
   civil authorities are prepared to issue certificates of this form,
   residential user CAs will accommodate such users.

   Because residential CAs may be operated under the auspices of
   multiple PCAs, there is a potential for the same residential CA DN to
   be assumed by several distinct entities.  This represents the one
   exception to the rule articulated throughout this document that no
   two entities may have the same DN.  This conflict is tolerated so as
   to allow residential CAs to be established offering different
   policies.  Two requirements are levied upon residential CAs as a
   result: (1) residential CAs must employ the residential DN conflict
   detection database maintained by the IPRA, and (2) residential CAs
   must coordinate to ensure that they do not assign duplicate
   certificate serial numbers.

   As an example, a residential user certificate might include a subject
   name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19
   North Square" CN = "Paul Revere."  The issuer of that certificate
   might have a DN of the form: C = "US"  SP = "Massachusetts" L =
   "Boston".  Note that the issuer DN is superior to the subject DN, as
   required by the IPRA policy described earlier.

   3.4.4.3  PERSONA CAs

   One or more CAs will be established to accommodate users who wish to
   conceal their identities while making use of PEM security features,
   e.g., to preserve the anonymity offered by "arbitrary" mailbox names
   in the current mail environment.  In this case the certifying
   authority is explicitly NOT vouching for the identity of the user.
   All such certificates are issued under a PERSONA CA, subordinate to a
   PCA with a PERSONA policy, to warn users explicitly that the subject
   DN is NOT a validated user identity.  To minimize the possibility of
   syntactic confusion with certificates which do purport to specify an
   authenticated user identity, a PERSONA certificate is issued as a
   form of organizational user certificate, not a residential user
   certificate.  There are no explicit, reserved words used to identify
   PERSONA user certificates.

   A CA issuing PERSONA certificates must institute procedures to ensure
   that it does not issue the same subject DN to multiple users (a
   constraint required for all certificates of any type issued by any
   CA).  There are no requirements on an issuer of PERSONA certificates
   to maintain any other records that might bind the true identity of
   the subject to his certificate.  However, a CA issuing such



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


   certificates must establish procedures (not specified in this
   document) in order to allow the holder of a PERSONA certificate to
   request that his certificate be revoked (i.e., listed on a CRL).

   As an example, a PERSONA user certificate might include a subject DN
   of the form:  C = "US" SP = "Massachusetts" L = "Boston" O =
   "Pseudonyms R US" CN = "Paul Revere."  The issuer of this certificate
   might have a DN of the form: C = "US"  SP = "Massachusetts" L =
   "Boston" O = "Pseudonyms R US".  Note the differences between this
   PERSONA user certificate for "Paul Revere" and the corresponding
   residential user certificate for the same common name.

   3.4.4.4  CA Responsibilities for CRL Management

   As X.500 directory servers become available, CRLs should be
   maintained and accessed via these servers.  However, prior to
   widespread deployment of X.500 directories, this document adopts some
   additional requirements for CRL management by CAs and PCAs.  As per
   X.509, each CA is required to maintain a CRL (in the format specified
   by this document in Appendix A) which contains entries for all
   certificates issued and later revoked by the CA.  Once a certificate
   is entered on a CRL it remains there until the validity interval
   expires.  Each PCA is required to maintain a CRL for revoked CA
   certificates within its domain.  The interval at which a CA issues a
   CRL is not fixed by this document, but the PCAs may establish minimum
   and maximum intervals for such issuance.

   As noted earlier, each PCA will provide access to a database
   containing CRLs issued by the IPRA, PCAs, and all CAs.  In support of
   this requirement, each CA must supply its current CRL to its PCA in a
   fashion consistent with CRL issuance rules imposed by the PCA and
   with the next scheduled issue date specified by the CA (see Section
   3.5.1).  CAs may distribute CRLs to subordinate UAs using the CRL
   processing type available in PEM messages (see RFC 1421).  CAs also
   may provide access to CRLs via the database mechanism described in
   RFC 1424 and alluded to immediately above.

   3.5  Certificate Revocation

   3.5.1  X.509 CRLs

   X.509 states that it is a CA's responsibility to maintain: "a time-
   stamped list of the certificates it issued which have been revoked."
   There are two primary reasons for a CA to revoke a certificate, i.e.,
   suspected compromise of a private component (invalidating the
   corresponding public component) or change of user affiliation
   (invalidating the DN).  The use of Certificate Revocation Lists
   (CRLs) as defined in X.509 is one means of propagating information



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


   relative to certificate revocation, though it is not a perfect
   mechanism.  In particular, an X.509 CRL indicates only the age of the
   information contained in it; it does not provide any basis for
   determining if the list is the most current CRL available from a
   given CA.

   The proposed architecture establishes a format for a CRL in which not
   only the date of issue, but also the next scheduled date of issue is
   specified.  Adopting this convention, when the next scheduled issue
   date arrives a CA (Throughout this section, when the term "CA" is
   employed, it should be interpreted broadly, to include the IPRA and
   PCAs as well as organizational, residential, and PERSONA CAs.) will
   issue a new CRL, 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 CRLs are issued by that CA.  Note that this does
   not preclude CRL issuance on a more frequent basis, e.g., in case of
   some emergency, but no system-wide mechanisms are architected for
   alerting users that such an unscheduled issuance has taken place.
   This scheduled CRL issuance convention allows users (UAs) to
   determine whether a given CRL is "out of date," a facility not
   available from the (1988) X.509 CRL format.

   The description of CRL management in the text and the format for CRLs
   specified in X.509 (1988) are inconsistent.  For example, the latter
   associates an issuer distinguished name with each revoked certificate
   even though the text states that a CRL contains entries for only a
   single issuer (which is separately specified in the CRL format).  The
   CRL format adopted for PEM is a (simplified) format consistent with
   the text of X.509, but not identical to the accompanying format. The
   ASN.1 format for CRLs used with PEM is provided in Appendix A.

   X.509 also defines a syntax for the "time-stamped list of revoked
   certificates representing other CAs."  This syntax, the
   "AuthorityRevocationList" (ARL) allows the list t