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 19992.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 theAdams & 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 19992.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 19992.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