protected  verifier     can directly  is the         has not   using OLD  must         verify the    situation of   updated the   public     access the   certificate   case 2 and     directory the   key        directory    without       will access    verifier can              in order     using the     the            verify the              to get the   directory     directory;     certificate              value of                   however, the   directly -              the OLD                    verification   this is thus              public key                 will FAIL      the same as                                                        case 4.Adams & Farrell             Standards Track                    [Page 17]RFC 2510          PKI Certificate Management Protocols        March 19992.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 directory. 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 directory and pick         the OldWithNew certificate (determined based on validity         periods);      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 directory and pick         the NewWithOld certificate (determined based on validity         periods);      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             Standards Track                    [Page 18]RFC 2510          PKI Certificate Management Protocols        March 19992.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 directory 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 directory 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. Section 5 describes how these may be   encapsulated in various transport mechanisms.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     }Adams & Farrell             Standards Track                    [Page 19]RFC 2510          PKI Certificate Management Protocols        March 1999   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     { ietf-version2 (1) },         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         senderKID       [2] KeyIdentifier           OPTIONAL,         recipKID        [3] KeyIdentifier           OPTIONAL,         -- to identify specific keys used for protection         transactionID   [4] OCTET STRING            OPTIONAL,         -- identifies the transaction; i.e., this will be the same in         -- corresponding request, response and confirmation messages         senderNonce     [5] OCTET STRING            OPTIONAL,         recipNonce      [6] OCTET STRING            OPTIONAL,         -- nonces used to provide replay protection, senderNonceAdams & Farrell             Standards Track                    [Page 20]RFC 2510          PKI Certificate Management Protocols        March 1999         -- is inserted by the creator of this message; recipNonce         -- is a nonce previously inserted in a related message by         -- the intended recipient of this message         freeText        [7] PKIFreeText             OPTIONAL,         -- this may be used to indicate context-specific instructions         -- (this field is intended for human consumption)         generalInfo     [8] SEQUENCE SIZE (1..MAX) OF                                InfoTypeAndValue     OPTIONAL         -- this may be used to convey context-specific information         -- (this field not primarily intended for human consumption)     }     PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String         -- text encoded as UTF-8 String (note:  each UTF8String SHOULD         -- include an RFC 1766 language tag to indicate the language         -- of the contained text)   The pvno field is fixed (at one) for this version of this   specification.   The sender field contains the name of the sender of the PKIMessage.   This name (in conjunction with senderKID, if supplied) should be   usable to verify the protection on the message.  If nothing about the   sender is known to the sending entity (e.g., in the init. req.   message, where the end entity may not know its own Distinguished Name   (DN), e-mail name, IP address, etc.), then the "sender" field MUST   contain a "NULL" value; that is, the SEQUENCE OF relative   distinguished names is of zero length. In such a case the senderKID   field MUST hold an identifier (i.e., a reference number) which   indicates to the receiver the appropriate shared secret information   to use to verify the message.   The recipient field contains the name of the recipient of the   PKIMessage. This name (in conjunction with recipKID, if supplied)   should be usable to verify the protection on the message.   The protectionAlg field specifies the algorithm used to protect the   message. If no protection bits are supplied (note that PKIProtection   is OPTIONAL) then this field MUST be omitted; if protection bits are   supplied then this field MUST be supplied.   senderKID and recipKID are usable to indicate which keys have been   used to protect the message (recipKID will normally only be required   where protection of the message uses Diffie-Hellman (DH) keys).Adams & Farrell             Standards Track                    [Page 21]RFC 2510          PKI Certificate Management Protocols        March 1999   The transactionID field within the message header MAY be used to   allow the recipient of a response message to correlate this with a   previously issued request. For example, in the case of an RA there   may be many requests "outstanding" at a given moment.   The senderNonce and recipNonce fields protect the PKIMessage against   replay attacks.   The messageTime field contains the time at which the sender created   the message. This may be useful to allow end entities to correct   their local time to be consistent with the time on a central system.   The freeText field may be used to send a human-readable message to   the recipient (in any number of languages).  The first language used   in this sequence indicates the desired language for replies.   The generalInfo field may be used to send machine-processable   additional data to the recipient.3.1.2 PKI Message Body     PKIBody ::= CHOICE {       -- message-specific body elements         ir      [0]  CertReqMessages,        --Initialization Request         ip      [1]  CertRepMessage,         --Initialization Response         cr      [2]  CertReqMessages,        --Certification Request         cp      [3]  CertRepMessage,         --Certification Response         p10cr   [4]  CertificationRequest,   --PKCS #10 Cert. Req.           -- the PKCS #10 certification request (see [PKCS10])         popdecc [5]  POPODecKeyChallContent, --pop Challenge         popdecr [6]  POPODecKeyRespContent,  --pop Response         kur     [7]  CertReqMessages,        --Key Update Request         kup     [8]  CertRepMessage,         --Key Update Response         krr     [9]  CertReqMessages,        --Key Recovery Request         krp     [10] KeyRecRepContent,       --Key Recovery Response         rr      [11] RevReqContent,          --Revocation Request         rp      [12] RevRepContent,          --Revocation Response         ccr     [13] CertReqMessages,        --Cross-Cert. Request         ccp     [14] CertRepMessage,         --Cross-Cert. Response         ckuann  [15] CAKeyUpdAnnContent,     --CA Key Update Ann.         cann    [16] CertAnnContent,         --Certificate Ann.         rann    [17] RevAnnContent,          --Revocation Ann.         crlann  [18] CRLAnnContent,          --CRL Announcement         conf    [19] PKIConfirmContent,      --Confirmation         nested  [20] NestedMessageContent,   --Nested Message         genm    [21] GenMsgContent,          --General Message         genp    [22] GenRepContent,          --General Response         error   [23] ErrorMsgContent         --Error Message     }Adams & Farrell             Standards Track                    [Page 22]RFC 2510          PKI Certificate Management Protocols        March 1999   The specific types are described in Section 3.3 below.3.1.3 PKI Message Protection   Some PKI messages will be protected for integrity. (Note that if an   asymmetric algorithm is used to protect a message and the relevant   public component has been certified already, then the origin of   message can also be authenticated.  On the other hand, if the public   component is uncertified then the message origin cannot be   automatically authenticated, but may be authenticated via out-of-band