Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
obsoletes
Extracted elements (22)
HTTP/1.0 support was removed in this document (compared to RFC 6712) in accordance with Section 4.1 of BCP 56 (RFC 9205), reflecting updated best practices for building protocols with HTTP.
HTTP POST is used exclusively (rather than GET or other methods) because PKI management operations can only be triggered via CMP PKI messages; while tunneling over POST is generally bad practice per BCP 56, HTTP is widely implemented, traverses proxies, and is already prevalent in existing CMP deployments.
The '/.well-known/cmp' URI prefix was introduced (via RFC 9480) to ease interworking in multi-vendor environments and support PKI management operations defined in the Lightweight CMP Profile.
Implementations based on earlier documents may use the unregistered 'application/pkixcmp-poll' media type; conforming implementations MAY handle this type like 'application/pkixcmp'.
A DER-encoded PKIMessage MUST be sent as the content of an HTTP POST request. The HTTP response status code for a successful request MUST be 200 (OK); other 2xx status codes MUST NOT be used for this purpose.
Each CMP server supporting HTTP or HTTPS transfer MUST support the use of the path prefix '/.well-known/' as defined in RFC 8615 and the registered name 'cmp'.
HTTP SHOULD be utilized for conveying CMP messages when a reliable transport protocol like TCP is available for direct interaction between two entities.
If the announced issue was successfully stored in a database or was already present, the answer MUST be an HTTP response with a 201 (Created) status code and empty content. A receiver MUST answer with a suitable 4xx or 5xx error code when a problem occurs.
If the receipt of an HTTP request is not confirmed by receiving an HTTP response, it MUST be assumed that the transferred CMP message was not successfully delivered to its destination.
The Internet media type 'application/pkixcmp' MUST be set in the HTTP 'Content-Type' header field when conveying a PKIMessage.
When pushing announcement messages, PKIMessage structures MUST be sent as the content of an HTTP POST request. The recipient MUST acknowledge receipt with an HTTP response having an appropriate status code and empty content.
Whenever a client receives an HTTP response with a status code in the 2xx, 4xx, or 5xx ranges, it MUST support handling response message content containing a CMP response PKIMessage.
Unencrypted CMP messages do not contain directly sensitive PKI-endangering information, but an eavesdropper could gather confidential personal, technical, or business-critical information; TLS or VPN protection is recommended to ensure EE privacy.
CMP announcement messages (CA Key Update Announcement [15], Certificate Announcement [16], Revocation Announcement [17], CRL Announcement [18]) may be pushed by a CA via HTTP POST; recipients respond with HTTP status codes only, not CMP responses.
CMP over HTTP exclusively uses the POST method for requests, effectively tunneling CMP over HTTP. Other HTTP request methods such as GET are not used because PKI management operations can only be triggered using CMP's PKI messages.
The CMP well-known URI structure supports the following path patterns: '/.well-known/cmp', '/.well-known/cmp/<operation>', '/.well-known/cmp/p/<name>', and '/.well-known/cmp/p/<name>/<operation>'.
IANA updated references for 'application/pkixcmp' in the Media Types registry and CoAP Content-Formats registry, and updated the 'cmp' entry in the Well-Known URIs registry and 'p' in the CMP Well-Known URI Path Segments registry to point to this document.
CMP provides inbuilt integrity protection and authentication; however, an eavesdropper may gather confidential information from unencrypted CMP messages. Users should consider HTTP over TLS (RFC 9110) or IPsec VPNs to protect confidentiality and ensure EE privacy.
Storing the target location of an HTTP 301 (Moved Permanently) response could be exploited by a meddler-in-the-middle attacker to permanently block clients from contacting the correct server; Redirection 3xx support should only be enabled after careful security consideration.
There is risk of denial-of-service attacks through resource consumption by opening many connections to an HTTP server; idle connections should be terminated after an appropriate timeout.
Without TLS or HTTP digest protection, there is no integrity protection at the HTTP level; information from HTTP headers should not be used to change transaction state regardless of any authentication mechanism in place.
PKIMessage structures are DER-encoded per ITU-T X.690 and transmitted as the body of HTTP POST requests with Content-Type 'application/pkixcmp'.