Certificate Management Messages over CMS
obsoleted by
- rfc-5272 — Certificate Management over CMS (CMC)
Extracted elements (30)
No special services are provided for renewal (same key, new certificate) or re-keying (new keys, new certificate). Instead, renewal and re-key messages are structurally identical to initial enrollment messages, with identity proof supplied by existing certificates from the CA, simplifying the protocol surface.
The protocol is designed so that all key generation can occur on the client and all operations can be completed in a single round trip where possible. The multi-round trip case (e.g., POP for encryption-only keys, pending certificate issuance) is minimized rather than eliminated, as the four-phase POP challenge-response is unavoidable for keys that cannot sign.
CMC clients and servers MUST support DSA for message signatures and Diffie-Hellman for message encryption key protection (D-H/3DES). RSA signatures and RSA key transport are SHOULD-level requirements. A minimally compliant server MUST accept Full PKI Requests (with both CRMF and PKCS#10 bodies), Simple Enrollment Requests, and MUST be able to return a Full PKI Response.
CMC compliant implementations MUST support section 5 of [DH-POP] (the Diffie-Hellman POP signature) and MAY support section 4 of [DH-POP] (the DH MAC signature) for producing the required signature value on DH certification requests.
Clients MUST NOT implicitly trust a self-signed certificate received in an enrollment response merely due to its presence in the certificate bag. If clients receive a new self-signed certificate, clients SHOULD provide a mechanism to enable the user to explicitly trust it.
CMC provides a shared-secret identity proof using HMAC-SHA1: the client computes HMAC-SHA1 over the reqSequence field using SHA1(token) as the shared secret and encodes the 160-bit result as the identityProof attribute. If verification fails and a response is returned, the failInfo attribute MUST have a value of badIdentity.
For CRMF request bodies within a Full Enrollment Request, each CRMF message MUST include both subject and publicKey fields; the CMC control MUST override any CRMF control; regInfo field MUST NOT be used; and POPOSigningKeyInput MUST NOT be used when subject and publicKeyValues are present.
If CMCStatusInfo on a certificate request returns confirmRequired, the client MUST return a Confirm Certificate Acceptance (CMCCertId, id-cmc 24) prior to any usage of the certificate. Servers MUST return a full enrollment response for a confirm certificate acceptance control.
If the server cannot match the decrypted POP challenge, the server MUST NOT issue the certificate. The client MUST abort the enrollment process (sending popFailed) if the decryption is unsuccessful or H(y) does not match the witness value.
LRAs MUST NOT alter any certificate request body (PKCS#10 or CRMF), as any alteration would invalidate the signature on the request and thus the POP for the private key.
Servers MUST be able to understand and process PKCS10 request bodies; clients MUST produce a PKCS10 request body for the Simple Enrollment Request. The subject name MAY be NULL but MUST be present; servers MUST NOT alter extensions so as to invalidate the original intent of a client-requested extension.
Servers MUST fail the processing of an entire PKIData message if any included control attribute is not recognized. The response MUST be the error badRequest and bodyList MUST contain the bodyPartID of the invalid or unrecognized control attribute.
Servers MUST implement EnvelopedData according to [CMS] for confidentiality. There is a noted ambiguity in the PKCS7 specification regarding encrypting content types other than id-data that has led to non-interoperability.
Servers MUST support both the Simple Enrollment Request and the Full Enrollment Request. Clients SHOULD use the Full Enrollment Request message when enrolling. An enrollment response MUST be returned to all Full Enrollment Requests.
To prevent substitution attacks, clients and servers MUST support the witness value technique for identity-POP linking: the client generates a random R (SHOULD be at least 512 bits), computes HMAC-SHA1(SHA1(token), R) as the idPOPLinkWitness extension in each certificate request, and includes R as the idPOPLinkRandom control attribute. Servers MUST verify each certificate request contains a correct idPOPLinkWitness.
Transaction management uses a transactionId (id-cmc 5) generated by the client. If the original request contains a transactionID, all subsequent request and response messages MUST include the same transactionID. Replay protection uses senderNonce (id-cmc 6) and recipientNonce (id-cmc 7); if a message includes a senderNonce, the response MUST reflect it as recipientNonce and include a new senderNonce.
Body Part Identifiers are 4-octet integers that uniquely identify each element within a single PKIData or PKIResponse object. The value zero is reserved to designate the current PKIData object; duplicate IDs within a single object MUST result in a badRequest error.
CMCFailInfo enumerates specific failure reasons including: badAlg (0), badMessageCheck (1), badRequest (2), badTime (3), badCertId (4), unsuportedExt (5), mustArchiveKeys (6), badIdentity (7), popRequired (8), popFailed (9), noKeyReuse (10), internalCAError (11), tryLater (12).
CMCStatusInfo (id-cmc 1) is the control attribute used in Full PKI Responses to convey success, failure, pending, noSupport, or confirmRequired status. It includes a bodyList referencing the affected body parts, an optional statusString, and an otherInfo choice of CMCFailInfo or PendInfo (with pendToken and pendTime).
EncryptedPOP (id-cmc 9) and DecryptedPOP (id-cmc 10) implement the four-phase POP challenge-response for encryption-only keys. The server encrypts a random value y with the public key (cms field), provides witnessAlgID/witness (hash of y), and thePOPAlgID. The client decrypts y, verifies the hash, and returns thePOP = HMAC-SHA1(y, request). Clients MUST implement SHA-1 for witnessAlgID and HMAC-SHA1 for thePOPAlgID.
LraPOPWitness (id-cmc 11) allows an LRA to inform the CA that it has performed out-of-band POP verification on behalf of listed certificate requests. If the CA does not allow LRA POP verification, it returns POPFAILURE and MUST NOT start its own challenge-response to re-verify POP.
PKIData is the ASN.1 content type (id-cct-PKIData, OID id-cct 2) used as the body of the Full PKI Request message. It is a SEQUENCE containing controlSequence, reqSequence, cmsSequence, and otherMsgSequence, each holding zero or more tagged items.
QueryPending (id-cmc 21) allows a client to poll a server about a pending certificate request using a token originally returned by the server in CMCStatusInfo's pendToken field. If the server returns a pending state, the same pendToken MUST NOT change during the request lifecycle.
ResponseBody is the ASN.1 content type (id-cct-PKIResponse, OID id-cct 3) used as the body of the Full PKI Response message. It is a SEQUENCE containing controlSequence, cmsSequence, and otherMsgSequence.
RevRequest (id-cmc 17) carries a certificate revocation request, including issuerName, serialNumber, reason (CRLReason), optional invalidityDate, optional sharedSecret (for key-loss scenarios), and optional comment. Clients MUST provide digitally signed revocation capability; servers MUST accept both signed and shared-secret-based revocation requests.
The id-alg-noSignature mechanism (OID id-pkix id-alg 2) provides a signature placeholder for encryption-only keys that cannot produce a signature. The NoSignatureValue is an OCTET STRING containing a hash of the certification request; there is no security associated with this type, so if POP is required the encryptedPOP/decryptedPOP mechanism MUST be used.
CMC implementations must validate cryptographic parameters before issuing certificates to prevent weak parameters and must be aware of the small subgroup attack (described in [X942]) when performing parameter validations on Diffie-Hellman keys.
Replay attacks may be detectable without nonces only when the CA maintains significant state information. Developers of state-constrained PKI clients are strongly encouraged to incorporate the senderNonce and recipientNonce attributes. The choice of whether to use them depends on careful consideration of the operational environment.
Under no circumstances should a signing key be archived, as doing so allows the archiving entity to potentially use the key for forging signatures. Prior to archiving any key, users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material.
MIME transport encodes Simple PKI Requests as application/pkcs10 with file extension .p10; Full PKI Requests as application/pkcs7-mime with smime-type CMC-request and extension .p7m; Simple PKI Responses as application/pkcs7-mime with smime-type certs-only and extension .p7c; Full PKI Responses as application/pkcs7-mime with smime-type CMC-response and extension .p7m.