Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
obsoleted by
- rfc-9810 — Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
obsoletes
- rfc-2510 — Internet X.509 Public Key Infrastructure Certificate Management Protocols
updated by
Extracted elements (28)
CMP is designed to minimize use of confidentiality in PKI management protocols to ease acceptance in regulatory environments where strong confidentiality might be problematic, while still supporting multiple industry-standard cryptographic algorithms.
The indirect POP method for encryption keys (returning an encrypted certificate so the EE proves possession by computing CertHash) is explicitly encouraged because it fits within the standard {request, response, confirmation} triple without extra round trips, unlike the challenge-response protocol which adds multiple messages.
The RA is defined as an OPTIONAL component; when absent, the CA performs RA functions so that end entities use the same protocol regardless of whether they communicate with an RA or directly with the CA. No special RA certification operation is defined, keeping the protocol uniform.
The root CA key update scheme does not use X.509 v3 extensions so that it works even for version 1 certificates; the four cross-signed certificate values (OldWithOld, OldWithNew, NewWithOld, NewWithNew) allow entities with either old or new CA public key to bridge the transition without protocol changes.
CMP defines two protocol version numbers: cmp1999 (pvno=1) for RFC 2510 implementations and cmp2000 (pvno=2) for this specification. Section 7 specifies handling rules for clients talking to RFC 2510 servers and for servers receiving cmp1999 PKIMessages to ensure backward compatibility.
An OOBCert used to distribute a root CA public key out-of-band MUST be self-signed (signature verifiable from SubjectPublicKeyInfo), and the subject and issuer fields MUST be identical. If subject is NULL, both subjectAltNames and issuerAltNames extensions MUST be present with equal values.
CAs/RAs MUST enforce Proof-of-Possession by some means. Without POP verification, the binding between an end entity and its private key remains unverified, making certificates less meaningful in the Internet PKI.
Conforming CA equipment, RA equipment, and EE equipment MUST support the Basic Authenticated Scheme, which requires end-entity-initiated authentication, key generation at the EE, and an explicit certificate confirmation message.
For multi-message transactions, all requests and responses MUST carry the same transactionID. A client MUST NOT have more than one transaction with the same transactionID in progress at any time to a given server. A server that cannot accommodate a new transactionID MUST return ErrorMsgContent with PKIFailureInfo of transactionIdInUse. It is RECOMMENDED that clients use 128 bits of pseudo-random data as the initial transactionID.
If the CA grants an ImplicitConfirm request, it MUST include the implicitConfirm extension (OID {id-it 13}, value NULL) in the PKIHeader of the response. If the EE does not find the extension in the response, it MUST send a certificate confirmation (certConf) message.
If the sender is unknown at message creation time (e.g., in an initial request where the EE does not yet know its DN), the sender field MUST contain a NULL value (zero-length SEQUENCE OF RDNs) and senderKID MUST hold a reference value identifying the shared secret for message verification.
In NestedMessageContent batches forwarded by an RA, all messages MUST be of the same type (e.g., all ir). The original EE PKIMessage MAY be included in generalInfo using infoType {id-it 15} with infoValue PKIMessages in the same order as requests in PKIBody.
Self-signed CAs SHALL be considered as directly trusted CAs for root CA key update purposes. Whether a non-self-signed CA is directly trusted is a matter of CA policy beyond the scope of CMP.
When the indirect POP method is used (certificate encrypted for EE, with CertHash as proof), the CA MUST NOT publish the certificate until the certConf message arrives, because the ability to compute CertHash proves decryption capability.
When verification of a cert confirmation (certConf) message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.
NestedMessageContent (defined as PKIMessages, a SEQUENCE OF PKIMessage) allows an RA to wrap one or more EE messages in a single new PKI message with its own protection layer, enabling the RA to add field values or extensions and to batch multiple EE requests to the CA.
PKIBody is a CHOICE of 27 tagged message types including ir/ip (Initialization Request/Response), cr/cp (Certification Request/Response), kur/kup (Key Update), rr/rp (Revocation Request/Response), certConf (Certificate Confirmation), pollReq/pollRep (Polling), nested (NestedMessageContent), and error (Error Message).
PKIMessage is the top-level CMP structure comprising a mandatory PKIHeader, a mandatory PKIBody, an optional PKIProtection (BIT STRING), and an optional extraCerts sequence. All CMP protocol messages use this single structure.
PKIStatus INTEGER defines accepted (0), grantedWithMods (1), rejection (2), waiting (3), revocationWarning (4), revocationNotification (5), and keyUpdateWarning (6). PKIFailureInfo BIT STRING defines 27 failure codes including badAlg (0), badPOP (9), transactionIdInUse (21), unsupportedVersion (22), and duplicateCertReq (26).
Root CA key update produces four certificate values: OldWithOld (self-signed with old keys), OldWithNew (old public key signed with new private key), NewWithOld (new public key signed with old private key), and NewWithNew (self-signed with new keys). These enable end entities holding either key to verify certificates during the transition period.
POP by exposing the private key (sending it encrypted to the CA/RA) carries significant risk because it requires the requester to trust the CA/RA with key material. A key that may be used for signing SHOULD NOT be sent to the CA/RA to prove possession.
The Diffie-Hellman key exchange used for DH-based MAC protection is subject to attack if DH parameters are not validated. End entities may freely choose DH algorithm parameters, so the CA must be capable of generating an appropriate ephemeral key pair; implementations must validate parameters to resist subgroup and small-subgroup attacks.
When POP is demonstrated via the indirect encrypted-certificate method, the CA must ensure it does not publish the certificate before certConf is received and validated; premature publication would allow a third party who intercepts the certificate response to register the certificate without possessing the private key.
The polling mechanism uses pollReq (tag 25) and pollRep (tag 26) messages. When the CA returns a 'waiting' status, the EE transitions to a polling state and sends periodic pollReq messages; the CA responds with pollRep containing a checkAfter time until the pending operation completes and the actual response (e.g., ip, cp) is returned.
DHBMParameter for Diffie-Hellman-based MAC protection encodes owf (AlgorithmIdentifier, SHA-1 recommended) and mac (AlgorithmIdentifier, e.g., DES-MAC, Triple-DES-MAC, or HMAC). The OWF is applied to the DH computation result to derive BASEKEY; the same key-expansion rule as PBM applies if K > H.
PBMParameter for shared-secret MAC protection encodes salt (OCTET STRING), owf (AlgorithmIdentifier for the one-way function), iterationCount (INTEGER), and mac (AlgorithmIdentifier). The salted secret is passed through the OWF iterationCount times to derive BASEKEY; key expansion uses OWF("N" || BASEKEY) if the MAC requires more than H bits.
PKIHeader encodes pvno (INTEGER, fixed at 2 for cmp2000), sender and recipient (GeneralName), and optional fields: messageTime (GeneralizedTime), protectionAlg (AlgorithmIdentifier), senderKID and recipKID (KeyIdentifier), transactionID, senderNonce, recipNonce (OCTET STRING), freeText (UTF8String sequence), and generalInfo (InfoTypeAndValue sequence).
PKIProtection is a BIT STRING computed over the DER encoding of ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody }. Protection may be a MAC (shared-secret PBM or DH-based) or a digital signature; the field is OPTIONAL but if omitted the protectionAlg field MUST also be omitted.