Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)

Chunked Transfer-Encoding is discouraged because the length of an ASN.1 sequence is known before transmission begins, making chunking unnecessary overhead. The Expect/100-continue mechanism is also unnecessary since CMP payloads are small and servers seldom reject without evaluating the body.

http, pkix

HTTP was chosen as the sole transfer protocol because it is generally easy to implement, able to traverse network borders using ubiquitous proxies, and already commonly used in existing CMP implementations. The earlier TCP-based management protocol was found needless and cumbersome.

http, pkix

Persistent HTTP connections are treated as a performance optimization only, not as a mechanism to correlate CMP messages or transactions. CMP's own transaction ID handles multi-message transaction correlation, making HTTP statefulness unnecessary.

http, pkix

Implementations based on earlier drafts of this document may use the unregistered MIME type 'application/pkixcmp-poll'. Implementors should be aware that different HTTP transfer approaches for CMP may exist due to the decade-long development history of this specification.

pkix, http

A receiver MUST answer with a suitable 4xx or 5xx HTTP error code when a problem occurs processing an Announcement.

http, pkix

A server implementation MUST handle Request-URI paths with or without a trailing slash as identical.

http, pkix

Compliant implementations MUST support TLS with the option to authenticate both server and client.

tls, pkix, security

HTTP SHOULD be utilized for conveying CMP messages when a reliable transport protocol like TCP is available for direct interaction between two entities.

http, pkix

If an announced issue was successfully stored or was already present, the response MUST be HTTP 201 Created with an empty message body.

http, pkix

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.

http, pkix

Implementations MUST NOT infer that requests on the same persistent HTTP connection come from the same client; every message is to be evaluated in isolation.

http, pkix

Implementations MUST support HTTP/1.0 and SHOULD support HTTP/1.1.

http, pkix

Recipients of CMP Announcement messages MUST acknowledge receipt with an HTTP response having an appropriate status code and an empty body; when no such response is received, delivery MUST be assumed unsuccessful.

http, pkix

The HTTP response status code for a successful CMP request/response exchange MUST be 200; other 'Successful 2xx' codes MUST NOT be used for this purpose.

http, pkix

The Internet Media Type 'application/pkixcmp' MUST be set in the HTTP Content-Type header field when conveying a PKIMessage.

http, pkix, registry

CMP over HTTP exclusively uses the HTTP POST method for requests, effectively tunneling CMP PKIMessage structures over HTTP. GET and other methods are not used because PKI management operations can only be triggered via CMP PKI messages.

http, pkix

Four CMP Announcement message types may be pushed by a CA via HTTP POST: [15] CA Key Update Announcement, [16] Certificate Announcement, [17] Revocation Announcement, and [18] CRL Announcement. These require no CMP response, only an HTTP status acknowledgement.

http, pkix

HTTP responses to pushed CMP Announcement messages use status code 201 (information successfully stored) or 202 (accepted for further processing). For 202, the sender may retry after an appropriate delay until 201 is received.

http, pkix

The MIME media type 'application/pkixcmp' was previously registered by IANA for identifying CMP sequences at the time of RFC 2510. No new registry actions are required by this document.

registry, pkix, http

Although CMP provides inbuilt integrity protection and its unencrypted messages do not directly endanger PKI security, eavesdroppers may gather confidential technical or business-critical information. Users should consider HTTP over TLS (RFC 2818) or IPsec VPNs (RFC 4301) to protect confidentiality.

security, tls, pkix, privacy

If HTTP responses to pushed Announcement messages are not authenticated and integrity-protected, their processing-state information cannot be trusted. The overall PKI system design must not depend on Announcements being reliably received and processed in this case.

security, pkix

Storing the target location from an HTTP '301 Moved Permanently' response could be exploited by a man-in-the-middle attacker to permanently redirect clients away from the correct server, effectively a permanent denial-of-service. Clients should only follow redirects after careful security consideration.

security, http, pkix

There is a denial-of-service risk through resource exhaustion by opening many connections to an HTTP server. Idle connections should be terminated after an appropriate timeout, and the server should close the connection after sending a CMP Error Message even if the transaction is incomplete.

security, http, pkix

Without encapsulation in TLS or equivalent security protocols, there is no integrity protection at the HTTP protocol level; therefore, information from the HTTP protocol should not be used to change the state of a CMP transaction.

security, tls, http, pkix

A DER-encoded PKIMessage (per ITU-T X.690 and RFC 4210) is sent as the entity-body of an HTTP POST request. The server returns the CMP response in the body of the HTTP response.

http, pkix