The Certificate Management Protocol (CMP) is an Internet protocol standardized by the IETF used for obtaining X.509 public-key certificates in a PKI.
CMP is a very feature-rich and flexible protocol. So far it is the only protocol with support of all types of cryptography. This includes KEM keys, which have become more important for post-quantum cryptography (PQC).
CMP messages are self-contained, which makes the protocol independent of the transport mechanism and provides end-to-end security also over multiple hops. This distinguishes CMP and CMC from other certificate enrollment protocols including EST. CMP messages are defined in ASN.1 syntax and encoded using the DER method.
CMP is described in RFC9810. Enrollment request messages employ the Certificate Request Message Format (CRMF), described in RFC4211 and updated in RFC9045. The only other protocol so far using CRMF is Certificate Management over CMS (CMC), described in RFC5273.
History
An obsolete version of CMP is described in RFC2510, the respective CRMF version in RFC2511. Both were published in March 1999.
In July 2025, RFC 9810 was released, which combines the RFCs 4210 and 9480 into a self-contained document and adds furher features, in particular support for KEM keys.
PKI Entities
In a Public-Key Infrastructure (PKI), so-called end entities (EEs) act as CMP client, requesting one or more certificates for themselves from a certificate authority (CA), which issues the legal certificates and acts as a CMP server. None or any number of registration authorities (RA), can be used to mediate between the EEs and CAs, having both a downstream CMP server interface and an upstream CMP client interface. Using a "cross-certification request" a CA can get a certificate signed by another CA.
Features
Self-contained messages with protection independent of transfer mechanism – as opposed to related protocols EST, SCEP, and ACME, this supports end-to-end security also over several hops.
Full certificate life-cycle support: an end entity can utilize CMP to obtain certificates from a CA, request updates for them, and also get them revoked.
Key pair generation is usually done by the client side, but can also be requested from the server side.
Proof-of-possession is usually done by a self-signature of the requested certificate contents, but CMP supports also other methods. This is crucial in particular for requesting certificates for KEM-only keys.
CMP supports the very important aspect of proof-of-origin in two formats: MAC-based with a shared secret (used initially) and signature-based (using pre-existing certificates).
In case an end entity has lost its private key and it is stored by the CA, it might be recovered by requesting a "key pair recovery".
There are various further types of requests possible, for instance to retrieve CA certificates and to obtain PKI parameters and preferences of the server side.
Transport
CMP messages are usually transferred over HTTP, but any reliable means of transportation can be used.
Encapsulated in HTTP messages,[1] optionally using TLS (HTTPS) for additional protection.
Encapsulated in CoAP messages, optionally using DTLS for additional protection.[2]
TCP or any other reliable, connection-oriented transport protocol.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
