accordance with CA policy; a null subject DN cannot be used.  A   common practice could be to place the identification value as part of   the subject DN.)  When the client generates the Full PKI Request   message, it MUST use these two pieces of information as follows:   1. The client MUST include the specific subject DN that it received      along with the shared secret as the subject name in every      certificate request (PKCS#10 and/or CRMF) in the Full PKI Request.      The subject names in the requests MUST NOT be null.   2. The client MUST include the identityProof control attribute      (Section 5.2), derived from the shared secret, in the Full PKI      Request.   The server receiving this message MUST (a) validate the identityProof   control attribute and then, (b) check that the subject DN included in   each certificate request matches that associated with the shared   secret.  If either of these checks fails the certificate request MUST   be rejected.5.3.3  Renewal and Re-Key Messages   In a renewal or re-key message, the subject DN in (a) the certificate   referenced by the CMS SignerInfo object, and (b) all certificate   requests within the request message MUST match according to the   standard name match rules described in [PKIXCERT].5.4  Data Return Control Attribute   The data return control attribute allows clients to send arbitrary   data (usually some type of internal state information) to the server   and to have the data returned as part of the enrollment response   message.  Data placed in a data return statement is considered to be   opaque to the server.  The same control is used for both requests and   responses.  If the data return statement appears in an enrollment   message, the server MUST return it as part of the enrollment response   message.   In the event that the information in the data return statement needs   to be confidential, it is expected that the client would apply some   type of encryption to the contained data, but the details of this are   outside the scope of this specification.   An example of using this feature is for a client to place an   identifier marking the exact source of the private key material.   This might be the identifier of a hardware device containing the   private key.Myers, et al.               Standards Track                    [Page 23]RFC 2797        Certificate Management Messages over CMS      April 20005.5  Add Extensions Control Attribute   The Add Extensions control attribute is used by LRAs in order to   specify additional extensions that are to be placed on certificates.   This attribute uses the following ASN.1 definition:     AddExtensions ::= SEQUENCE {         pkiDataReference             BodyPartID         certReferences               SEQUENCE OF BodyPartID,         extensions                   SEQUENCE OF Extension     }      -- pkiDataReference field contains the body part id of the      embedded request message.      -- certReferences field is a list of references to one or more of      the payloads contained within a PKIData.  Each element of the      certReferences sequence MUST be equal to either the bodyPartID of      a TaggedCertificationRequest or the certReqId of the CertRequest      within a CertReqMsg.   By definition, the listed extensions are to      be applied to every element referenced in the certReferences      sequence.  If a request corresponding to bodyPartID cannot be      found, the error badRequest is returned referencing this control      attribute.      -- extensions field contains the sequence of extensions to be      applied to the referenced certificate requests.   Servers MUST be able to process all extensions defined in [PKIXCERT].   Servers are not required to be able to process every V3 X.509   extension transmitted using this protocol, nor are they required to   be able to process other, private extensions.  Servers are not   required to put all LRA-requested extensions into a certificate.   Servers are permitted to modify LRA-requested extensions.  Servers   MUST NOT alter an extension so as to reverse the meaning of a   client-requested extension If a certification request is denied due   to the inability to handle a requested extension and a response is   returned, the server MUST return a failInfo attribute with the value   of unsupportedExt.   If multiple Add Extensions statements exist in an enrollment message,   the exact behavior is left up to the certificate issuer policy.   However it is recommended that the following policy be used.  These   rules would be applied to individual extensions within an Add   Extensions control attribute (as opposed to an "all or nothing"   approach).Myers, et al.               Standards Track                    [Page 24]RFC 2797        Certificate Management Messages over CMS      April 2000   1. If the conflict is within a single PKIData object, the certificate      request would be rejected with an error of badRequest.   2. If the conflict is between different PKIData objects, the      outermost version of the extension would be used (allowing an LRA      to override the extension requested by the end-entyt).5.6  Transaction Management Control Attributes   Transactions are identified and tracked using a transaction   identifier.  If used, clients generate transaction identifiers and   retain their value until the server responds with a message that   completes the transaction.  Servers correspondingly include received   transaction identifiers in the response.   The transactionId attribute identifies a given transaction.  It is   used between client and server to manage the state of an operation.   Clients MAY include a transactionID attribute in request messages.   If the original request contains a transactionID attribute, all   subsequent request and response messages MUST include the same   transactionID attribute.  A server MUST use only transactionIds in   the outermost PKIdata object. TransactionIds on inner PKIdata objects   are for intermediate entities.   Replay protection can be supported through the use of sender and   recipient nonces. If nonces are used, in the first message of a   transaction, no recipientNonce is transmitted; a senderNonce is   instantiated by the message originator and retained for later   reference.  The recipient of a sender nonce reflects this value back   to the originator as a recipientNonce and includes it's own   senderNonce.  Upon receipt by the transaction originator of this   message, the originator compares the value of recipientNonce to its   retained value.  If the values match, the message can be accepted for   further security processing.  The received value for senderNonce is   also retained for inclusion in the next message associated with the   same transaction.   The senderNonce and recipientNonce attribute can be used to provide   application-level replay prevention. Clients MAY include a   senderNonce in the initial request message.  Originating messages   include only a value for senderNonce. If a message includes a   senderNonce, the response MUST include the transmitted value of the   previously received senderNonce as recipientNonce and include new   value for senderNonce. A server MUST use only nonces in the outermost   PKIdata object. Nonces on inner PKIdata objects are for intermediate   entities.Myers, et al.               Standards Track                    [Page 25]RFC 2797        Certificate Management Messages over CMS      April 20005.7  Proof-of-possession (POP) for encryption-only keys   Everything described in this section is optional to implement, for   both servers and clients. Servers MAY require this POP method be used   only if another POP method is unavailable. Servers SHOULD reject all   requests contained within a PKIData if any required POP is missing   for any element within the PKIData.   Many servers require proof that an entity requesting a certificate   for a public key actually possesses the corresponding private   component of the key pair.  For keys that can be used as signature   keys, signing the certification request with the private key serves   as a POP on that key pair.  With keys that can only be used for   encryption operations, POP MUST be performed by forcing the client to   decrypt a value.  See Section 5 of [CRMF] for a detailed discussion   of POP.   By necessity, POP for encryption-only keys cannot be done in one   round-trip, since there are four distinct phases:   1. Client tells the server about the public component of a new      encryption key pair.   2. Server sends the client a POP challenge, encrypted with the      presented public encryption key, which the client must decrypt.   3. Client decrypts the POP challenge and sends it back to the server.   4. Server validates the decrypted POP challenge and continues      processing the certificate request.   CMC defines two different attributes.  The first deals with the   encrypted challenge sent from the server to the user in step 2.  The   second deals with the decrypted challenge sent from the client to the   server in step 3.   The encryptedPOP attribute is used to send the encrypted challenge   from the server to the client.  As such, it is encoded as a tagged   attribute within the controlSequence of a ResponseBody.  (Note that   we assume that the message sent in Step 1 above is an enrollment   request and that the response in step 2 is a Full Enrollment Response   including a failureInfo specifying that a POP is explicitly required,   and providing the POP challenge in the encryptedPOP attribute.)      EncryptedPOP ::= SEQUENCE {           request        TaggedRequest,           cms            contentInfo,           thePOPAlgID    AlgorithmIdentifier,           witnessAlgID   AlgorithmIdentifier,           witness        OCTET STRINGMyers, et al.               Standards Track                    [Page 26]RFC 2797        Certificate Management Messages over CMS      April 2000      }      DecryptedPOP ::= SEQUENCE {           bodyPartID     BodyPartID,           thePOPAlgID    AlgorithmIdentifier,           thePOP         OCTET STRING      }   The encrypted POP algorithm works as follows:   1. The server generates a random value y and associates it with the      request.   2. The server returns the encrypted pop with the following fields      set:      a. request is the certificate request in the original request         message (it is included here so the client need not key a copy         of the request),      b. cms is an EnvelopedData object, the content type being id-data         and the content being the value y.  If the certificate request         contains a subject key identifier (SKI) extension, then the         recipient identifier SHOULD be the SKI.  If the         issuerAndSerialNumber form is used, the IsserName MUST be         encoded as NULL and the SerialNumber as the bodyPartId of the         certificate request,      c. thePOPAlgID contains the algorithm to be used in computing the         return POP value,      d. witnessAlgID contains the hash algorithm used on y to create         the field witness,      e. witness contains the hashed value of y.   3. The client decrypts the cms field to obtain the value y.  The      client computes H(y) using the witnessAlgID and compares to the      value of witness.  If the values do not compare or the decryption      is not successful, the client MUST abort the enrollment process.      The client aborts the process by sending a request message      containing a CMCStatusInfo control attribute with failInfo value      of popFailed.   4. The client creates the decryptedPOP as part of a new PKIData      message.  The fields in the decryptedPOP are:      a. bodyPartID refers to the certificate request in the new         enrollment message,      b. thePOPAlgID is copied from the encryptedPOP,      c. thePOP contains the possession proof.  This value is computed         by thePOPAlgID using the value y and request referenced in         (4a).   5. The server then re-computes the value of thePOP from its cached      value of y and the request and compares to the value of thePOP.      If the values do not match, the server MUST NOT issue the      certificate.  The server MAY re-issue a new challenge or MAY failMyers, et al.               Standards Track                    [Page 27]RFC 2797        Certificate Management Messages over CMS      April 2000      the request altogether.   When defining the algorithms for thePOPAlgID and witnessAlgID care   must be taken to ensure that the result of witnessAlgID is not a   useful value to shortcut the computation with thePOPAlgID.  Clients   MUST implement SHA-1 for witnessAlgID.  Clients MUST implement HMAC-   SHA1 for thePOPAlgID.  The value of y is used as the secret value in   the HMAC algorithm and the request referenced in (4a) is used as the   data.  If y is greater than 64 bytes, only the first 64 bytes of y   are used as the secret.   One potential problem with the algorithm above is the amount of state   that a CA needs to keep in order to verify the returned POP value.   This describes one of many possible ways of addressing the problem by   reducing the amount of state kept on the CA to a single (or small   set) of values.   1. Server generates random seed x, constant across all requests. (The      value of x would normally be altered on a regular basis and kept      for a short time afterwards.)   2. For certificate request R, server computes y = F(x,R).  F can be,      for example, HMAC-SHA1(x,R).  All that's important for      statelessness is that y be consistently computable with only known      state constant x and function F, other inputs coming from the cert      request structure.  y should not be predictable based on knowled