Certificate Management over CMS (CMC)
obsoletes
- rfc-2797 — Certificate Management Messages over CMS
updated by
- rfc-6402 — Certificate Management over CMS (CMC) Updates
Extracted elements (31)
Identity and POP information are carried separately in a Full PKI Request (identity in the outer SignedData signature, POP in each cert request), creating a substitution attack risk where an attacker could bundle cert requests from different entities. The POP Link Witness mechanism cryptographically binds each cert request's POP to the shared-secret to close this gap.
The CMC Unsigned Data attribute (id-aa-cmc-unsignedData) was introduced because signed controls inside a client request cannot be removed by an RA or Key Archive Agent without breaking the RA's signature. By placing data in unsigned/unauthenticated attributes, each RA can move it to its own outer wrapper without invalidating inner signatures.
When encrypting a Full PKI Request, a second signature layer placed outside the EnvelopedData is recommended (Option 2) so that the recipient can authenticate the source even before decryption. Option 1 (EnvelopedData wrapping SignedData) and plain SignedData are also supported; servers MUST support all three options.
The CMC Status Info control (id-cmc-statusInfo, id-cmc 1) is retained for backward compatibility with RFC 2797. Servers MUST use the Extended CMC Status Info control but MAY additionally emit the older control. Clients MUST be able to deal with multiple CMC status info controls in a single PKI Response.
The PKIResponse ASN.1 type was named ResponseBody in RFC 2797 and has been renamed to PKIResponse for clarity; the old name is retained as a synonym (ReponseBody ::= PKIResponse) for backward compatibility.
As part of processing a PKI Request/Response, the signature(s) on SignedData MUST be verified. If the signature does not verify and the message contains anything other than a CMC Status Info control, a Full PKI Response with CMCFailInfo value of badMessageCheck and bodyPartID of 0 MUST be returned.
Clients and servers MUST support the POP Link Witness witness-value technique for linking identity and POP information. Clients and servers MAY additionally support shared-secret/subject DN matching or other bilateral techniques of similar strength.
Clients MUST be able to process both Simple PKI Responses and Full PKI Responses. Clients MUST NOT assume certificates in a response are in any particular order.
If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response. This control allows clients to pass opaque state information that is echoed back.
Implementations MUST be able to support shared-secret identity proof tokens at least 16 characters long. The shared-secret should be generated in a random manner; its distribution is out of scope.
Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension (for example, changing key usage from keyAgreement to digitalSignature). If a certification request is denied due to an unsupported extension, the server MUST return CMCFailInfo value unsupportedExt.
Servers MUST use the Extended CMC Status Info control (id-cmc-statusInfoV2). Clients MUST be able to process the Extended CMC Status Info control. The older CMC Status Info control is retained for backwards compatibility with RFC 2797.
The CRMF regInfo field MUST NOT be used in a CRMF certification request within CMC; equivalent functionality is provided by the CMC regInfo control (Section 6.12). When both CRMF and CMC controls provide equivalent functionality, the CMC control SHOULD be used and MUST override the CRMF control.
The final server MUST fail the processing of an entire PKIData if any included control is not recognized and is not already marked as processed by a Control Processed control. The PKI Response MUST include a CMCFailInfo of badRequest with the bodyList containing the bodyPartID of the unrecognized control(s).
The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included. It also cannot be used if the private key is not capable of producing some type of signature.
When a server processes a Full PKI Request, a PKI Response MUST be returned. The response is a Simple PKI Response only if enrollment was successful and only certificates are returned; otherwise a Full PKI Response is used.
When AuthenticatedData is used for a Full PKI Request, the Password Recipient Info option of RecipientInfo MUST be used, a randomly generated key MUST be used to compute the MAC, and the key derivation input MUST be a concatenation of the identifier (encoded as UTF8) and the shared-secret.
When using a hardware shared-secret token, the entire certification request MUST be shrouded (encrypted) to prevent an active eavesdropper from extracting the time-critical token and submitting a different request with the same token value.
CMC defines 30 control attributes under the id-cmc arc ({id-pkix 7}), including status controls (id-cmc 1, 25), identity proof (id-cmc 3, 34), transaction/nonce (id-cmc 5–7), encrypted/decrypted POP (id-cmc 9–10), revocation (id-cmc 17), batch processing (id-cmc 28–29), and trust anchor publication (id-cmc 26).
CMCFailInfo integer enumeration with 14 defined values (0–13): badAlg, badMessageCheck, badRequest, badTime, badCertId, unsupportedExt, mustArchiveKeys, badIdentity, popRequired, popFailed, noKeyReuse, internalCAError, tryLater, authDataFail. Additional failure reasons in closed environments MUST use codes 1000–1999.
CMCStatus integer enumeration: success(0), failed(2), pending(3), noSupport(4), confirmRequired(5), popRequired(6), partial(7). The pending and partial values require the client to poll back using the Query Pending control with the pendToken from PendInfo.
Identity Proof Version 2 control (id-cmc-identityProofV2, id-cmc 34): IdentityProofV2 SEQUENCE containing hashAlgID (AlgorithmIdentifier), macAlgID (AlgorithmIdentifier), and witness (OCTET STRING). The witness is a MAC over the PKIData reqSequence, keyed by a hash of the shared-secret.
PKIResponse content type (id-cct-PKIResponse, OID {id-pkix id-cct(12) 3}) is a SEQUENCE of controlSequence, cmsSequence, and otherMsgSequence. All certificates issued as part of the response are included in the certificates field of the immediately encapsulating SignedData.
POP Link Witness Version 2 control (id-cmc-popLinkWitnessV2, id-cmc 33): PopLinkWitnessV2 SEQUENCE containing keyGenAlgorithm (AlgorithmIdentifier), macAlgorithm (AlgorithmIdentifier), and witness (OCTET STRING computed as MAC over a random value R of at least 512 bits, keyed by the shared-secret).
Reuse of the shared-secret on certification request retries maintains consistent identity proof values, but can open the door for replay and other attacks. The protocol includes optional replay detection through nonces (SenderNonce and RecipientNonce controls, id-cmc 6–7) to mitigate this. The required identity proof tokens must be at least 16 characters with sufficient entropy.
CMC enrollment transaction states: initial request → success (certificate returned), failed (CMCFailInfo included), pending (client must poll using Query Pending control with pendToken), partial (some requests fulfilled, client polls for remainder), or confirmRequired (client must send Confirm Certificate Acceptance before using certificate).
BodyPartID is a 4-octet INTEGER in the range 0..4294967295 (bodyIdMax). Value 0 is reserved as reference to the current PKIData object. BodyPartIDs MUST be unique within a single PKIData or PKIResponse but may be duplicated across nesting layers.
CMCStatusInfoV2 is a SEQUENCE containing cMCStatus (CMCStatus integer), bodyList (SEQUENCE SIZE(1..MAX) OF BodyPartReference), optional statusString (UTF8String), and optional otherInfo (CHOICE of failInfo/pendInfo/extendedFailInfo). BodyPartReference is a CHOICE of bodyPartID or bodyPartPath.
CMCUnsignedData (id-aa-cmc-unsignedData, OID {id-aa 34}) is a SEQUENCE of bodyPartPath (BodyPartPath), identifier (OBJECT IDENTIFIER), and content (ANY DEFINED BY identifier). There MUST be at most one CMCUnsignedData attribute per SignerInfo or AuthenticatedData, and if present it MUST appear with the same value(s) in all SignerInfo and AuthenticatedData items.
PKIData content type (id-cct-PKIData, OID {id-pkix id-cct(12) 2}) is a SEQUENCE of four fields: controlSequence (TaggedAttributes), reqSequence (TaggedRequests), cmsSequence (TaggedContentInfos), and otherMsgSequence (OtherMsgs), each of SIZE(0..MAX).
TaggedAttribute (control syntax) is a SEQUENCE of bodyPartID (BodyPartID integer), attrType (OBJECT IDENTIFIER), and attrValues (SET OF AttributeValue ANY). The bodyPartID MUST be unique within a single PKIData or PKIResponse.