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               Expires May 2003                   [Page 22]         -- 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 [RFC2279] (note:  each UTF8String          -- MAY include an RFC 1766/RFC 3066 language tag to indicate the          -- language of the contained text -- see [RFC2482] for details)   The pvno field is fixed (at 2) 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   sufficient to indicate the key to use 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).   These fields MUST be used if required to uniquely identify a key   (e.g., if more than one key is associated with a given sender name)   and SHOULD be omitted otherwise.Adams & Farrell               Expires May 2003                   [Page 23]   The transactionID field within the message header is to be used to   allow the recipient of a message to correlate this with an ongoing   transaction. This is needed for all transactions that consist of   more than just a single request/response pair. For transactions that   consist of a single request/response pair the rules are as follows.    A client MAY populate the transactionID field of the request. If a   server receives such a request which has the transactionID field set,   then it MUST set the transactionID field of the response to the same   value; if a server receives such request with a missing transactionID   field then it MAY set transactionID field of the response.   For transactions that consist of more than just a single   request/response pair the rules are as follows.  Clients SHOULD    generate a transactionID for the first request. If a server receives    such a request which has the transactionID field set, then it MUST set    the transactionID field of the response to the same value; if a server   receives such request with a missing transactionID field then it MUST   populate transactionID field of the response with a server-generated   ID. Subsequent requests and responses MUST all set the transactionID   field to the thus established value. In all cases where a   transactionID is being used, a given client MUST NOT have more than   one transaction with the same transactionID in progress at any time   (to a given server). Servers are free to require uniqueness of the   transactionID or not, as long as they are able to correctly associate   messages with the corresponding transaction. Typically this means   that a server will require the {client, transactionID} tuple to be   unique, or even the transactionID alone to be unique if it cannot   distinguish clients based on transport level information. A server   receiving the first message of a transaction (which requires more than   a single request/response pair) that contains a transactionID that   does not allow it to meet the above constraints (typically because   the transactionID is already in use) MUST send back an   ErrorMsgContent with a PKIFailureInfo of transactionIdInUse. It is   RECOMMENDED that the clients fill the transactionID field with 128 bits    of (pseudo-) random data for the start of a transaction to reduce the    probability of having the transactionID in use at the server.   The senderNonce and recipNonce fields protect the PKIMessage against   replay attacks.  The senderNonce will typically be 128 bits of    (pseudo-) random data generated by the sender, whereas the recipNonce    is copied from the senderNonce of the previous message in the    transaction.   The messageTime field contains the time at which the sender created   the message. This may be useful to allow end entities to correct/check   their local time for consistency 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.  The following generalInfo extensions   are defined and MAY be supported.Adams & Farrell               Expires May 2003                   [Page 24]3.1.1.1 ImplicitConfirm   This is used by the EE to inform the CA that it does not wish to send   a certificate confirmation for issued certificates.      implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}      ImplicitConfirmValue ::= NULL   If the CA grants the request to the EE, it MUST put the same extension   in the PKIHeader of the response.  If the EE does not find the    extension in the response, it MUST send the certificate confirmation.3.1.1.2 ConfirmWaitTime   This is used by the CA to inform the EE how long it intends to wait for   the certificate confirmation before revoking the certificate and    deleting the transaction.      confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}      ConfirmWaitTimeValue ::= GeneralizedTime -- time CA will wait until   3.1.2 PKI Message Body     PKIBody ::= CHOICE {  -- message-specific body elements & Section ref       ir      [0]   CertReqMessages,       --Initialization Req  (3.3.1)       ip      [1]   CertRepMessage,        --Initialization Resp (3.3.2)       cr      [2]   CertReqMessages,       --Certification Req   (3.3.3)       cp      [3]   CertRepMessage,        --Certification Resp  (3.3.4)       p10cr   [4]   CertificationRequest,  --PKCS #10 Cert. Req. [PKCS10]         -- the PKCS #10 certification request (see [PKCS10])       popdecc [5]   POPODecKeyChallContent --pop Challenge       (3.2.8)       popdecr [6]   POPODecKeyRespContent, --pop Response        (3.2.8)       kur     [7]   CertReqMessages,       --Key Update Request  (3.3.5)       kup     [8]   CertRepMessage,        --Key Update Response (3.3.6)       krr     [9]   CertReqMessages,       --Key Recovery Req    (3.3.7)       krp     [10]  KeyRecRepContent,      --Key Recovery Resp   (3.3.8)       rr      [11]  RevReqContent,         --Revocation Request  (3.3.9)       rp      [12]  RevRepContent,         --Revocation Response (3.3.10)       ccr     [13]  CertReqMessages,       --Cross-Cert. Request (3.3.11)       ccp     [14]  CertRepMessage,        --Cross-Cert. Resp    (3.3.12)       ckuann  [15]  CAKeyUpdAnnContent,    --CA Key Update Ann.  (3.3.13)       cann    [16]  CertAnnContent,        --Certificate Ann.    (3.3.14)       rann    [17]  RevAnnContent,         --Revocation Ann.     (3.3.15)       crlann  [18]  CRLAnnContent,         --CRL Announcement    (3.3.16)       pkiconf [19]  PKIConfirmContent,     --Confirmation        (3.3.17)       nested  [20]  NestedMessageContent,  --Nested Message      (3.1.3)       genm    [21]  GenMsgContent,         --General Message     (3.3.19)       genp    [22]  GenRepContent,         --General Response    (3.3.20)       error   [23]  ErrorMsgContent,       --Error Message       (3.3.21)       certConf [24] CertConfirmContent,    --Certificate confirm (3.3.18)       pollReq [25]  PollReqContent,        --Polling request     (3.3.22)       pollRep [26]  PollRepContent         --Polling response    (3.3.22)       }Adams & Farrell               Expires May 2003                   [Page 25]   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 the   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   means.)   When protection is applied the following structure is used:     PKIProtection ::= BIT STRING   The input to the calculation of PKIProtection is the DER encoding of   the following data structure:     ProtectedPart ::= SEQUENCE {         header    PKIHeader,         body      PKIBody     }   There MAY be cases in which the PKIProtection BIT STRING is   deliberately not used to protect a message (i.e., this OPTIONAL field   is omitted) because other protection, external to PKIX, will instead   be applied. Such a choice is explicitly allowed in this   specification.  Examples of such external protection include PKCS #7   [PKCS7] and Security Multiparts [RFC1847] encapsulation of the   PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the   relevant PKIHeader information is securely carried in the external   mechanism).  It is noted, however, that many   such external mechanisms require that the end entity already   possesses a public-key certificate, and/or a unique Distinguished   Name, and/or other such infrastructure-related information. Thus,   they may not be appropriate for initial registration, key-recovery,   or any other process with "boot-strapping" characteristics.  For   those cases it may be necessary that the PKIProtection parameter be   used.  In the future, if/when external mechanisms are modified to   accommodate boot-strapping scenarios, the use of PKIProtection may   become rare or non-existent.   Depending on the circumstances the PKIProtection bits may contain a   Message Authentication Code (MAC) or signature. Only the following   cases can occur:Adams & Farrell               Expires May 2003                   [Page 26]   - shared secret information   In this case the sender and recipient share secret information   (established via out-of-band means or from a previous PKI management   operation).  PKIProtection will contain a MAC value and the   protectionAlg will be the following (see also Appendix B2):     id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}     PBMParameter ::= SEQUENCE {         salt                OCTET STRING,         owf                 AlgorithmIdentifier,         -- AlgId for a One-Way Function (SHA-1 recommended)         iterationCount      INTEGER,         -- number of times the OWF is applied         mac                 AlgorithmIdentifier         -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],     }   -- or HMAC [RFC2104, RFC2202])   In the above protectionAlg the salt value is appended to the shared   secret input. The OWF is then applied iterationCount times, where the   salted secret is the input to the first iteration and, for each   successive iteration, the input is set to be the output of the   previous iteration. The output of the final iteration (called   "BASEKEY" for ease of reference, with a size of "H") is what is used   to form the symmetric key. If the MAC algorithm requires a K-bit key   and K <= H, then the most significant K bits of BASEKEY are used. If   K > H, then all of BASEKEY is used for the most significant H bits of   the key, OWF("1" || BASEKEY) is used for the next most significant H   bits of the key, OWF("2" || BASEKEY) is used for the next most   significant H bits of the key, and so on, until all K bits have been   derived. [Here "N" is the ASCII byte encoding the number N and "||"   represents concatenation.]   Note:  it is RECOMMENDED that the fields of PBMParameter remain    constant throughout the messages of a single transaction (e.g.,    ir/ip/certConf/pkiConf) in order to reduce the overhead associated   with PasswordBasedMac computation).   - DH key pairs   Where the sender and receiver possess Diffie-Hellman certificates   with compatible DH parameters, then in order to protect the message   the end entity must generate a symmetric key based on its private DH   key value and the DH public key of the recipient of the PKI message.   PKIProtection will contain a MAC value keyed with this derived   symmetric key and the protectionAlg will be the following:Adams & Farrell               Expires May 2003                   [Page 27]     id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}     DHBMParameter ::= SEQUENCE {         owf                 AlgorithmIdentifier,         -- AlgId for a One-Way Function (SHA-1 r