Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
obsoletes
- rfc-4210 — Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
- rfc-9480 — Certificate Management Protocol (CMP) Updates
updates
- rfc-5912 — New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
Extracted elements (29)
CMS EnvelopedData is used instead of the deprecated EncryptedValue throughout CMP (private key protection, certificate encryption, POP, revocation passphrases) to improve crypto agility. CMP version 3 was introduced specifically to signal this ASN.1-level change while maintaining version 2 backward compatibility.
The indirect POP method (encrypting the issued certificate for the end entity and verifying decryption in the confirmation message) is preferred over the direct challenge-response method because it requires no extra messages; the {request, response, confirmation} triple suffices for both encryption and KEM keys.
The KEM MAC protection scheme places id-KemBasedMac on the private arc 1.2.840.113533.7.66 (Nortel/Entrust) rather than an IANA arc to keep it co-located with the existing id-PasswordBasedMac and id-DHBasedMac OIDs.
Backward compatibility with CMP version 2 is maintained wherever possible; CMP version 3 (pvno=3) is used only when the transaction requires EnvelopedData, certConf with hashAlg, POPOPrivKey with agreeMAC, or RootCaKeyUpdateContent in ckuann messages.
CMP messages carry integrity protection but no mandatory confidentiality; unencrypted CMP traffic may expose confidential technical or business-critical metadata. Implementers should consider adding TLS (RFC 8446), DTLS (RFC 9147), or IPsec for transport-level confidentiality.
A certification request for a KEM certificate SHALL use POPOPrivKey with the keyEncipherment choice of ProofOfPossession in the popo field of CertReqMsg, as long as no KEM-specific POP choice is defined.
A PKI entity holding a KEM key pair and wishing to use it for MAC-based protection MUST support KEM Decapsulate(); the verifying entity MUST support KEM Encapsulate(). Bob encapsulates and sends the ciphertext; Alice decapsulates and derives the MAC key via a KDF.
CAs and RAs MUST enforce Proof-of-Possession (POP) by some means because many operational protocols do not verify the binding between an end entity and its private key; without CA/RA enforcement, Internet PKI certificates would be less meaningful.
For multi-message transactions containing a KemCiphertextInfo infoValue, the client MUST generate a transactionID; otherwise it SHOULD generate one. Servers MUST echo the received transactionID and MUST respond with transactionIdInUse if the ID conflicts with an in-progress transaction.
If no PKIProtection is supplied, protectionAlg MUST be omitted; if protection is supplied, protectionAlg MUST be present. senderKID SHOULD be used in any case and MUST be used if needed to uniquely identify the key.
If the CA grants an ImplicitConfirm request, it MUST include the same id-it-implicitConfirm extension in the response PKIHeader; if the end entity does not find the extension in the response, it MUST send a certificate confirmation message.
It is RECOMMENDED that clients populate transactionID with 128 bits of pseudo-random data at transaction start to minimize collision probability; senderNonce is likewise typically 128 bits of random data and recipNonce MUST copy the previous message's senderNonce.
To prove authorized delegation, certificates used for CMP message protection or signed central key generation MUST be issued by the delegating CA and MUST contain the respective EKU (id-kp-cmcCA, id-kp-cmcRA, or id-kp-cmKGA).
When a CA key update link certificate 'new with new' is created, its notBefore MUST precede the notAfter of 'old with old'; the 'new with old' certificate MUST share the same notBefore as 'new with new' and expire no later than when all end entities possess the new key.
When the sender is unknown (e.g., initial request with no DN), the sender field MUST contain a NULL-DN (SEQUENCE OF zero-length RDNs, encoded 0x3000), and senderKID MUST hold a reference number identifying the shared secret.
KemCiphertextInfo (OID id-it-KemCiphertextInfo, arc id-it 24) is a generalInfo extension a PKI entity MAY include in a request to carry the KEM ciphertext for MAC-based message protection when it knows the recipient holds a KEM key pair.
PKIBody is a CHOICE of 27 tagged message types covering initialization (ir/ip), certification (cr/cp), PKCS#10 (p10cr), POP challenge/response (popdecc/popdecr), key update (kur/kup), key recovery (krr/krp), revocation (rr/rp), cross-certification (ccr/ccp), CA announcements, polling, error, and general messages.
PKIMessage is the top-level container with a mandatory PKIHeader and PKIBody, an optional PKIProtection BIT STRING, and an optional extraCerts field carrying auxiliary certificates useful to the recipient.
The Key Generation Authority (KGA) is an optional PKI management entity that generates key pairs on behalf of end entities and therefore knows both the public and private key. Its authorization is indicated by the id-kp-cmKGA EKU or by the CA certificate itself.
Three EKU OIDs are defined for CMP delegation: id-kp-cmcCA (pkix.kp.27) for CA role, id-kp-cmcRA (pkix.kp.28) for RA role, and id-kp-cmKGA (pkix.kp.32) for Key Generation Authority. These reuse CMC OIDs for CA/RA as protocol-agnostic roles.
This document updates IANA registries for CMP OIDs, including new id-it extensions (id-it-certProfile at id-it 21, id-it-KemCiphertextInfo at id-it 24) and the new EKU id-kp-cmKGA (pkix.kp.32), as specified in Section 9.
Trust anchor provisioning via CMP messages requires that the initial trust anchor is acquired through a trustworthy out-of-band mechanism; bootstrapping (e.g., BRSKI or SZTP) establishes the root CA public key before any CMP message-based provisioning can be considered secure.
Using a KEM key pair recurrently for message protection across many transactions creates a long-term relationship between the KEM private key and the protected messages, which may weaken forward secrecy; implementers should consider key rotation policies for KEM protection keys.
When authorizing requests for certificates with specific EKUs (e.g., CA, RA, KGA roles), the issuing CA must verify the requester is authorized to hold those EKUs; misconfigured delegation can allow an entity to fraudulently act as a CA or RA within the PKI.
Root CA key update defines four verification cases based on whether the verifier's TEE holds the old or new CA public key and whether the signer's certificate was issued under the old or new key. Cases 1 and 4 verify directly; Case 2 requires retrieving 'new with new' and 'new with old' link certificates; Case 3 requires retrieving the 'old with new' certificate.
KemBMParameter (OID id-KemBasedMac, arc 1.2.840.113533.7.66.16) encodes: kdf (AlgorithmIdentifier for key derivation), optional kemContext [0] OCTET STRING, len INTEGER (output key length in octets), and mac (AlgorithmIdentifier). len MUST equal the desired MAC key size.
PBMParameter for id-PasswordBasedMac encodes: salt (OCTET STRING), owf (AlgorithmIdentifier for the one-way function), iterationCount (INTEGER), and mac (AlgorithmIdentifier). When K > H bits are required, key expansion using OWF("N" || BASEKEY) MUST be applied.
PKIHeader encodes pvno (cmp1999=1, cmp2000=2, cmp2021=3), sender and recipient GeneralNames, optional messageTime, protectionAlg, senderKID, recipKID, transactionID, senderNonce, recipNonce, freeText, and generalInfo extension sequence.
PKIProtection is a BIT STRING computed over the DER encoding of ProtectedPart SEQUENCE { header PKIHeader, body PKIBody }. It contains either a MAC (shared secret or KEM-derived key) or a digital signature.