draft-ietf-pkix-rfc2510bis-07.txt

PKIX的RFC英文文档

Adams & Farrell               Expires May 2003                   [Page 11]



      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.  Transport protocols for conveying these exchanges in 
   different environments (file based, on-line, E-mail, and WWW) are 
   beyond the scope of this document and are specified separately.





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               Expires May 2003                   [Page 12]




   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
   secret value) 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               Expires May 2003                   [Page 13]




   centralized key generation service - the actual key pair MAY have
   been generated elsewhere and transported to the end entity, RA, or CA
   using a (proprietary or standardized) key generation request/response
   protocol (outside the scope of this specification).

   There are thus three possibilities for the location of "key
   generation":  the end entity, an RA, or a CA.

2.2.1.4 Confirmation of successful certification

   Following the creation of an initial certificate for an end entity,
   additional assurance can be gained by having the end entity
   explicitly confirm successful receipt of the message containing (or
   indicating the creation of) the certificate. Naturally, this
   confirmation message must be protected (based on the initial
   authentication key or other means).

   This gives two further possibilities: confirmed or not.

2.2.2 Mandatory schemes

   The criteria above allow for a large number of initial registration /
   certification schemes. This specification mandates that conforming CA
   equipment, RA equipment, and EE equipment MUST support the second
   scheme listed below. Any entity MAY additionally support other
   schemes, if desired.

2.2.2.1 Centralized scheme

   In terms of the classification above, this scheme is, in some ways,
   the simplest possible, where:

   - initiation occurs at the certifying CA;
   - no on-line message authentication is required;
   - "key generation" occurs at the certifying CA (see Section 2.2.1.3);
   - no confirmation message is required.

   In terms of message flow, this scheme means that the only message
   required is sent from the CA to the end entity. The message must
   contain the entire PSE for the end entity. Some out-of-band means
   must be provided to allow the end entity to authenticate the message
   received and decrypt any encrypted values.











Adams & Farrell               Expires May 2003                   [Page 14]



2.2.2.2 Basic authenticated scheme

   In terms of the classification above, this scheme is where:

   - initiation occurs at the end entity;
   - message authentication is REQUIRED;
   - "key generation" occurs at the end entity (see Section 2.2.1.3);
   - a confirmation message is REQUIRED.

   In terms of message flow, the basic authenticated scheme is as
   follows:

      End entity                                          RA/CA
      ==========                                      =============
           out-of-band distribution of Initial Authentication
           Key (IAK) and reference value (RA/CA -> EE)
      Key generation
      Creation of certification request
      Protect request with IAK
                    -->>--certification request-->>--
                                                     verify request
                                                     process request
                                                     create response
                    --<<--certification response--<<--
      handle response
      create confirmation
                    -->>--cert conf message-->>--
                                                     verify confirmation
                                                     create response
                    --<<-- conf ack (optional)  --<<--
      handle response

   (Where verification of the cert confirmation message fails, the RA/CA 
   MUST revoke the newly issued certificate if it has been published or
   otherwise made available.)

2.3 Proof of Possession (POP) of Private Key

   In order to prevent certain attacks and to allow a CA/RA to properly
   check the validity of the binding between an end entity and a key
   pair, the PKI management operations specified here make it possible
   for an end entity to prove that it has possession of (i.e., is able
   to use) the private key corresponding to the public key for which a
   certificate is requested.  A given CA/RA is free to choose how to
   enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in-
   band messages) in its certification exchanges (i.e., this may be a
   policy issue).  However, it is REQUIRED that CAs/RAs MUST enforce POP
   by some means because there are currently many non-PKIX operational
   protocols in use (various electronic mail protocols are one example)
   that do not explicitly check the binding between the end entity and
   the private key.  Until operational protocols that do verify the



Adams & Farrell               Expires May 2003                   [Page 15]




   binding (for signature, encryption, and key agreement key pairs)
   exist, and are ubiquitous, this binding can only be assumed to have
   been verified by the CA/RA. Therefore, if the binding is not verified
   by the CA/RA, certificates in the Internet Public-Key Infrastructure
   end up being somewhat less meaningful.

   POP is accomplished in different ways depending upon the type of key
   for which a certificate is requested. If a key can be used for
   multiple purposes (e.g., an RSA key) then any appropriate method MAY
   be used (e.g., a key which may be used for signing, as well as other
   purposes, SHOULD NOT be sent to the CA/RA in order to prove
   possession).

   This specification explicitly allows for cases where an end entity
   supplies the relevant proof to an RA and the RA subsequently attests
   to the CA that the required proof has been received (and validated!).
   For example, an end entity wishing to have a signing key certified
   could send the appropriate signature to the RA which then simply
   notifies the relevant CA that the end entity has supplied the
   required proof. Of course, such a situation may be disallowed by some
   policies (e.g., CAs may be the only entities permitted to verify POP
   during certification).

2.3.1 Signature Keys

   For signature keys, the end entity can sign a value to prove
   possession of the private key.

2.3.2 Encryption Keys

   For encryption keys, the end entity can provide the private key to
   the CA/RA, or can be required to decrypt a value in order to prove
   possession of the private key (see Section 3.2.8). Decrypting a value
   can be achieved either directly or indirectly.

   The direct method is for the RA/CA to issue a random challenge to
   which an immediate response by the EE is required.

   The indirect method is to issue a certificate which is encrypted for
   the end entity (and have the end entity demonstrate its ability to
   decrypt this certificate in the confirmation message). This allows a
   CA to issue a certificate in a form which can only be used by the
   intended end entity.

   This specification encourages use of the indirect method because this
   requires no extra messages to be sent (i.e., the proof can be
   demonstrated using the {request, response, confirmation} triple of
   messages).





Adams & Farrell               Expires May 2003                   [Page 16]




2.3.3 Key Agreement Keys

   For key agreement keys, the end entity and the PKI management entity
   (i.e., CA or RA) must establish a shared secret key in order to prove
   that the end entity has possession of the private key.

   Note that this need not impose any restrictions on the keys that can
   be certified by a given CA -- in particular, for Diffie-Hellman keys
   the end entity may freely choose its algorithm parameters -- provided
   that the CA can generate a short-term (or one-time) key pair with the
   appropriate parameters when necessary.

2.4 Root CA key update