CoAP Transport for CMPV2

The CMPv2 is used by PKI entities for the generation and management of the certificates. One of the requirements of CMPv2 is to be independent of the transport protocol in use. CMP has mechanisms to take care of required transactions, error reporting and encryption of messages. The CoAP defined in , and is a client-server protocol, like HTTP, that is designed to be used by constrained devices over constrained networks. The recommended transport for CoAP is UDP, however specifies the support of CoAP over TCP, TLS and Websockets. This document specifies the use of CoAP as a transport medium for the CMPv2 and Lightweight CMP Profile. This document, in general, follows the HTTP transport specifications for CMPv2 defined in and specifies the additional requirements for CoAP transport. This document also provides guidance on how to use a "CoAP to HTTP" proxy for a better adaptation of CoAP transport without significant changes to the existing PKI entities. Although CoAP transport can be used for communication between Registration Authority (RA) and Certification Authority (CA) or between CAs, the scope of this document is for communication between End Entity (EE) and RA or EE and CA. This document is applicable only when the CoAP transport is being used for the CMPv2 transactions.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

CMPv2 transaction consists of passing PKIMesssage between the PKI End Entities (EEs), Registration Authorities (RAs), and Certification Authorities (CAs). If the EEs are constrained devices then they will prefer, as a client, the use of CoAP instead of HTTP as a transport medium, while the RAs and CAs, in general, are not constrained and can support both CoAP and HTTP Client and Server implementation. This section specifes how to use CoAP as transport mechanism for CMPv2 or Lightweight CMP Profile.

The information about the URIs of CA and RA that is required by EEs can be either configured out of band on EEs or the EEs can use the service discovery mechanism described in section 7 of to find them. The EE, RA SHOULD support service discovery as described in section 7 of . An EE MUST verify the configured Root CA certificate against the Root CA certificate of the discovered entity to make sure it is talking to correct endpoint.

The CoAP URI MUST follow the guidelines defined in section 3.6 of for CMPv2 protocol. Implementations supporting the Lightweight CMP Profile MUST follow the guidelines specified for HTTP transport defined in section 7.1 of Lightweight CMP Profile. The URI's for CoAP resources should start with coap:// instead of http:// and coaps:// instead of https://

The CMPv2 PKIMessage MUST be DER encoded and sent as the body of the CoAP POST request. If the CoAP request is successful then the server should return a "2.05 Content" response code. If the CoAP request is not successful then an appropriate CoAP Client Error 4.xx or a Server Error 5.xx response code MUST be returned.

When transferring CMPv2 PKIMesssage over CoAP the media type application/pkixcmp MUST be used.

When using the CoAP protocol, a PKI EE SHOULD poll for the possible changes via PKI Information request using General Message defined in the PKIMessage for various type of changes like CA key update or to get current CRL to check revocation or using Support messages defined in section 5.4 of Lightweight CMP Profile. This will help constrained devices acting as EEs save resources as there is no need to open a listening socket for notifications and it will also make the use of a CoAP to HTTP proxy transparent to the EE.

Since the CMPv2 PKIMesssage consists of a header body and optional fields a CMPv2 message can be much larger than the MTU of the outgoing interface of the device. In order to avoid IP fragmentation of messages that are exchanged between EEs and RAs or CAs, the Block Wise transfer mode MUST be used for the CMPv2 Transactions over CoAP. If a CoAP to HTTP proxy is in the path between EEs and CA or EEs and RA then, it MUST receive the entire body from the client before sending the HTTP request to the server. This will avoid unnecessary errors in case the entire content of the PKIMesssage is not received and Proxy opens a connection with the server.

CMPv2 PKIMessage request messages sent from EEs to RAs or from EEs to CAs over CoAP transport MUST not use a Multicast destination address.

Although CPMv2 protocol does not depend upon the underlying transport for the encryption and authentication of the messages but in cases when end to end secrecy is desired for the CoAP transport, CoAP over DTLS as a transport medium SHOULD be used. Section 9.1 of defines how to use DTLS for securing the CoAP. For CMPv2 and Lightweight CMP Profile the clients should follow specifications defined in section 7.1 and section 7.2 of Lightweight CMP Profile for setting up DTLS connection either using certificates or shared secret. Once a DTLS connection is established it SHOULD be used for as long as possible to avoid the frequent overhead of using DTLS connection for constrained devices.

The use of a CoAP to HTTP proxy is recommended to avoid significant changes in the implementation of the CAs and RAs. However, if a proxy is in place then Announcements Messages cannot be passed to EEs efficiently. In case a CoAP to HTTP proxy is used for CMP transactions, it SHOULD support service discovery mentioned in section 2.1

If a CoAP to HTTP proxy is used then it MUST be positioned between EEs and RAs or between EEs and CAs when RA is not part of CMP transactions. The use of a CoAP to HTTP proxy between CAs and RAs is not recommended. The implementation of a CoAP to HTTP proxy is specified in Section 10 of . The CoAP to HTTP proxy will also protect the CAs and RAs from UDP based Denial of Service attacks.

A CoAPs to HTTPS proxy (DTLS transport to TLS transport proxy) can be used instead of the CoAP to HTTP proxy if the server support HTTPS protocol, however client SHOULD be configured to trust the CA certificate used by proxy to sign the Man in the Middle (MITM) certificate for certificate chain validation .

The CMPv2 protocol itself does not require secure transport and depends upon various mechanisms in the protocol itself to make sure that the transactions are secure. However, the CoAP protocol which uses UDP as layer 4 transport is vulnerable to many issues due to the connectionless characteristics of UDP itself. The Security considerations for CoAP protocol are mentioned in the . Using a CoAP to HTTP proxy mitigates some of the risks as the requests from the EE's can terminate inside the trusted network and will not require the server to listen on a UDP port making it safe from UDP based address spoofing, Denial of Service, and amplification attacks due to the characteristics of UDP.

This document requires a new entry to the CoAP Content-Formats Registry code for the content-type application/pkixcmp

The author would like to thank Hendrik Brockhaus, David von Oheimb, and Andreas Kretschmer for their guidance in writing the content of this document and providing valuable feedback.