The CMC status info control is used in full PKI Response messages to   return information on a client request.  Servers MAY emit multiple   CMC status info controls referring to a single body part. Clients   MUST be able to deal with multiple CMC status info controls in a   response message. This statement uses the following ASN.1 definition:      CMCStatusInfo ::= SEQUENCE {           cMCStatus           CMCStatus,           bodyList            SEQUENCE SIZE (1..MAX) OF BodyPartID,           statusString        UTF8String OPTIONAL,           otherInfo           CHOICE {             failInfo            CMCFailInfo,             pendInfo            PendInfo } OPTIONAL      }      PendInfo ::= SEQUENCE {           pendToken           OCTET STRING,           pendTime            GeneralizedTime      }Myers, et al.               Standards Track                    [Page 17]RFC 2797        Certificate Management Messages over CMS      April 2000      -- cMCStatus is described in section 5.1.1      -- bodyList contains the list of body parts in the request message      to which this status information applies.  If an error is being      returned for a simple enrollment message, body list will contain a      single integer of value '1'.      -- statusString contains a string with additional description      information.  This string is human readable.      -- failInfo is described in section 5.1.2. It provides a detailed      error on what the failure was.  This choice is present only if      cMCStatus is failed.      -- pendToken is the token to be used in the queryPending control      attribute.      -- pendTime contains the suggested time the server wants to be      queried about the status of the request.   If the cMCStatus field is success, the CMC Status Info Control MAY be   omitted unless it is only item in the response message.  If no status   exists for a certificate request or other item requiring processing,   then the value of success is to be assumed.5.1.1   CMCStatus values   CMCStatus is a field in the CMCStatusInfo structure.  This field   contains a code representing the success or failure of a specific   operation.  CMCStatus has the ASN.1 structure of:      CMCStatus ::= INTEGER {           success                (0),           -- request was granted           -- reserved            (1),           -- not used, defined where the original structure was defined           failed                 (2),           -- you don't get what you want, more information elsewhere in      the message           pending                (3),           -- the request body part has not yet been processed,           -- requester is responsible to poll back on this           -- pending may only be return for certificate request      operations.           noSupport              (4),           -- the requested operation is not supported           confirmRequired        (5)Myers, et al.               Standards Track                    [Page 18]RFC 2797        Certificate Management Messages over CMS      April 2000           -- conformation using the idConfirmCertAcceptance control is      required           -- before use of certificate      }5.1.2   CMCFailInfo   CMCFailInfo conveys information relevant to the interpretation of a   failure condition. The CMCFailInfo has the following ASN.1 structure:      CMCFailInfo ::= INTEGER {           badAlg            (0)           -- Unrecognized or unsupported algorithm           badMessageCheck   (1)           -- integrity check failed           badRequest        (2)           -- transaction not permitted or supported           badTime           (3)           -- Message time field was not sufficiently close to the system      time           badCertId         (4)           -- No certificate could be identified matching the provided      criteria           unsuportedExt     (5)           -- A requested X.509 extension is not supported by the      recipient CA.           mustArchiveKeys   (6)           -- Private key material must be supplied           badIdentity       (7)           -- Identification Attribute failed to verify           popRequired       (8)           -- Server requires a POP proof before issuing certificate           popFailed         (9)           -- POP processing failed           noKeyReuse        (10)           -- Server policy does not allow key re-use           internalCAError   (11)           tryLater          (12)      }   Additional failure reasons MAY be defined for closed environments   with a need.Myers, et al.               Standards Track                    [Page 19]RFC 2797        Certificate Management Messages over CMS      April 20005.2  Identification and IdentityProof Control Attributes   Some CAs and LRAs require that a proof of identity be included in a   certification request.  Many different ways of doing this exist with   different degrees of security and reliability.  Most people are   familiar with the request of a bank to provide your mother's maiden   name as a form of identity proof.   CMC provides one method of proving the client's identity based on a   shared secret between the certificate requestor and the verifying   authority.  If clients support full request messages, clients MUST   implement this method of identity proof.  Servers MUST provide this   method and MAY also have a bilateral method of similar strength   available.   The CMC method starts with an out-of-band transfer of a token (the   shared secret).  The distribution of this token is beyond the scope   of this document.  The client then uses this token for an identity   proof as follows:   1. The reqSequence field of the PKIData object (encoded exactly as it      appears in the request message including the sequence type and      length) is the value to be validated.   2. A SHA1 hash of the token is computed.   3. An HMAC-SHA1 value is then computed over the value produced in      Step 1, as described in [HMAC], using the hash of the token from      Step 2 as the shared secret value.   4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the      value of the identityProof attribute.   When the server verifies the identityProof attribute, it computes the   HMAC-SHA1 value in the same way and compares it to the identityProof   attribute contained in the enrollment request.   If a server fails the verification of an identityProof attribute and   the server returns a response message, the failInfo attribute MUST be   present in the response and MUST have a value of badIdentity.   Optionally, servers MAY require the inclusion of the unprotected   identification attribute with an identification attribute.  The   identification attribute is intended to contain either a text string   or a numeric quantity, such as a random number, which assists the   server in locating the shared secret needed to validate the contents   of the identityProof attribute.  Numeric values MUST be converted to   text string representations prior to encoding as UTF8-STRINGs in this   attribute.  If the identification control attribute is included inMyers, et al.               Standards Track                    [Page 20]RFC 2797        Certificate Management Messages over CMS      April 2000   the message, the derivation of the shared secret in step 2 is altered   so that the hash of the concatenation of the token and the identity   value are hashed rather than just the token.5.2.1  Hardware Shared Secret Token Generation   The shared secret between the end-entity and the identity verify is   sometimes transferred using a hardware device that generates a series   of tokens based on some shared secret value.  The user can therefore   prove their identity by transferring this token in plain text along   with a name string.  The above protocol can be used with a hardware   shared-secret token generation device by the following modifications:   1. The identification attribute MUST be included and MUST contain the      hardware-generated token.   2. The shared secret value used above is the same hardware-generated      token.   3. All certification requests MUST have a subject name and the      subject name MUST contain the fields required to identify the      holder of the hardware token device.5.3  Linking Identity and POP Information   In a PKI Full Request message identity information about the   creator/author of the message is carried in the signature of the CMS   SignedData object containing all of the certificate requests.   Proof-of-possession information for key pairs requesting   certification, however, is carried separately for each PKCS#10 or   CRMF message.  (For keys capable of generating a digital signature,   the POP is provided by the signature on the PKCS#10 or CRMF request.   For encryption-only keys the controls described in Section 5.7 below   are used.)  In order to prevent substitution-style attacks we must   guarantee that the same entity generated both the POP and proof-of-   identity information.   This section describes two mechanisms for linking identity and POP   information: witness values cryptographically derived from the   shared-secret (Section 5.3.1) and shared-secret/subject DN matching   (Section 5.3.2).  Clients and servers MUST support the witness value   technique.  Clients and servers MAY support shared-secret/subject DN   matching or other bilateral techniques of similar strength.  The idea   behind both mechanisms is to force the client to sign some data into   each certificate request that can be directly associated with the   shared-secret; this will defeat attempts to include certificate   requests from different entities in a single Full PKI Request   message.Myers, et al.               Standards Track                    [Page 21]RFC 2797        Certificate Management Messages over CMS      April 20005.3.1  Witness values derived from the shared-secret   The first technique for doing identity-POP linking works by forcing   the client to include a piece of information cryptographically-   derived from the shared-secret token as a signed extension within   each certificate request (PKCS#10 or CRMF) message.  This technique   is useful if null subject DNs are used (because, for example, the   server can generate the subject DN for the certificate based only on   the shared secret).  Processing begins when the client receives the   shared-secret token out-of-band from the server.  The client then   computes the following values:   1. The client generates a random byte-string, R, which SHOULD be at      least 512 bits in length.   2. A SHA1 hash of the token is computed.   3. An HMAC-SHA1 value is then computed over the random value produced      in Step 1, as described in [HMAC], using the hash of the token      from Step 2 as the shared secret.   4. The random value produced in Step 1 is encoded as the value of an      idPOPLinkRandom control attribute.  This control attribute MUST be      included in the Full PKI Request message.   5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value      of an idPOPLinkWitness extension to the certificate request.      a. For CRMF, idPOPLinkWitness is included in the controls section         of the CertRequest structure.      b. For PKCS#10, idPOPLinkWitness is included in the attributes         section of the CertificationRequest structure.   Upon receipt, servers MUST verify that each certificate request   contains a copy of the idPOPLinkWitness and that its value was   derived in the specified manner from the shared secret and the random   string included in the idPOPLinkRandom control attribute.5.3.2  Shared-secret/subject DN matching   The second technique for doing identity-POP linking is to link a   particular subject distinguished name (subject DN) to the shared-   secrets that are distributed out-of-band and to require that clients   using the shared-secret to prove identity include that exact subject   DN in every certificate request.  It is expected that many client-   server connections using shared-secret based proof-of-identity will   use this mechanism. (It is common not to omit the subject DN   information from the certificate request messages.)   When the shared secret is generated and transferred out-of-band to   initiate the registration process (Section 5.2), a particular subject   DN is also associated with the shared secret and communicated to the   client.  (The subject DN generated MUST be unique per entity inMyers, et al.               Standards Track                    [Page 22]RFC 2797        Certificate Management Messages over CMS      April 2000