rfc1422.txt

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

   of the policies under which certificates are issued.

   Specifically, the architecture proposes a system in which user (or
   mailing list) certificates represent the leaves in a certification
   hierarchy.  This certification hierarchy is largely isomorphic to the
   X.500 directory naming hierarchy, with two exceptions: the IPRA forms
   the root of the tree (the root of the X.500 DIT is not instantiated
   as a node), and a number of Policy Certification Authorities (PCAs)
   form the "roots" of subtrees, each of which represents a different
   certification policy.

   Not every level in the directory hierarchy need correspond to a
   certification authority.  For example, the appearance of geographic
   entities in a distinguished name (e.g., countries, states, provinces,
   localities) does not require that various governments become
   certifying authorities in order to instantiate this architecture.
   However, it is anticipated that, over time, a number of such points
   in the hierarchy will be instantiated as CAs in order to simplify
   later transition of management to appropriate governmental
   authorities.

   These conventions minimize the complexity of validating user
   certificates, e.g., by making explicit the relationship between a



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


   certificate issuer and the user (via the naming hierarchy). Note that
   in this architecture, only PCAs may be certified by the IPRA, and
   every CA's certification path can be traced to a PCA, through zero or
   more CAs.  If a CA is certified by more than one PCA, each
   certificate issued by a PCA for the CA must contain a distinct public
   component.  These conventions result in a certification hierarchy
   which is a compatible subset of that permitted under X.509, with
   respect to both syntax and semantics.

   Although the key management architecture described in this document
   has been designed primarily to support privacy enhanced mail, this
   infrastructure also may, in principle, be used to support X.400 mail
   security facilities (as per 1988 X.411) and X.500 directory
   authentication facilities.  Thus, establishment of this
   infrastructure paves the way for use of these and other OSI protocols
   in the Internet in the future.  In the future, these certificates
   also may be employed in the provision of security services in other
   protocols in the TCP/IP and OSI suites as well.

   3.2  Relation to X.509 Architecture

   CCITT 1988 Recommendation X.509, "The Directory - Authentication
   Framework", defines a framework for authentication of entities
   involved in a distributed directory service.  Strong authentication,
   as defined in X.509, is accomplished with the use of public-key
   cryptosystems.  Unforgeable certificates are generated by
   certification authorities; these authorities may be organized
   hierarchically, though such organization is not required by X.509.
   There is no implied mapping between a certification hierarchy and the
   naming hierarchy imposed by directory system naming attributes.

   This document interprets the X.509 certificate mechanism to serve the
   needs of PEM in the Internet environment.  The certification
   hierarchy proposed in this document in support of privacy enhanced
   mail is intentionally a subset of that allowed under X.509.  This
   certification hierarchy also embodies semantics which are not
   explicitly addressed by X.509, but which are consistent with X.509
   precepts.  An overview of the rationale for these semantics is
   provided in Section 1.

   3.3  Certificate Definition

   Certificates are central to the key management architecture for X.509
   and PEM.  This section provides an overview of the syntax and a
   description of the semantics of certificates.  Appendix A includes
   the ASN.1 syntax for certificates.   A certificate includes the
   following contents:




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


       1.  version

       2.  serial number

       3.  signature (algorithm ID and parameters)

       4.  issuer name

       5.  validity period

       6.  subject name

       7.  subject public key (and associated algorithm ID)

   3.3.1  Version Number

   The version number field is intended to facilitate orderly changes in
   certificate formats over time.  The initial version number for
   certificates used in PEM is the X.509 default which has a value of
   zero (0), indicating the 1988 version.  PEM implementations are
   encouraged to accept later versions as they are endorsed by
   CCITT/ISO.

   3.3.2  Serial Number

   The serial number field provides a short form, unique identifier for
   each certificate generated by an issuer.  An issuer must ensure that
   no two distinct certificates with the same issuer DN contain the same
   serial number.  (This requirement must be met even when the
   certification function is effected on a distributed basis and/or when
   the same issuer DN is certified under two different PCAs.  This is
   especially critical for residential CAs certified under different
   PCAs.) The serial number is used in CRLs to identify revoked
   certificates, as described in Section 3.4.3.4.  Although this
   attribute is an integer, PEM UA processing of this attribute need not
   involve any arithmetic operations.  All PEM UA implementations must
   be capable of processing serial numbers at least 128 bits in length,
   and size-independent support serial numbers is encouraged.

   3.3.3  Signature

   This field specifies the algorithm used by the issuer to sign the
   certificate, and any parameters associated with the algorithm. (The
   certificate signature is appended to the data structure, as defined
   by the signature macro in X.509.  This algorithm identification
   information is replicated with the signature.)  The signature is
   validated by the UA processing a certificate, in order to determine
   that the integrity of its contents have not been modified subsequent



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


   to signing by a CA (IPRA, or PCA).  In this context, a signature is
   effected through the use of a Certificate Integrity Check (CIC)
   algorithm and a public-key encryption algorithm.  RFC 1423 contains
   the definitions and algorithm IDs for signature algorithms employed
   in this architecture.

   3.3.4  Subject Name

   A certificate provides a representation of its subject's identity in
   the form of a Distinguished Name (DN).  The fundamental binding
   ensured by the key management architecture is that between the public
   component and the user's identity in this form.  A distinguished name
   is an X.500 directory system concept and if a user is already
   registered in an X.500 directory, his distinguished name is defined
   via that registration.  Users who are not registered in a directory
   should keep in mind likely directory naming structure (schema) when
   selecting a distinguished name for inclusion in a certificate.

   3.3.5  Issuer Name

   A certificate provides a representation of its issuer's identity, in
   the form of a Distinguished Name.  The issuer identification is used
   to select the appropriate issuer public component to employ in
   performing certificate validation.  (If an issuer (CA) is certified
   by multiple PCAs, then the issuer DN does not uniquely identify the
   public component used to sign the certificate.  In such circumstances
   it may be necessary to attempt certificate validation using multiple
   public components, from certificates held by the issuer under
   different PCAs.  If the 1992 version of a certificate is employed,
   the issuer may employ distinct issuer UIDs in the certificates it
   issues, to further facilitate selection of the right issuer public
   component.) The issuer is the certifying authority (IPRA, PCA or CA)
   who vouches for the binding between the subject identity and the
   public key contained in the certificate.

   3.3.6  Validity Period

   A certificate carries a pair of date and time indications, indicating
   the start and end of the time period over which a certificate is
   intended to be used.  The duration of the interval may be constant
   for all user certificates issued by a given CA or it might differ
   based on the nature of the user's affiliation.  For example, an
   organization might issue certificates with shorter intervals to
   temporary employees versus permanent employees.  It is recommended
   that the UTCT (Coordinated Universal Time) values recorded here
   specify granularity to no more than the minute, even though finer
   granularity can be expressed in the format.  (Implementors are warned
   that no DER is defined for UTCT in X.509, thus transformation between



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


   local and transfer syntax must be performed carefully, e.g., when
   computing the hash value for a certificate.  For example, a UTCT
   value which includes explict, zero values for seconds would not
   produce the same hash value as one in which the seconds were
   omitted.) It also recommended that all times be expressed as
   Greenwich Mean Time (Zulu), to simplify comparisons and avoid
   confusion relating to daylight savings time.  Note that UTCT
   expresses the value of a year modulo 100 (with no indication of
   century), hence comparisons involving dates in different centuries
   must be performed with care.

   The longer the interval, the greater the likelihood that compromise
   of a private component or name change will render it invalid and thus
   require that the certificate be revoked.  Once revoked, the
   certificate must remain on the issuer's CRL (see Section 3.4.3.4)
   until the validity interval expires.  PCAs may impose restrictions on
   the maximum validity interval that may be elected by CAs operating in
   their certification domain (see Appendix B).

   3.3.7  Subject Public Key

   A certificate carries the public component of its associated subject,
   as well as an indication of the algorithm, and any algorithm
   parameters, with which the public component is to be used.  This
   algorithm identifier is independent of that which is specified in the
   signature field described above.  RFC 1423 specifies the algorithm
   identifiers which may be used in this context.

   3.4  Roles and Responsibilities

   One way to explain the architecture proposed by this document is to
   examine the roles which are defined for various entities in the
   architecture and to describe what is required of each entity in order
   for the proposed system to work properly.  The following sections
   identify four types of entities within this architecture: users and
   user agents, the Internet Policy Registration Authority, Policy
   Certification Authorities, and other Certification Authorities.  For
   each type of entity, this document specifies the procedures which the
   entity must execute as part of the architecture and the
   responsibilities the entity assumes as a function of its role in the
   architecture.

   3.4.1  Users and User Agents

   The term User Agent (UA) is taken from CCITT X.400 Message Handling
   Systems (MHS) Recommendations, which define it as follows: "In the
   context of message handling, the functional object, a component of
   MHS, by means of which a single direct user engages in message



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