Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol
Extracted elements (27)
CoAP over UDP is specified as the primary transport (not CoAP over TCP/TLS/WebSockets) because this document targets constrained IoT devices, which benefit from UDP's lower overhead; CMP's own PKIProtection provides integrity without requiring a reliable transport.
Multicast CoAP is prohibited for CMP PKIMessages because CMP transactions require point-to-point exchanges with specific RAs or CAs, and multicast delivery would undermine the targeted, transactional nature of certificate management.
This document follows the HTTP transfer for CMP specifications in RFC 6712 and is designed so a CoAP-to-HTTP proxy can bridge CoAP-speaking constrained EEs to existing PKI entities already providing CMP over HTTP without changes to the PKI implementation.
An EE SHOULD periodically reregister itself for CMP announcement messages, since a server can remove the EE from its list of observers at any time.
CMP PKIMessages MUST be DER encoded and sent as the body of a CoAP POST request. Each CoAP request MUST be marked as a Confirmable message.
CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination address.
CoAP CMP endpoints supporting service discovery MUST also support resource discovery in the CoRE Link Format (RFC 6690), and the link MUST include the 'ct' attribute with the value 'application/pkixcmp'.
CoAP endpoints MUST support use of the path prefix '/.well-known/' and the registered name 'cmp' to enable endpoint discovery and interoperability.
EEs and RAs or CAs MUST use block-wise transfer mode (RFC 7959) to transfer CMP messages larger than the MTU of the outgoing interface, instead of relying on IP fragmentation.
If a CoAP-to-HTTP proxy is in the path and the server supports it, the proxy MUST use chunked transfer encoding (RFC 9112) over HTTP and MUST try to reduce the number of packets by using an optimal chunk length.
If the port number is not specified in the authority, the default port numbers MUST be assumed: 5683 for 'coap:' and 5684 for 'coaps:'.
The CoAP-to-HTTP proxy MUST function as a reverse proxy, only permitting connections to a limited set of preconfigured servers.
When a CoAP CMP request succeeds, the RA or CA MUST return a Success 2.xx response code; otherwise, it MUST return an appropriate Client Error 4.xx or Server Error 5.xx response code.
When transferring CMP PKIMessages over CoAP, the content-format 'application/pkixcmp' MUST be used.
A CMP transaction over CoAP consists of PKIMessage exchanges between end entities (EEs), registration authorities (RAs), and certification authorities (CAs). Constrained EEs act as CoAP clients preferring CoAP over HTTP; RAs and CAs support both.
A CoAP-to-HTTP cross-protocol proxy, based on RFC 7252 Section 10, can bridge constrained EEs using CoAP to existing PKI infrastructure serving CMP over HTTP, since the CMP payload is identical over both transports.
An EE MAY use the CoAP Observe Option (RFC 7641) to register for CMP announcement messages by sending a GET to the server URI suffixed by '/ann'. Supported announcement types include CA Key Update, Certificate, Revocation, and CRL Announcements.
The CoAP URI for CMP follows the pattern 'coap://host/.well-known/cmp[/p/<profileLabel>][/<operation>]', supporting optional path segments for CA distinction and PKI management operations as defined in the Lightweight CMP Profile.
IANA registered 'application/pkixcmp' with ID 259 in the 'CoAP Content-Formats' registry to identify CMP transaction payloads over CoAP.
IANA registered the path segment 'ann' in the 'CMP Well-Known URI Path Segments' registry; EEs use a GET to this path with the CoAP Observe Option to register for CMP announcement messages.
A CoAP-to-HTTP proxy can mitigate DoS, replay, and resource-exhaustion attacks by validating ASN.1 syntax and PKIMessage protection before forwarding to PKI entities; however, the proxy itself may be vulnerable to resource-exhaustion and should use short discard timers and per-client rate limiting.
CMP does not provide confidentiality of its payloads; CoAP over DTLS (RFC 9147) SHOULD be used when confidentiality is desired, though it cannot conceal that CMP is in use within the DTLS layer.
DTLS associations SHOULD be kept alive and reused where possible to amortize the overhead of DTLS session establishment on constrained devices.
Implementations SHOULD use the available datagram size and avoid sending small datagrams containing partial CMP PKIMessage data, in order to reduce memory usage for packet buffering on constrained devices.
The CoAP Observe Option is best-effort; an EE might miss announcement messages (e.g., CRL updates) because the server may lose its observer state. EEs should use alternate polling methods for time-critical changes.
When PKIProtection is used, the PKIHeader and PKIBody of CMP are cryptographically protected against malicious modification, so UDP can be used without compromising CMP security.
CMP PKIMessages are DER-encoded ASN.1 structures carried as the body of CoAP POST requests with content-format 'application/pkixcmp' (CoAP Content-Format ID 259). Large messages exceeding the interface MTU MUST be segmented using CoAP block-wise transfer.