rfc2510.txt

PKIX的RFC英文文档

   lines.
























Adams & Farrell             Standards Track                     [Page 6]

RFC 2510          PKI Certificate Management Protocols        March 1999


      +---+     cert. publish        +------------+      j
      |   |  <---------------------  | End Entity | <-------
      | C |             g            +------------+      "out-of-band"
      |   |                            | ^                loading
      | e |                            | |      initial
      | r |                          a | | b     registration/
      | t |                            | |       certification
      |   |                            | |      key pair recovery
      | / |                            | |      key pair update
      |   |                            | |      certificate update
      | C |  PKI "USERS"               V |      revocation request
      | R | -------------------+-+-----+-+------+-+-------------------
      | L |  PKI MANAGEMENT    | ^              | ^
      |   |    ENTITIES      a | | b          a | | b
      |   |                    V |              | |
      | R |             g   +------+    d       | |
      | e |   <------------ | RA   | <-----+    | |
      | p |      cert.      |      | ----+ |    | |
      | o |       publish   +------+   c | |    | |
      | s |                              | |    | |
      | i |                              V |    V |
      | t |          g                 +------------+   i
      | o |   <------------------------|     CA     |------->
      | r |          h                 +------------+  "out-of-band"
      | y |      cert. publish              | ^         publication
      |   |      CRL publish                | |
      +---+                                 | |    cross-certification
                                          e | | f  cross-certificate
                                            | |       update
                                            | |
                                            V |
                                          +------+
                                          | CA-2 |
                                          +------+

                           Figure 1 - PKI Entities

   At a high level the set of operations for which management messages
   are defined can be grouped as follows.

      1 CA establishment: When establishing a new CA, certain steps are
        required (e.g., production of initial CRLs, export of CA public
        key).

      2 End entity initialization: this includes importing a root CA
        public key and requesting information about the options
        supported by a PKI management entity.




Adams & Farrell             Standards Track                     [Page 7]

RFC 2510          PKI Certificate Management Protocols        March 1999


      3 Certification: various operations result in the creation of new
        certificates:

        3.1 initial registration/certification: This is the process
            whereby  an end entity first makes itself known to a CA or
            RA, prior to the CA issuing a certificate or certificates
            for that end entity. The end result of this process (when it
            is successful) is that a CA issues a certificate for an end
            entity's public key, and returns that certificate to the end
            entity and/or posts that certificate in a public repository.
            This process may, and typically will, involve multiple
            "steps", possibly including an initialization of the end
            entity's equipment. For example, the end entity's equipment
            must be securely initialized with the public key of a CA, to
            be used in validating certificate paths.  Furthermore, an
            end entity typically needs to be initialized with its own
            key pair(s).

        3.2 key pair update:  Every key pair needs to be updated
            regularly (i.e., replaced with a new key pair), and a new
            certificate needs to be issued.

        3.3 certificate update: As certificates expire they may be
            "refreshed" if nothing relevant in the environment has
            changed.

        3.4 CA key pair update: As with end entities, CA key pairs need
            to be updated regularly; however, different mechanisms are
            required.

        3.5 cross-certification request:  One CA requests issuance of a
            cross-certificate from another CA.  For the purposes of this
            standard, the following terms are defined.  A "cross-
            certificate" is a certificate in which the subject CA and
            the issuer CA are distinct and SubjectPublicKeyInfo contains
            a verification key (i.e., the certificate has been issued
            for the subject CA's signing key pair).  When it is
            necessary to distinguish more finely, the following terms
            may be used: a cross-certificate is called an "inter-domain
            cross-certificate" if the subject and issuer CAs belong to
            different administrative domains; it is called an "intra-
            domain cross-certificate" otherwise.









Adams & Farrell             Standards Track                     [Page 8]

RFC 2510          PKI Certificate Management Protocols        March 1999


   Notes:

   Note 1. The above definition of "cross-certificate" aligns with the
   defined term "CA-certificate" in X.509.  Note that this term is not
   to be confused with the X.500 "cACertificate" attribute type, which
   is unrelated.

   Note 2. In many environments the term "cross-certificate", unless
   further qualified, will be understood to be synonymous with "inter-
   domain cross-certificate" as defined above.

   Note 3. Issuance of cross-certificates may be, but is not
   necessarily, mutual; that is, two CAs may issue cross-certificates
   for each other.

        3.6 cross-certificate update: Similar to a normal certificate
            update but involving a cross-certificate.

      4 Certificate/CRL discovery operations: some PKI management
        operations result in the publication of certificates or CRLs:

        4.1 certificate publication: Having gone to the trouble of
            producing a certificate, some means for publishing it is
            needed.  The "means" defined in PKIX MAY involve the
            messages specified in Sections 3.3.13 - 3.3.16, or MAY
            involve other methods (LDAP, for example) as described in
            the "Operational Protocols" documents of the PKIX series of
            specifications.

        4.2 CRL publication: As for certificate publication.

      5 Recovery operations: some PKI management operations are used
        when an end entity has "lost" its PSE:

        5.1 key pair recovery:  As an option, user client key materials
            (e.g., a user's private key used for decryption purposes)
            MAY be backed up by a CA, an RA, or a key backup system
            associated with a CA or RA. If an entity needs to recover
            these backed up key materials (e.g., as a result of a
            forgotten password or a lost key chain file), a  protocol
            exchange may be needed to support such recovery.

      6 Revocation operations: some PKI operations result in the
        creation of new CRL entries and/or new CRLs:

        6.1 revocation request:  An authorized person advises a CA of an
            abnormal situation requiring certificate revocation.




Adams & Farrell             Standards Track                     [Page 9]

RFC 2510          PKI Certificate Management Protocols        March 1999


      7 PSE operations: whilst the definition of PSE operations (e.g.,
        moving a PSE, changing a PIN, etc.) are beyond the scope of this
        specification, we do define a PKIMessage (CertRepMessage) which
        can form the basis of such operations.

   Note that on-line protocols are not the only way of implementing the
   above operations.  For all operations there are off-line methods of
   achieving the same result, and this specification does not mandate
   use of on-line protocols.  For example, when hardware tokens are
   used, many of the operations MAY be achieved as part of the physical
   token delivery.

   Later sections define a set of standard messages supporting the above
   operations.  The protocols for conveying these exchanges in different
   environments (file based, on-line, E-mail, and WWW) is also
   specified.

2. Assumptions and restrictions

2.1 End entity initialization

   The first step for an end entity in dealing with PKI management
   entities is to request information about the PKI functions supported
   and to securely acquire a copy of the relevant root CA public key(s).

2.2 Initial registration/certification

   There are many schemes that can be used to achieve initial
   registration and certification of end entities. No one method is
   suitable for all situations due to the range of policies which a CA
   may implement and the variation in the types of end entity which can
   occur.

   We can however, classify the initial registration / certification
   schemes that are supported by this specification. Note that the word
   "initial", above, is crucial - we are dealing with the situation
   where the end entity in question has had no previous contact with the
   PKI. Where the end entity already possesses certified keys then some
   simplifications/alternatives are possible.

   Having classified the schemes that are supported by this
   specification we can then specify some as mandatory and some as
   optional. The goal is that the mandatory schemes cover a sufficient
   number of the cases which will arise in real use, whilst the optional
   schemes are available for special cases which arise less frequently.
   In this way we achieve a balance between flexibility and ease of
   implementation.




Adams & Farrell             Standards Track                    [Page 10]

RFC 2510          PKI Certificate Management Protocols        March 1999


   We will now describe the classification of initial registration /
   certification schemes.

2.2.1 Criteria used

2.2.1.1 Initiation of registration / certification

   In terms of the PKI messages which are produced we can regard the
   initiation of the initial registration / certification exchanges as
   occurring wherever the first PKI message relating to the end entity
   is produced. Note that the real-world initiation of the registration
   / certification procedure may occur elsewhere (e.g., a personnel
   department may telephone an RA operator).

   The possible locations are at the end entity, an RA, or a CA.

2.2.1.2 End entity message origin authentication

   The on-line messages produced by the end entity that requires a
   certificate may be authenticated or not. The requirement here is to
   authenticate the origin of any messages from the end entity to the
   PKI (CA/RA).

   In this specification, such authentication is achieved by the PKI
   (CA/RA) issuing the end entity with a secret value (initial
   authentication key) and reference value (used to identify the
   transaction) via some out-of-band means. The initial authentication
   key can then be used to protect relevant PKI messages.

   We can thus classify the initial registration/certification scheme
   according to whether or not the on-line end entity -> PKI messages
   are authenticated or not.

   Note 1: We do not discuss the authentication of the PKI -> end entity
   messages here as this is always REQUIRED. In any case, it can be
   achieved simply once the root-CA public key has been installed at the
   end entity's equipment or it can be based on the initial
   authentication key.

   Note 2: An initial registration / certification procedure can be
   secure where the messages from the end entity are authenticated via
   some out- of-band means (e.g., a subsequent visit).

2.2.1.3 Location of key generation

   In this specification, "key generation" is regarded as occurring
   wherever either the public or private component of a key pair first
   occurs in a PKIMessage. Note that this does not preclude a



Adams & Farrell             Standards Track                    [Page 11]

RFC 2510          PKI Certificate Management Protocols        March 1999


   centralized key generation service - the actual key pair MAY have
   been generated elsewhere and transported to the end entity, RA, or CA