RFC 9482: Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol









This document species the use of the Constrained Application Protocol (CoAP) as a transfer

mechanism for the Certicate Management Protocol (CMP). CMP denes the interaction between

various PKI entities for the purpose of certicate creation and management. CoAP is an HTTP-

like client-server protocol used by various constrained devices in the Internet of Things space.

Stream:

RFC:

Category:

Published:

ISSN:

Authors:

Internet Engineering Task Force (IETF)

9482

Standards Track

November 2023

2070-1721

M. Sahni, Ed.

Palo Alto Networks

S. Tripathi, Ed.

Palo Alto Networks



This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the

consensus of the IETF community. It has received public review and has been approved for

publication by the Internet Engineering Steering Group (IESG). Further information on Internet

Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback

on it may be obtained at .https://www.rfc-editor.org/info/rfc9482



reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF

Documents ( ) in eect on the date of publication of this

document. Please review these documents carefully, as they describe your rights and restrictions

with respect to this document. Code Components extracted from this document must include

Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are

provided without warranty as described in the Revised BSD License.

https://trustee.ietf.org/license-info

Sahni & Tripathi Standards Track Page 1



1.Introduction

1.1.Requirements Language

2.CoAP Transfer Mechanism for CMP

2.1.CoAP URI Format

2.2.Discovery of CMP RA/CA

2.3.CoAP Request Format

2.4.CoAP Block-Wise Transfer Mode

2.5.Multicast CoAP

2.6.Announcement PKIMessage

3.Proxy Support

4.Security Considerations

5.IANA Considerations

6.References

6.1.Normative References

6.2.Informative References

Acknowledgements

Authors' Addresses

 

The Certicate Management Protocol (CMP) is used by the PKI entities for the

generation and management of certicates. One of the requirements of CMP is to be independent

of the transport protocol in use. CMP has mechanisms to take care of required transactions, error

reporting, and protection of messages.

The Constrained Application Protocol (CoAP) dened in , , and is a

client-server protocol like HTTP. It is designed to be used by constrained devices over constrained

networks. The recommended transport for CoAP is UDP; however, species the

support of CoAP over TCP, TLS, and WebSockets.

[RFC4210]

[RFC7252] [RFC7959] [RFC8323]

[RFC8323]

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 2

This document species the use of CoAP over UDP as a transport medium for

, (designated as CMP in this document), and the

. In general, this document follows the HTTP transfer for CMP

specications dened in and species the requirements for using CoAP as a transfer

mechanism for CMP.

This document also provides guidance on how to use a "CoAP-to-HTTP" proxy to ease adoption of

a CoAP transfer mechanism by enabling the interconnection with existing PKI entities already

providing CMP over HTTP.

 

The key words " ", " ", " ", " ", " ", " ", "

", " ", " ", " ", and " " in this document are to

be interpreted as described in BCP14 when, and only when, they appear in

all capitals, as shown here.

CMP version 2

[RFC4210] CMP version 3 [RFC9480] Lightweight

CMP Prole [RFC9483]

[RFC6712]

      

    

[RFC2119] [RFC8174]

 

A CMP transaction consists of exchanging PKIMessages between PKI end entities (EEs),

registration authorities (RAs), and certication authorities (CAs). If the EEs are constrained

devices, then they may prefer, as a CMP client, the use of CoAP instead of HTTP as the transfer

mechanism. In general, the RAs and CAs are not constrained and can support both CoAP and

HTTP client and server implementations. This section species how to use CoAP as the transfer

mechanism for CMP.

[RFC4210]

 

The CoAP URI format is described in . The CoAP endpoints support

use of the path prex "/.well-known/" as dened in and the registered name "cmp" to

help with endpoint discovery and interoperability. Optional path segments be added after

the registered application name (i.e., after "/.well-known/cmp") to provide distinction. The path

segment 'p' followed by an arbitraryLabel <name> could, for example, support the dierentiation

of specic CAs or certicate proles. Further path segments, for example, as specied in

, could indicate PKI management operations using an

operationLabel <operation>. A valid full CMP URI can look like this:

Section 6 of [RFC7252] 

[RFC8615]



Lightweight CMP Prole [RFC9483]

coap://www.example.com/.well-known/cmp

coap://www.example.com/.well-known/cmp/<operation>

coap://www.example.com/.well-known/cmp/p/<profileLabel>

coap://www.example.com/.well-known/cmp/p/<profileLabel>/<operation>

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 3

 

The EEs can be congured with enough information to form the CMP server URI. The minimum

information that can be congured is the scheme, i.e., "coap:" or "coaps:", and the authority

portion of the URI, e.g., "example.com:5683". If the port number is not specied in the authority,

then the default port numbers be assumed for the "coap:" and "coaps:" scheme URIs. The

default port for "coap:" scheme URIs is 5683 and the default port for "coaps:" scheme URIs is 5684

Optionally, in the environments where a Local RA or CA is deployed, EEs can also use the CoAP

service discovery mechanism to discover the URI of the Local RA or CA. The CoAP CMP

endpoints supporting service discovery also support resource discovery in the Constrained

RESTful Environments (CoRE) Link Format, as described in . The link include the

'ct' attribute dened in with the value of "application/pkixcmp", as

dened in the "CoAP Content-Formats" IANA registry.



[RFC7252]



[RFC6690] 

Section 7.2.1 of [RFC7252]

 

The CMP PKIMessages be DER encoded and sent as the body of the CoAP POST request. A

CMP client send each CoAP request marked as a Conrmable message . If the

CoAP request is successful, then the CMP RA or CA return a Success 2.xx response code;

otherwise, the CMP RA or CA return an appropriate Client Error 4.xx or Server Error 5.xx

response code. A CMP RA or CA may choose to send a piggybacked response to the

client, or it send a separate response in case it takes some time for the RA or CA to

process the CMP transaction.

When transferring CMP PKIMessage over CoAP, the content-format "application/pkixcmp"

be used.



 [RFC7252]



[RFC7252]

 [RFC7252]



 

A CMP PKIMessage consists of a header, body, protection, and extraCerts structure, which may

contain many optional and potentially large elds. Thus, a CMP message can be much larger than

the Maximum Transmission Unit (MTU) of the outgoing interface of the device. The EEs and RAs

or CAs use the block-wise transfer mode to transfer such large messages instead

of relying on IP fragmentation.

If a CoAP-to-HTTP proxy is in the path between EEs and an RA or EEs and a CA and if the server

supports, then it use the chunked transfer encoding to send data over the HTTP

transport. The proxy try to reduce the number of packets sent by using an optimal chunk

length for the HTTP transport.

 [RFC7959]

 [RFC9112]



 

CMP PKIMessages sent over CoAP use a Multicast destination address.

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 4

 

A CMP server may publish announcements that can be triggered by an event or periodically for

the other PKI entities. Here is the list of CMP announcement messages prexed by their

respective ASN.1 identier (see ):

An EE use the CoAP Observe Option to register itself to get any announcement

messages from the RA or CA. The EE can send a GET request to the server's URI suxed by "/

ann". For example, a path to register for announcement messages may look like this:

If the server supports CMP announcement messages, then it send an appropriate Success

2.xx response code; otherwise, it send an appropriate Client Error 4.xx or Server Error 5.xx

response code. If for some reason the server cannot add the client to its list of observers for the

announcements, it can omit the Observe Option in the response to the client. Upon

receiving a Success 2.xx response without the Observe Option , after some time, a

client try to register again for announcements from the CMP server. Since a server can

remove the EE from the list of observers for announcement messages, an EE

periodically reregister itself for announcement messages.

Alternatively, an EE periodically poll for the current status of the CA via the "PKI

Information Request" message; see . If supported, EEs also use

"support messages" dened in to get

information about the CA status. These mechanisms will help constrained devices that are acting

as EEs to conserve resources by eliminating the need to create an endpoint for receiving

notications from the RA or CA. It will also simplify the implementation of a CoAP-to-HTTP

proxy.

Section 5.1.2 of [RFC4210]

[15] CA Key Update Announcement

[16] Certificate Announcement

[17] Revocation Announcement

[18] CRL Announcement

 [RFC7641]

coap://www.example.com/.well-known/cmp/ann

coap://www.example.com/.well-known/cmp/p/<profileLabel>/ann



[RFC7641]







Section 6.5 of [RFC4210] 

Section 4.3 of Lightweight CMP Prole [RFC9483]

 

This section provides guidance on using a CoAP-to-HTTP proxy between EEs and RAs or CAs in

order to avoid changes to the existing PKI implementation.

Since the CMP payload is the same over CoAP and HTTP transfer mechanisms, a CoAP-to-HTTP

cross-protocol proxy can be implemented based on . The CoAP-to-HTTP

proxy can either be located closer to the EEs or closer to the RA or CA. The proxy support

service discovery and resource discovery, as described in Section 2.2. The CoAP-to-HTTP proxy

Section 10 of [RFC7252]



RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 5

function as a reverse proxy, only permitting connections to a limited set of precongured

servers. It is out of scope of this document to specify how a reverse proxy can route CoAP client

requests to one of the congured servers. Some recommended mechanisms are as follows:

Use the Uri-Path option to identify a server.

Use separate hostnames for each of the congured servers and then use the Uri-Host option

for routing the CoAP requests.

Use separate hostnames for each of the congured servers and then use Server Name

Indication in case of the "coaps://" scheme for routing CoAP requests.



•

[RFC8446]

 

If PKIProtection is used, the PKIHeader and PKIBody of the CMP are cryptographically

protected against malicious modications. As such, UDP can be used without compromising

the security of the CMP. Security considerations for CoAP are dened in .

The CMP does not provide condentiality of the CMP payloads. If condentiality is desired,

CoAP over DTLS be used to provide condentiality for the CMP payloads;

although, it cannot conceal that the CMP is used within the DTLS layer.

denes how to use DTLS for securing CoAP. DTLS

associations be kept alive and reused where possible to amortize on the

additional overhead of DTLS on constrained devices.

An EE might not witness all of the announcement messages when using the CoAP Observe

Option , since the Observe Option is a "best-eort" approach and the server might

lose its state for subscribers to its announcement messages. The EEs may use an alternate

method described in Section 2.6 to obtain time critical changes, such as Certicate

Revocation List (CRL) updates.

Implementations use the available datagram size and avoid sending small

datagrams containing partial CMP PKIMessage data in order to reduce memory usage for

packet buering.

A CoAP-to-HTTP proxy can also protect the PKI entities by handling UDP and CoAP messages.

The proxy can mitigate attacks, like denial-of-service attacks, replay attacks, and resource-

exhaustion attacks, by enforcing basic checks, like validating that the ASN.1 syntax is

compliant to CMP messages and validating the PKIMessage protection before sending them

to PKI entities.

Since the proxy may have access to the CMP-level metadata and control over the ow of CMP

messages, proper role-based access control should be in place. The proxy can be deployed at

the edge of the "end entities" network or in front of an RA and CA to protect them. However,

the proxy may itself be vulnerable to resource-exhaustion attacks as it's required to buer

the CMP messages received over CoAP transport before sending it to the HTTP endpoint. This

can be mitigated by using short timers for discarding the buered messages and rate

limiting clients based on the resource usage.

•

[RFC7252]

•

[RFC9147] 

• Section 9.1 of [RFC7252] [RFC9147]

[RFC9147] 

•

[RFC7641]

[RFC5280]

• 

•

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 6











 

 

, , ,

, , March 1997,

, , , and ,

, ,

, September 2005, .

, , ,

, August 2012, .

and ,

, ,

, September 2012, .

, , and ,

, , , June 2014,

Type name:

Subtype name:

Reference:

Path Segment:

Description:

Reference:

 

IANA has registered "application/pkixcmp" (ID 259) in the "CoAP Content-Formats" registry to

transfer CMP transactions over CoAP.

application

pkixcmp

RFC 9482

IANA has also registered a new path segment "ann" in the "CMP Well-Known URI Path Segments"

registry for the EEs to register themselves for the announcement messages.

ann

The path to send a GET request with the CoAP Observe Option to register for CMP

announcement messages.

RFC 9482

IANA has added this document as a reference for the "cmp" entry in the "Well-Known URIs"

registry.

IANA has also added this document as a reference for the "p" entry in the "CMP Well-Known URI

Path Segments" registry.

[RFC4210]

Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels" BCP 14

RFC 2119 DOI 10.17487/RFC2119 <https://www.rfc-editor.org/info/

rfc2119>

Adams, C. Farrell, S. Kause, T. T. Mononen "Internet X.509 Public Key

Infrastructure Certicate Management Protocol (CMP)" RFC 4210 DOI 10.17487/

RFC4210 <https://www.rfc-editor.org/info/rfc4210>

Shelby, Z. "Constrained RESTful Environments (CoRE) Link Format" RFC 6690

DOI 10.17487/RFC6690 <https://www.rfc-editor.org/info/rfc6690>

Kause, T. M. Peylo "Internet X.509 Public Key Infrastructure -- HTTP

Transfer for the Certicate Management Protocol (CMP)" RFC 6712 DOI

10.17487/RFC6712 <https://www.rfc-editor.org/info/rfc6712>

Shelby, Z. Hartke, K. C. Bormann "The Constrained Application Protocol

(CoAP)" RFC 7252 DOI 10.17487/RFC7252 <https://www.rfc-

editor.org/info/rfc7252>

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 7























, , , September 2015,

and ,

, , , August 2016,

, ,

, , , May 2017,

, , ,

, May 2019, .

, , and , , ,

, , June 2022,

, , and ,

, , , April

2022, .

, , and ,

, , , November 2023,

, , and ,

, , ,

November 2023, .

 

, , , , , and ,

, , , May 2008,

, , , , , and

, ,

, , February 2018,

, , ,

, August 2018, .

Hartke, K. "Observing Resources in the Constrained Application Protocol

(CoAP)" RFC 7641 DOI 10.17487/RFC7641 <https://www.rfc-

editor.org/info/rfc7641>

Bormann, C. Z. Shelby, Ed. "Block-Wise Transfers in the Constrained

Application Protocol (CoAP)" RFC 7959 DOI 10.17487/RFC7959

<https://www.rfc-editor.org/info/rfc7959>

Leiba, B. "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" BCP

14 RFC 8174 DOI 10.17487/RFC8174 <https://www.rfc-editor.org/info/

rfc8174>

Nottingham, M. "Well-Known Uniform Resource Identiers (URIs)" RFC 8615

DOI 10.17487/RFC8615 <https://www.rfc-editor.org/info/rfc8615>

Fielding, R., Ed. Nottingham, M., Ed. J. Reschke, Ed. "HTTP/1.1" STD 99 RFC

9112 DOI 10.17487/RFC9112 <https://www.rfc-editor.org/info/

rfc9112>

Rescorla, E. Tschofenig, H. N. Modadugu "The Datagram Transport Layer

Security (DTLS) Protocol Version 1.3" RFC 9147 DOI 10.17487/RFC9147

<https://www.rfc-editor.org/info/rfc9147>

Brockhaus, H. von Oheimb, D. J. Gray "Certicate Management Protocol

(CMP) Updates" RFC 9480 DOI 10.17487/RFC9480 <https://

www.rfc-editor.org/info/rfc9480>

Brockhaus, H. von Oheimb, D. S. Fries "Lightweight Certicate

Management Protocol (CMP) Prole" RFC 9483 DOI 10.17487/RFC9483

<https://www.rfc-editor.org/info/rfc9483>

Cooper, D. Santesson, S. Farrell, S. Boeyen, S. Housley, R. W. Polk

"Internet X.509 Public Key Infrastructure Certicate and Certicate Revocation

List (CRL) Prole" RFC 5280 DOI 10.17487/RFC5280 <https://www.rfc-

editor.org/info/rfc5280>

Bormann, C. Lemay, S. Tschofenig, H. Hartke, K. Silverajan, B. B. Raymor,

Ed. "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets"

RFC 8323 DOI 10.17487/RFC8323 <https://www.rfc-editor.org/

info/rfc8323>

Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.3" RFC 8446

DOI 10.17487/RFC8446 <https://www.rfc-editor.org/info/rfc8446>

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 8



The authors would like to thank , , and

for their guidance in writing the content of this document and providing valuable

feedback.

Hendrik Brockhaus David von Oheimb Andreas

Kretschmer



 

Palo Alto Networks

3000 Tannery Way

, Santa Clara CA 95054

United States of America

[email protected] Email:

 

Palo Alto Networks

3000 Tannery Way

, Santa Clara CA 95054

United States of America

[email protected] Email:

RFC 9482 CoAP Transfer for CMP November 2023

Sahni & Tripathi Standards Track Page 9