RFC 9482

Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol

📅 published November 2023, from ietf

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

okay bestie, settle in because this one is a whole vibe 💅✨

Here's the title block tea ☕: this doc is RFC 9482, published in November 2023 as a Standards Track document, which means it's the real deal and not just a suggestion 👑. The editors are M. Sahni and S. Tripathi (both listed as "Ed.", so they're the editors who pulled it all together) 🫶, and they're from Palo Alto Networks. It's part of the ISSN: 2070-1721 series. It doesn't say it obsoletes or updates anything, so it's standing on its own 🦋.

Also, the title is giving "CoAP meets CMP," and I am here for the crossover 🧚💜

Abstract

So the big idea is that this doc explains how to use CoAP (the Constrained Application Protocol) as a transfer mechanism for CMP (the Certificate Management Protocol) 🔥. CMP is how different PKI entities talk to each other to create and manage certificates 🔐. CoAP is basically HTTP's cute, lightweight cousin that constrained IoT devices use 🌸. The whole point is getting these two to work together, no cap ✨.

Status of This Memo

Okay so this is an Internet Standards Track document 💖. It's a product of the IETF and has the consensus of the IETF community, plus it got public review and was approved by the IESG 🎀. If you want more info on Internet Standards, check Section 2 of RFC 7841 🦋. The current status, errata, and feedback stuff lives at https://www.rfc-editor.org/info/rfc9482 🌈.

Copyright (c) 2023 IETF Trust and the document authors, all rights reserved 💅. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date 📜. Read those carefully, because they spell out your rights and restrictions 🙈. If you pull Code Components out of this document, they have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 🫶.

Table of Contents

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

1. Introduction ✨

CMP ([RFC4210]) is what PKI entities use to generate and manage certificates 🔐. One of its big requirements is that it doesn't care which transport protocol you use 🦋. It also has built-in mechanisms for handling required transactions, error reporting, and protecting messages 💜.

CoAP is defined in [RFC7252], [RFC7959], and [RFC8323] 🌸. It's a client-server protocol, kinda like HTTP, and it's designed for constrained devices running on constrained networks 🧚. The recommended transport for CoAP is UDP 💅, but [RFC8323] also covers CoAP over TCP, TLS, and WebSockets 🌈.

This document is about using CoAP over UDP as the transport for CMP version 2 [RFC4210], CMP version 3 [RFC9480] (which is just "CMP" in this doc 💖), and the Lightweight CMP Profile [RFC9483] ✨. Generally, it follows the HTTP transfer for CMP specs in [RFC6712] and lays out the requirements for using CoAP as the CMP transfer mechanism 🎀.

It also gives guidance on using a "CoAP-to-HTTP" proxy 🦋. This helps folks adopt CoAP without ditching the PKI entities that already speak CMP over HTTP, since the proxy connects the two worlds 🫶.

1.1. Requirements Language

Okay, this part is super important 🙈. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like this 💅. Anything lowercase is just regular English 💖.

2. CoAP Transfer Mechanism for CMP 🌸

A CMP transaction is basically a bunch of PKIMessages [RFC4210] getting swapped between PKI end entities (EEs), registration authorities (RAs), and certification authorities (CAs) 🔥. If the EEs are constrained devices, they may prefer to use CoAP instead of HTTP as the transfer mechanism when they act as a CMP client 🧚. Generally, RAs and CAs aren't constrained, so they can handle both CoAP and HTTP, as client or server 💜. This section explains how to use CoAP for CMP 🎀.

2.1. CoAP URI Format ✨

The CoAP URI format is in Section 6 of [RFC7252] 🦋. CoAP endpoints MUST support the path prefix "/.well-known/" from [RFC8615] along with the registered name "cmp" 💖. That helps with endpoint discovery and interoperability 🫶. You MAY add optional path segments after the registered application name (so, after "/.well-known/cmp") to tell things apart 🌈. For example, the path segment 'p' followed by an arbitraryLabel <name> could help tell specific CAs or certificate profiles apart 💅. More path segments, like the ones in the Lightweight CMP Profile [RFC9483], can name PKI management operations using an operationLabel <operation> 🧚. Here's what a valid full CMP URI can look like 👑:

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>

2.2. Discovery of CMP RA/CA 🔍

EEs can be set up with enough info to build the CMP server URI 🎀. The bare minimum is the scheme, which is "coap:" or "coaps:", plus the authority part, like "example.com:5683" 💖. If the port isn't in the authority, the default port numbers MUST be assumed for "coap:" and "coaps:" URIs 🦋. The default port for "coap:" is 5683, and for "coaps:" it's 5684 [RFC7252] 🌸.

Optionally, if a Local RA or CA is deployed, EEs can use the CoAP service discovery mechanism [RFC7252] to find the URI of that Local RA or CA 🧚. CoAP CMP endpoints that support service discovery MUST also support resource discovery in the Constrained RESTful Environments (CoRE) Link Format, as described in [RFC6690] 💅. The link MUST include the 'ct' attribute from Section 7.2.1 of [RFC7252], with the value "application/pkixcmp", as defined in the "CoAP Content-Formats" IANA registry 🫶.

2.3. CoAP Request Format 📮

CMP PKIMessages MUST be DER encoded and sent as the body of a CoAP POST request 💖. A CMP client MUST send each CoAP request as a Confirmable message [RFC7252] 🔥. If the CoAP request works, the CMP RA or CA MUST return a Success 2.xx response code 🎀. If it doesn't, the CMP RA or CA MUST return an appropriate Client Error 4.xx or Server Error 5.xx response code 🙈. A CMP RA or CA MAY send a piggybacked response [RFC7252] to the client 🦋. Or it MAY send a separate response [RFC7252] if it takes a while to process the CMP transaction ⏳.

When you transfer a CMP PKIMessage over CoAP, the content-format "application/pkixcmp" MUST be used 💜.

2.4. CoAP Block-Wise Transfer Mode 🧩

A CMP PKIMessage has a header, body, protection, and extraCerts structure, and it can include lots of optional and potentially big fields 🌈. So a CMP message can end up way bigger than the MTU of the device's outgoing interface 😭. The EEs, RAs, and CAs MUST use the block-wise transfer mode [RFC7959] for big messages, instead of leaning on IP fragmentation 💅.

If a CoAP-to-HTTP proxy sits in the path between EEs and an RA, or between EEs and a CA, and the server supports it, the proxy MUST use chunked transfer encoding [RFC9112] to send data over HTTP 🧚. The proxy MUST also try to cut down on the number of packets by picking an optimal chunk length for the HTTP transport 🫶.

2.5. Multicast CoAP 🚫

CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination address 🙅‍♀️.

2.6. Announcement PKIMessage 📣

A CMP server can publish announcements, either because of an event or on a schedule, for the other PKI entities 🎀. Here's the list of CMP announcement messages, each with its ASN.1 identifier (see Section 5.1.2 of [RFC4210]) 💖:

[15] CA Key Update Announcement
[16] Certificate Announcement
[17] Revocation Announcement
[18] CRL Announcement

An EE MAY use the CoAP Observe Option [RFC7641] to sign itself up for announcement messages from the RA or CA 🦋. It can send a GET request to the server's URI with "/ann" added on the end 🌸. For example, the path to register for announcements might look like this 🧚:

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

If the server supports CMP announcement messages, it MUST send an appropriate Success 2.xx response code 💅. Otherwise, it MUST send an appropriate Client Error 4.xx or Server Error 5.xx response code 🙈. If for some reason the server can't add the client to its list of observers for announcements, it MAY leave out the Observe Option [RFC7641] in the response to the client 🫶. If a client gets a Success 2.xx response without the Observe Option [RFC7641], it MAY try to register for announcements from the CMP server again after some time 🔁. The server can remove an EE from its observer list, so an EE SHOULD periodically re-register for announcement messages 💖.

Alternatively, an EE MAY periodically poll the CA's current status with the "PKI Information Request" message (see Section 6.5 of [RFC4210]) 🌈. If it's supported, EEs MAY also use the "support messages" from Section 4.3 of the Lightweight CMP Profile [RFC9483] to get CA status info 💜. These approaches help constrained devices acting as EEs save resources, since they don't have to set up an endpoint to receive notifications from the RA or CA ✨. They also make a CoAP-to-HTTP proxy simpler to build 🎀.

3. Proxy Support 🌉

This section explains how to use a CoAP-to-HTTP proxy between EEs and RAs or CAs, so you don't have to change the existing PKI implementation 🦋.

Since the CMP payload is the same over CoAP and HTTP, a CoAP-to-HTTP cross-protocol proxy can be built based on Section 10 of [RFC7252] 💖. The proxy can sit closer to the EEs or closer to the RA or CA 🫶. The proxy MAY support service discovery and resource discovery, as described in Section 2.2 💅. The CoAP-to-HTTP proxy MUST work as a reverse proxy, only allowing connections to a limited set of preconfigured servers 🔒. How a reverse proxy routes CoAP client requests to one of those configured servers is out of scope for this document 🙈. Some recommended mechanisms are:

  • Use the Uri-Path option to identify a server.
  • Use separate hostnames for each configured server, then use the Uri-Host option to route CoAP requests.
  • Use separate hostnames for each configured server, then use Server Name Indication [RFC8446] for the "coaps://" scheme to route CoAP requests.

Part 1 done, bestie! 🧚 More is coming, so stay tuned 💖

4. Security Considerations ✨

  • okay so, if PKIProtection is used, the PKIHeader and PKIBody of the CMP are cryptographically protected against malicious modifications 🔐. That means UDP can be used without compromising the security of the CMP 💅. Security considerations for CoAP are defined in [RFC7252].
  • The CMP does not provide confidentiality of the CMP payloads 😭. If confidentiality is desired, CoAP over DTLS [RFC9147] SHOULD be used to provide confidentiality for the CMP payloads. Even so, it cannot conceal that the CMP is used within the DTLS layer 🙈.
  • Section 9.1 of [RFC7252] explains how to use DTLS [RFC9147] for securing CoAP 🧚. DTLS [RFC9147] associations SHOULD be kept alive and reused where possible, to amortize the additional overhead of DTLS on constrained devices. Main character energy for those tiny devices 🫶.
  • An EE might not witness all of the announcement messages when using the CoAP Observe Option [RFC7641]. The Observe Option is a "best-effort" 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 Certificate Revocation List (CRL) [RFC5280] updates.
  • Implementations SHOULD use the available datagram size and avoid sending small datagrams containing partial CMP PKIMessage data. This keeps memory usage for packet buffering down 🧠✨.
  • 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. Those checks include 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 flow 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 buffer the CMP messages received over CoAP transport before sending them to the HTTP endpoint 😱. This can be mitigated by using short timers for discarding the buffered messages and rate limiting clients based on the resource usage. Literally the most dramatic plot twist of the whole spec 🎭.

5. IANA Considerations 🎀

IANA has registered "application/pkixcmp" (ID 259) in the "CoAP Content-Formats" registry at https://www.iana.org/assignments/core-parameters to transfer CMP transactions over CoAP 🦋.

Type name:  application
Subtype name:  pkixcmp
Reference:  RFC 9482 [RFC4210]

IANA has also registered a new path segment "ann" in the "CMP Well-Known URI Path Segments" registry at https://www.iana.org/assignments/cmp. This is so the EEs can register themselves for the announcement messages 📣.

Path Segment:  ann
Description:  The path to send a GET request with the CoAP Observe
      Option to register for CMP announcement messages.
Reference:  RFC 9482

IANA has added this document as a reference for the "cmp" entry in the "Well-Known URIs" registry at https://www.iana.org/assignments/well-known-uris. Iconic paperwork moment 📄💅.

IANA has also added this document as a reference for the "p" entry in the "CMP Well-Known URI Path Segments" registry at https://www.iana.org/assignments/cmp/ 🌸.

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 💜

The authors 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 🫶🌈.

Authors' Addresses 🦋

Mohit Sahni (editor)
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
United States of America
Email: msahni@paloaltonetworks.com
Saurabh Tripathi (editor)
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
United States of America
Email: stripathi@paloaltonetworks.com
📦 where this page comes from