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               Expires May 2003                   [Page 17]   Note 3. This scheme ensures that end entities will acquire the new CA    public key, at the latest by 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 repository 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 or before the    time by which the CA will next update its key pair.Adams & Farrell               Expires May 2003                   [Page 18]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          repository in repository the the repository   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.              repository   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   protected  verifier     can directly  is the         has not   using OLD  must         verify the    situation of   updated the   public     access the   certificate   case 2 and     repository the   key        repository   without       will access    verifier can              in order     using the     the            verify the              to get the   repository    repository;    certificate              value of                   however, the   directly -              the OLD                    verification   this is thus              public key                 will FAIL      the same as                                                        case 4.Adams & Farrell               Expires May 2003                   [Page 19]2.4.2.1 Verification in cases 1, 4, 5 and 8.   In these cases the verifier has a local copy of the CA public key   which can be used to verify the certificate directly. This is the   same as the situation where no key change has occurred.   Note that case 8 may arise between the time when the CA operator has   generated the new key pair and the time when the CA operator stores   the updated attributes in the repository. Case 5 can only arise if the   CA operator has issued both the signer's and verifier's certificates   during this "gap" (the CA operator SHOULD avoid this as it leads to   the failure cases described below).2.4.2.2 Verification in case 2.   In case 2 the verifier must get access to the old public key of the   CA. The verifier does the following:      1. Look up the caCertificate attribute in the repository and pick         the OldWithNew certificate (determined based on validity         periods; note that the subject and issuer fields must match);      2. Verify that this is correct using the new CA key (which the         verifier has locally);      3. If correct, check the signer's certificate using the old CA         key.   Case 2 will arise when the CA operator has issued the signer's   certificate, then changed key and then issued the verifier's   certificate, so it is quite a typical case.2.4.2.3 Verification in case 3.   In case 3 the verifier must get access to the new public key of the   CA. The verifier does the following:      1. Look up the CACertificate attribute in the repository and pick         the NewWithOld certificate (determined based on validity         periods; note that the subject and issuer fields must match);      2. Verify that this is correct using the old CA key (which the         verifier has stored locally);      3. If correct, check the signer's certificate using the new CA         key.   Case 3 will arise when the CA operator has issued the verifier's   certificate, then changed key and then issued the signer's   certificate, so it is also quite a typical case.Adams & Farrell               Expires May 2003                   [Page 20]2.4.2.4 Failure of verification in case 6.   In this case the CA has issued the verifier's PSE containing the new   key without updating the repository attributes. This means that the   verifier has no means to get a trustworthy version of the CA's old   key and so verification fails.   Note that the failure is the CA operator's fault.2.4.2.5 Failure of verification in case 7.   In this case the CA has issued the signer's certificate protected   with the new key without updating the repository attributes. This   means that the verifier has no means to get a trustworthy version of   the CA's new key and so verification fails.   Note that the failure is again the CA operator's fault.2.4.3 Revocation - Change of CA key   As we saw above the verification of a certificate becomes more   complex once the CA is allowed to change its key. This is also true   for revocation checks as the CA may have signed the CRL using a newer   private key than the one that is within the user's PSE.   The analysis of the alternatives is as for certificate verification.3. Data Structures   This section contains descriptions of the data structures required   for PKI management messages. Section 4 describes constraints on their   values and the sequence of events for each of the various PKI   management operations. 3.1 Overall PKI Message   All of the messages used in this specification for the purposes of   PKI management use the following structure:     PKIMessage ::= SEQUENCE {         header           PKIHeader,         body             PKIBody,         protection   [0] PKIProtection OPTIONAL,         extraCerts   [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL     }     PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessageAdams & Farrell               Expires May 2003                   [Page 21]   The PKIHeader contains information which is common to many PKI   messages.   The PKIBody contains message-specific information.   The PKIProtection, when used, contains bits that protect the PKI   message.   The extraCerts field can contain certificates that may be useful to   the recipient. For example, this can be used by a CA or RA to present   an end entity with certificates that it needs to verify its own new   certificate (if, for example, the CA that issued the end entity's   certificate is not a root CA for the end entity).  Note that this   field does not necessarily contain a certification path - the   recipient may have to sort, select from, or otherwise process the   extra certificates in order to use them.3.1.1 PKI Message Header   All PKI messages require some header information for addressing and   transaction identification. Some of this information will also be   present in a transport-specific envelope; however, if the PKI message   is protected then this information is also protected (i.e., we make   no assumption about secure transport).   The following data structure is used to contain this information:     PKIHeader ::= SEQUENCE {         pvno                INTEGER     { cmp1999(1), cmp2000(2) },         sender              GeneralName,         -- identifies the sender         recipient           GeneralName,         -- identifies the intended recipient         messageTime     [0] GeneralizedTime         OPTIONAL,         -- time of production of this message (used when sender         -- believes that the transport will be "suitable"; i.e.,         -- that the time will still be meaningful upon receipt)         protectionAlg   [1] AlgorithmIdentifier     OPTIONAL,         -- algorithm used for calculation of protection bits