rfc1422.txt

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

   3.4.2.2  Ensuring the Uniqueness of Distinguished Names

   A fundamental requirement of this certification scheme is that
   certificates are not issued to distinct entities under the same
   distinguished name.  This requirement is important to the success of
   distributed management for the certification hierarchy.  The IPRA
   will not certify two PCAs with the same distinguished name and no PCA
   may certify two CAs with the same DN.  However, since PCAs are
   expected to certify organizational CAs in widely disjoint portions of
   the directory namespace, and since X.500 directories are not
   ubiquitous, a facility is required for coordination among PCAs to
   ensure the uniqueness of CA DNs.  (This architecture allows multiple
   PCAs to certify residential CAs and thus multiple, distinct
   residential CAs with identical DNs may come into existence, at least
   until such time as civil authorities assume responsibilities for such
   certification.  Thus, on an interim basis, the architecture
   explicitly accommodates the potential for duplicate residential CA



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


   DNs.)

   In support of the uniqueness requirement, the IPRA will establish and
   maintain a database to detect potential, unintended duplicate
   certification of CA distinguished names.  This database will be made
   accessible to all PCAs via an email interface.  Each entry in this
   database will consist of a 4-tuple.  The first element in each entry
   is a hash value, computed on a canonical, ASN.1 encoded
   representation of a CA distinguished name.  The second element
   contains the subjectPublicKey that appears in the CA's certificate.
   The third element is the distinguished name of the PCA which
   registered the entry.  The fourth element consists of the date and
   time at which the entry was made, as established by the IPRA.  This
   database structure provides a degree of privacy for CAs registered by
   PCAs, while providing a facility for ensuring global uniqueness of CA
   DNs certified in this scheme.

   In order to avoid conflicts, a PCA should query the database using a
   CA DN hash value as a search key, prior to certifying a CA.  The
   database will return any entries which match the query, i.e., which
   have the same CA DN.  The PCA can use the information contained in
   any returned entries to determine if any PCAs should be contacted to
   resolve possible DN conflicts.  If no potential conflicts appear, a
   PCA can then submit a candidate entry, consisting of the first three
   element values, plus any entries returned by the query.  The database
   will register this entry, supplying the time and date stamp, only if
   two conditions are met: (1) the first two elements (the CA DN hash
   and the CA subjectPublicKey) of the candidate entry together must be
   unique and, (2) any other entries included in the submission must
   match what the current database would return if the query
   corresponding to the candidate entry were submitted.

   If the database detects a conflicting entry (failure of case 1
   above), or if the submission indicates that the PCA's perception of
   possible conflicting entries is not current (failure of case 2), the
   submission is rejected and the database will return the potential
   conflicting entry (entries).  If the submission is successful, the
   database will return the timestamped new entry.  The database does
   not, in itself, guarantee uniqueness of CA DNs as it allows for two
   DNs associated with different public components to be registered.
   Rather, it is the responsibility of PCAs to coordinate with one
   another whenever the database indicates a potential DN conflict and
   to resolve such conflicts prior to certification of CAs.  Details of
   the protocol used to access the database will be provided in another
   document.

   As noted earlier, a CA may be certified under more than one PCA,
   e.g., because the CA wants to issue certificates under two different



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


   policies.  If a CA is certified by multiple different PCAs, the CA
   must employ a different public key pair for each PCA.  In such
   circumstances the certificate issued to the CA by each PCA will
   contain a different subjectPublicKey and thus will represent a
   different entry in this database.  The same situation may arise if
   multiple, equivalent residential CAs are certified by different PCAs.

   To complete the strategy for ensuring uniqueness of DNs, there is a
   DN subordination requirement levied on CAs.  In general, CAs are
   expected to sign certificates only if the subject DN in the
   certificate is subordinate to the issuer (CA) DN.  This ensures that
   certificates issued by a CA are syntactically constrained to refer to
   subordinate entities in the X.500 directory information tree (DIT),
   and this further limits the possibility of duplicate DN registration.
   CAs may sign certificates which do not comply with this requirement
   if the certificates are "cross-certificates" or "reverse
   certificates" (see X.509) used with applications other than PEM.

   The IPRA also will establish and maintain a separate database to
   detect potential duplicate certification of (residential) user
   distinguished names.  Each entry in this database will consist of 4-
   tuple as above, but the first components is the hash of a residential
   user DN and the third component is the DN of the residential CA DN
   which registered the user.  This structure provides a degree of
   privacy for users registered by CAs which service residential users
   while providing a facility for ensuring global uniqueness of user DNs
   certified under this scheme.  The same database access facilities are
   provided as described above for the CA database.  Here it is the
   responsibility of the CAs to coordinate whenever the database
   indicates a potential conflict and to resolve the conflict prior to
   (residential) user certification.

   3.4.2.3  Accuracy of Distinguished Names

   As noted above, the IPRA will make a reasonable effort to ensure that
   PCA DNs are accurate.  The procedures employed to ensure the accuracy
   of a CA distinguished name, i.e., the confidence attached to the
   DN/public component binding implied by a certificate, will vary
   according to PCA policy.  However, it is expected that every PCA will
   make a good faith effort to ensure the legitimacy of each CA DN
   certified by the PCA.  Part of this effort should include a check
   that the purported CA DN is consistent with any applicable national
   standards for DN assignment, e.g., NADF recommendations within North
   America [5,9].







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


   3.4.2.4  Distinguished Name Conventions

   A few basic DN conventions are included in the IPRA policy.  The IPRA
   will certify PCAs, but not CAs nor users.  PCAs will certify CAs, but
   not users.  These conventions are required to allow simple
   certificate validation within PEM, as described later.  Certificates
   issued by CAs (for use with PEM) will be for users or for other CAs,
   either of which must have DNs subordinate to that of the issuing CA.

   The attributes employed in constructing DNs will be specified in a
   list maintained by the IANA, to provide a coordinated basis for
   attribute identification for all applications employing DNs.  This
   list will initially be populated with attributes taken from X.520.
   This document does not impose detailed restrictions on the attributes
   used to identify different entities to which certificates are issued,
   but PCAs may impose such restrictions as part of their policies.
   PCAs, CAs and users are urged to employ only those DN attributes
   which have printable representations, to facilitate display and
   entry.

   3.4.2.5  CRL Management

   Among the procedures articulated by each PCA in its policy statement
   are procedures for the maintenance and distribution of CRLs by the
   PCA itself and by its subordinate CAs.  The frequency of issue of
   CRLs may vary according to PCA-specific policy, but every PCA and CA
   must issue a CRL upon inception to provide a basis for uniform
   certificate validation procedures throughout the Internet hierarchy.
   The IPRA will maintain a CRL for all the PCAs it certifies and this
   CRL will be updated monthly.  Each PCA will maintain a CRL for all of
   the CAs which it certifies and these CRLs will be updated in
   accordance with each PCA's policy.   The format for these CRLs is
   that specified in Section 3.5.2 of the document.

   In the absence of ubiquitous X.500 directory services, the IPRA will
   require each PCA to provide, for its users, robust database access to
   CRLs for the Internet hierarchy, i.e., the IPRA CRL, PCA CRLs, and
   CRLs from all CAs.  The means by which this database is implemented
   is to be coordinated between the IPRA and PCAs.  This database will
   be accessible via email as specified in RFC 1424, both for retrieval
   of (current) CRLs by any user, and for submission of new CRLs by CAs,
   PCAs and the IPRA.  Individual PCAs also may elect to maintain CRL
   archives for their CAs, but this is not required by this policy.

   3.4.2.6  Public Key Algorithm Licensing Issues

   This certification hierarchy is architecturally independent of any
   specific digital signature (public key) algorithm.  Some algorithms,



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


   employed for signing certificates and validating certificate
   signatures, are patented in some countries.  The IPRA will not grant
   a license to any PCA for the use of any signature algorithm in
   conjunction with the management of this certification hierarchy.  The
   IPRA will acquire, for itself, any licenses needed for it to sign
   certificates and CRLs for PCAs, for all algorithms which the IPRA
   supports.  Every PCA will be required to represent to the IPRA that
   the PCA has obtained any licenses required to issue (sign)
   certificates and CRLs in the environment(s) which the PCA will serve.

   For example, the RSA cryptosystem is patented in the United States
   and thus any PCA operating in the U.S. and using RSA to sign
   certificates and CRLs must represent that it has a valid license to
   employ the RSA algorithm in this fashion.  In contrast, a PCA
   employing RSA and operating outside of the U.S. would represent that
   it is exempt from these licensing constraints.

   3.4.3  Policy Certification Authorities

   The policy statement submitted by a prospective PCA must address the
   topics in the following outline.  Additional policy information may
   be contained in the statement, but PCAs are requested not to use
   these statements as advertising vehicles.

   1. PCA Identity-  The DN of the PCA must be specified.  A postal
   address, an Internet mail address, and telephone (and optional fax)
   numbers must be provided for (human) contact with the PCA.  The date
   on which this statement is effective, and its scheduled duration must
   be specified.

   2. PCA Scope- Each PCA must describe the community which the PCA
   plans to serve.  A PCA should indicate if it will certify
   organizational, residential, and/or PERSONA CAs.   There is not a
   requirement that a single PCA serve only one type of CA, but if a PCA
   serves multiple types of CAs, the policy statement must specify
   clearly how a user can distinguish among these classes.  If the PCA
   will operate CAs to directly serve residential or PERSONA users, it
   must so state.

   3. PCA Security & Privacy- Each PCA must specify the technical and
   procedural security measures it will employ in the generation and
   protection of its component pair.  If any security requirements are
   imposed on CAs certified by the PCA these must be specified as well.
   A PCA also must specify what measures it will take to protect the
   privacy of any information collected in the course of certifying CAs.
   If the PCA operates one or more CAs directly, to serve residential or
   PERSONA users, then this statement on privacy measures applies to
   these CAs as well.



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


   4. Certification Policy-  Each PCA must specify the policy and
   procedures which govern its certification of CAs and how this policy
   applies transitively to entities (users or subordinate CAs) certified
   by these CAs.  For example, a PCA must state what procedure is
   employed to verify the claimed identity of a CA, and the CA's right
   to use a DN.  Similarly, if any requirements are imposed on CAs to