rfc2510.txt

PKIX的RFC英文文档

   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             Standards Track                    [Page 12]

RFC 2510          PKI Certificate Management Protocols        March 1999


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
                    -->>--confirmation message-->>--
                                                     verify confirmation

   (Where verification of the 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             Standards Track                    [Page 13]

RFC 2510          PKI Certificate Management Protocols        March 1999


   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             Standards Track                    [Page 14]

RFC 2510          PKI Certificate Management Protocols        March 1999


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

   This discussion only applies to CAs that are a root CA for some end
   entity.

   The basis of the procedure described here is that the CA protects its
   new public key using its previous private key and vice versa. Thus
   when a CA updates its key pair it must generate two extra
   cACertificate attribute values if certificates are made available
   using an X.500 directory (for a total of four:  OldWithOld;
   OldWithNew; NewWithOld; and NewWithNew).

   When a CA changes its key pair those entities who have acquired the
   old CA public key via "out-of-band" means are most affected. It is
   these end entities who will need access to the new CA public key
   protected with the old CA private key. However, they will only
   require this for a limited period (until they have acquired the new
   CA public key via the "out-of-band" mechanism). This will typically
   be easily achieved when these end entities' certificates expire.

   The data structure used to protect the new and old CA public keys is
   a standard certificate (which may also contain extensions). There are
   no new data structures required.

   Note 1. This scheme does not make use of any of the X.509 v3
   extensions as it must be able to work even for version 1
   certificates. The presence of the KeyIdentifier extension would make
   for efficiency improvements.

   Note 2. While the scheme could be generalized to cover cases where
   the CA updates its key pair more than once during the validity period
   of one of its end entities' certificates, this generalization seems
   of dubious value. Not having this generalization simply means that
   the validity period of a CA key pair must be greater than the
   validity period of any certificate issued by that CA using that key
   pair.



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


   Note 3.This scheme forces end entities to acquire the new CA public
   key on the expiry of the last certificate they owned that was signed
   with the old CA private key (via the "out-of-band" means).
   Certificate and/or key update operations occurring at other times do
   not necessarily require this (depending on the end entity's
   equipment).

2.4.1 CA Operator actions

   To change the key of the CA, the CA operator does the following:

      1. Generate a new key pair;

      2. Create a certificate containing the old CA public key signed
         with the new private key (the "old with new" certificate);

      3. Create a certificate containing the new CA public key signed
         with the old private key (the "new with old" certificate);

      4. Create a certificate containing the new CA public key signed
         with the new private key (the "new with new" certificate);

      5. Publish these new certificates via the directory and/or other
         means (perhaps using a CAKeyUpdAnn message);

      6. Export the new CA public key so that end entities may acquire
         it using the "out-of-band" mechanism (if required).

   The old CA private key is then no longer required. The old CA public
   key will however remain in use for some time. The time when the old
   CA public key is no longer required (other than for non-repudiation)
   will be when all end entities of this CA have securely acquired the
   new CA public key.

   The "old with new" certificate must have a validity period starting
   at the generation time of the old key pair and ending at the expiry
   date of the old public key.

   The "new with old" certificate must have a validity period starting
   at the generation time of the new key pair and ending at the time by
   which all end entities of this CA will securely possess the new CA
   public key (at the latest, the expiry date of the old public key).

   The "new with new" certificate must have a validity period starting
   at the generation time of the new key pair and ending at the time by
   which the CA will next update its key pair.





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


2.4.2 Verifying Certificates.

   Normally when verifying a signature, the verifier verifies (among
   other things) the certificate containing the public key of the
   signer. However, once a CA is allowed to update its key there are a
   range of new possibilities. These are shown in the table below.

               Repository contains NEW     Repository contains only OLD
                 and OLD public keys        public key (due to, e.g.,
                                             delay in publication)

                  PSE      PSE Contains  PSE Contains    PSE Contains
               Contains     OLD public    NEW public      OLD public
              NEW public       key            key            key
                  key

   Signer's   Case 1:      Case 3:       Case 5:        Case 7:
   certifi-   This is      In this case  Although the   In this case
   cate is    the          the verifier  CA operator    the CA
   protected  standard     must access   has not        operator  has
   using NEW  case where   the           updated the    not updated
   public     the          directory in  directory the  the directory
   key        verifier     order to get  verifier can   and so the
              can          the value of  verify the     verification
              directly     the NEW       certificate    will FAIL
              verify the   public key    directly -
              certificate                this is thus
              without                    the same as
              using the                  case 1.
              directory

   Signer's   Case 2:      Case 4:       Case 6:        Case 8:
   certifi-   In this      In this case  The verifier   Although the
   cate is    case the     the verifier  thinks this    CA operator