Certificate Management Protocol (CMP) Updates
obsoleted by
- rfc-9810 — Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
- rfc-9811 — Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
updates
Extracted elements (30)
CMP version 3 (cmp2021) is introduced specifically to signal support for EnvelopedData instead of EncryptedValue, and to signal use of an explicit hash AlgorithmIdentifier in certConf messages. Using cmp2000 as the default pvno avoids extra version-negotiation round trips and maintains compatibility with existing implementations.
EncryptedValue is deprecated in favor of EnvelopedData to improve crypto agility, consistent with RFC 4211 Section 2.1 point 9. The EncryptedKey CHOICE wrapper is bits-on-the-wire compatible with the old EncryptedValue syntax when the untagged default choice is used, enabling backward-compatible migration.
The EncryptedKey CHOICE structure is backward compatible: using the untagged default choice EncryptedValue is bits-on-the-wire identical to the old CMP v2 syntax. CMP v3 (cmp2021) MUST use the EnvelopedData choice; CMP v2 implementations using thisMessage for POPOPrivKey MUST encode its contents as EncryptedValue wrapped in a BIT STRING.
A trust anchor provider MUST NOT include to-be-trusted CA certificates in a CMP message unless the deployment ensures adequacy. Whenever an EE receives a CA certificate as a trust anchor, it MUST authenticate the message sender using existing trust anchor information and MUST verify the sender is authorized to provide trust anchors.
Certificates used for CMP message protection or signed data for central key generation MUST be issued by the delegating CA and MUST contain the respective EKU extensions (id-kp-cmcCA, id-kp-cmcRA, or id-kp-cmKGA) to prove the delegation of authorization.
Each CMP server supporting HTTP or HTTPS MUST support the path prefix '/.well-known/' with the registered name 'cmp' to ease interworking in multi-vendor environments. The URI structure supports optional /p/<name> and /<operation> path segments.
If a client knows the protocol version(s) supported by the server, it MUST send a PKIMessage with the highest version supported by both parties. If the server version is unknown, the client MUST send using its highest supported version, except that cmp2021 SHOULD only be used if cmp2021 syntax (EnvelopedData or hashAlg) is actually needed.
If a client receives an ErrorMsgContent with pvno cmp1999 after sending a message with a higher protocol version, it MUST abort the current transaction. This extends the version negotiation behavior to clients using any version higher than cmp1999.
In a CertResponse to a p10cr message, the certReqId MUST be set to -1 because p10cr contains exactly one CertificationRequestInfo with no certReqId field. This fixes Errata IDs 3949 and 4078.
It is RECOMMENDED that PBMParameter fields remain constant throughout all messages of a single CMP transaction (e.g., ir/ip/certConf/pkiConf) to reduce the overhead associated with PasswordBasedMac computation. This fixes Errata ID 2616.
The content of an EnvelopedData structure MUST be encrypted using a newly generated symmetric content-encryption key. This content-encryption key MUST be securely provided to the recipient using key transport, key agreement, or password-based key management techniques as specified in CMS RFC 5652.
The hashAlg field in CertStatus SHOULD be used only when the signatureAlgorithm of the confirmed certificate does not specify a hash algorithm. In such cases (e.g., EdDSA), hashAlg MUST be used to specify the hash algorithm for computing certHash.
When id-it-certProfile is used in an ir/cr/kur/genm, the value MUST NOT contain more elements than the number of CertReqMsg or InfoTypeAndValue elements. When used in a p10cr, the value MUST NOT contain multiple certificate profile names.
CRL Update Retrieval uses id-it-crlStatusList (id-it 22) in the GenMsg with a SEQUENCE of CRLStatus structures (each containing a CRLSource and optional thisUpdate Time), and id-it-crls (id-it 23) in the GenRep with fresh CertificateList entries. The server only returns CRLs more recent than those indicated by the client.
EncryptedKey is defined as a CHOICE between the deprecated EncryptedValue and EnvelopedData (tagged [0]). It is used in CMP to transport private keys, certificates, or revocation passphrases in encrypted form. EnvelopedData is the recommended choice.
id-it-caCerts (id-it 17) is a new general message type allowing a client to request CA certificates. The GenMsg body is absent; the GenRep body contains a SEQUENCE SIZE (1..MAX) OF CMPCertificate or is absent if no certificates are available.
id-it-certProfile (id-it 21) is a new generalInfo OID allowing an EE to indicate specific certificate profile names in ir/cr/kur/p10cr/genm messages. The CertProfileValue is a SEQUENCE of UTF8String values corresponding positionally to the CertReqMsg elements.
Three new Extended Key Usage OIDs are defined: id-kp-cmcCA (id-pkix kp 27) for CA role, id-kp-cmcRA (id-pkix kp 28) for RA role, and id-kp-cmKGA (id-pkix kp 32) for Key Generation Authority role. These allow automated validation of PKI management entity delegation.
IANA registered 'cmp' as a permanent entry in the 'Well-Known URIs' registry and created a new 'Certificate Management Protocol (CMP)' registry group with a 'CMP Well-Known URI Path Segments' registry. The initial entry is path segment 'p', indicating the next segment specifies a CA or certificate profile name.
IANA registered id-kp-cmKGA (decimal 32) in the 'SMI Security for PKIX Extended Key Purpose' registry for the CMP Key Generation Authority extended key usage.
IANA registered seven new entries in the 'SMI Security for PKIX CMP Information Types' registry: id-it-caCerts (17), id-it-rootCaKeyUpdate (18), id-it-certReqTemplate (19), id-it-rootCaCert (20), id-it-certProfile (21), id-it-crlStatusList (22), and id-it-crls (23).
IANA registered two new entries in the 'SMI Security for PKIX CRMF Registration Controls' registry: id-regCtrl-algId (11) for specifying a cryptographic algorithm in certificate request templates, and id-regCtrl-rsaKeyLen (12) for specifying the intended RSA modulus bit length.
A CA should not reuse its certificate signing key for other purposes such as protecting CMP responses or TLS connections. Separating the CA signing key minimizes its exposure and reduces its usage to a minimum. This fixes Errata ID 5731.
Implementations must generate nonces and private keys from cryptographically secure random input. If shared secret information is generated by a CSRNG, its entropy equals its bit length; for centrally generated key pair delivery, shared secret entropy SHOULD NOT be less than the security strength of the key pair. It is RECOMMENDED that low-entropy secrets (e.g., user passwords) be limited to a single PKI management operation.
When a CA issues a certificate containing EKU extensions defined in Section 4.5 (cmcCA, cmcRA, cmKGA), this expresses delegation of authorization originally held only by the CA certificate itself. Such delegation is a sensitive PKI action and requires special care to ensure only legitimate entities receive such EKUs.
The polling mechanism is extended from ir/cr/kur to all PKI message types. An EE enters the Polling state upon receiving any response with PKIStatus 'waiting' (including error messages with certReqId -1). The EE sends pollReq, and the CA/RA returns pollRep (with checkAfter seconds) or the final response.
CertReqTemplateContent (id-it 19) is a SEQUENCE of a CertTemplate and optional Controls (keySpec). The publicKey field in certTemplate MUST NOT be used; supported key algorithms are specified via id-regCtrl-algId (id-pkix pkip regCtrl 11) and id-regCtrl-rsaKeyLen (id-pkix pkip regCtrl 12) controls.
CertStatus gains an optional hashAlg field ([0] AlgorithmIdentifier) for explicitly specifying the digest algorithm when the certificate's signatureAlgorithm OID does not indicate a hash (e.g., EdDSA). If hashAlg is present, the certConf message header MUST use cmp2021(3).
PKIHeader pvno field is updated to include cmp2021(3) alongside cmp1999(1) and cmp2000(2). The pvno INTEGER value 3 signals support for EnvelopedData and the optional hashAlg field in CertStatus.
RootCaKeyUpdateContent is defined for id-it-rootCaKeyUpdate (id-it 18) responses: a SEQUENCE with mandatory newWithNew CMPCertificate and optional newWithOld ([0]) and oldWithNew ([1]) CMPCertificate fields. Unlike CAKeyUpdAnnContent, the optional cross-certificates may be omitted.