rfc9482.original   rfc9482.txt 
ACE M. Sahni, Ed. Internet Engineering Task Force (IETF) M. Sahni, Ed.
Internet-Draft S. Tripathi, Ed. Request for Comments: 9482 S. Tripathi, Ed.
Intended status: Standards Track Palo Alto Networks Category: Standards Track Palo Alto Networks
Expires: 16 November 2023 15 May 2023 ISSN: 2070-1721 October 2023
CoAP Transfer for the Certificate Management Protocol Constrained Application Protocol (CoAP) Transfer for the Certificate
draft-ietf-ace-cmpv2-coap-transport-10 Management Protocol
Abstract Abstract
This document specifies the use of Constrained Application Protocol This document specifies the use of the Constrained Application
(CoAP) as a transfer mechanism for the Certificate Management Protocol (CoAP) as a transfer mechanism for the Certificate
Protocol (CMP). CMP defines the interaction between various PKI Management Protocol (CMP). CMP defines the interaction between
entities for the purpose of certificate creation and management. various PKI entities for the purpose of certificate creation and
CoAP is an HTTP-like client-server protocol used by various management. CoAP is an HTTP-like client-server protocol used by
constrained devices in the IoT space. various constrained devices in the Internet of Things space.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 16 November 2023. 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.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. CoAP Transfer Mechanism for CMP . . . . . . . . . . . . . . . 3 2. CoAP Transfer Mechanism for CMP
2.1. CoAP URI Format . . . . . . . . . . . . . . . . . . . . . 3 2.1. CoAP URI Format
2.2. Discovery of CMP RA/CA . . . . . . . . . . . . . . . . . 4 2.2. Discovery of CMP RA/CA
2.3. CoAP Request Format . . . . . . . . . . . . . . . . . . . 4 2.3. CoAP Request Format
2.4. CoAP Block-Wise Transfer Mode . . . . . . . . . . . . . . 4 2.4. CoAP Block-Wise Transfer Mode
2.5. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . 5 2.5. Multicast CoAP
2.6. Announcement PKIMessage . . . . . . . . . . . . . . . . . 5 2.6. Announcement PKIMessage
3. Proxy Support . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Proxy Support
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References
7.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
1. Introduction 1. Introduction
The Certificate Management Protocol (CMP) [RFC4210] is used by the The Certificate Management Protocol (CMP) [RFC4210] is used by the
PKI entities for the generation and management of certificates. One PKI entities for the generation and management of certificates. One
of the requirements of Certificate Management Protocol is to be of the requirements of CMP is to be independent of the transport
independent of the transport protocol in use. CMP has mechanisms to protocol in use. CMP has mechanisms to take care of required
take care of required transactions, error reporting and protection of transactions, error reporting, and protection of messages.
messages.
The Constrained Application Protocol (CoAP) defined in [RFC7252], The Constrained Application Protocol (CoAP) defined in [RFC7252],
[RFC7959] and [RFC8323] is a client-server protocol like HTTP. It is [RFC7959], and [RFC8323] is a client-server protocol like HTTP. It
designed to be used by constrained devices over constrained networks. is designed to be used by constrained devices over constrained
The recommended transport for CoAP is UDP, however [RFC8323] networks. The recommended transport for CoAP is UDP; however,
specifies the support of CoAP over TCP, TLS and Websockets. [RFC8323] specifies the support of CoAP over TCP, TLS, and
WebSockets.
This document specifies the use of CoAP over UDP as a transport This document specifies the use of CoAP over UDP as a transport
medium for the CMP version 2 [RFC4210], CMP version 3 medium for CMP version 2 [RFC4210], CMP version 3 [RFC9480]
[I-D.ietf-lamps-cmp-updates] designated as CMP in this document and (designated as CMP in this document), and the Lightweight CMP Profile
Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. [RFC9483]. In general, this document follows the HTTP transfer for
This document, in general, follows the HTTP transfer for CMP CMP specifications defined in [RFC6712] and specifies the
specifications defined in [RFC6712] and specifies the requirements requirements for using CoAP as a transfer mechanism for CMP.
for using CoAP as a transfer mechanism for the CMP.
This document also provides guidance on how to use a "CoAP-to-HTTP" This document also provides guidance on how to use a "CoAP-to-HTTP"
proxy to ease adoption of CoAP transfer mechanism by enabling the proxy to ease adoption of a CoAP transfer mechanism by enabling the
interconnection with existing PKI entities already providing CMP over interconnection with existing PKI entities already providing CMP over
HTTP. HTTP.
1.1. Terminology 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. CoAP Transfer Mechanism for CMP 2. CoAP Transfer Mechanism for CMP
A CMP transaction consists of exchanging PKIMessages [RFC4210] A CMP transaction consists of exchanging PKIMessages [RFC4210]
between PKI End Entities (EEs), Registration Authorities (RAs), and between PKI end entities (EEs), registration authorities (RAs), and
Certification Authorities (CAs). If the EEs are constrained devices certification authorities (CAs). If the EEs are constrained devices,
then they may prefer, as a CMP client, the use of CoAP instead of then they may prefer, as a CMP client, the use of CoAP instead of
HTTP as the transfer mechanism. The RAs and CAs, in general, are not HTTP as the transfer mechanism. In general, the RAs and CAs are not
constrained and can support both CoAP and HTTP Client and Server constrained and can support both CoAP and HTTP client and server
implementations. This section specifies how to use CoAP as the implementations. This section specifies how to use CoAP as the
transfer mechanism for the Certificate Management Protocol. transfer mechanism for CMP.
2.1. CoAP URI Format 2.1. CoAP URI Format
The CoAP URI format is described in section 6 of [RFC7252]. The CoAP The CoAP URI format is described in Section 6 of [RFC7252]. The CoAP
endpoints MUST support use of the path prefix "/.well-known/" as endpoints MUST support use of the path prefix "/.well-known/" as
defined in [RFC8615] and the registered name "cmp" to help with defined in [RFC8615] and the registered name "cmp" to help with
endpoint discovery and interoperability. Optional path segments MAY endpoint discovery and interoperability. Optional path segments MAY
be added after the registered application name (i.e. after "/.well- be added after the registered application name (i.e., after "/.well-
known/cmp") to provide distinction. The path segment 'p' followed by known/cmp") to provide distinction. The path segment 'p' followed by
an arbitraryLabel <name> could for example support the an arbitraryLabel <name> could, for example, support the
differentiation of specific CAs or certificate profiles. Further differentiation of specific CAs or certificate profiles. Further
path segments, e.g., as specified in the Lightweight CMP Profile [I- path segments, for example, as specified in Lightweight CMP Profile
D.ietf-lamps-lightweight-cmp-profile], could indicate PKI management [RFC9483], could indicate PKI management operations using an
operations using an operationLabel <operation>. A valid full CMP URI operationLabel <operation>. A valid full CMP URI can look like this:
can look like this:
coap://www.example.com/.well-known/cmp coap://www.example.com/.well-known/cmp
coap://www.example.com/.well-known/cmp/<operation> 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>
coap://www.example.com/.well-known/cmp/p/<profileLabel>/<operation> coap://www.example.com/.well-known/cmp/p/<profileLabel>/<operation>
2.2. Discovery of CMP RA/CA 2.2. Discovery of CMP RA/CA
The EEs can be configured with enough information to form the CMP The EEs can be configured with enough information to form the CMP
server URI. The minimum information that can be configured is the server URI. The minimum information that can be configured is the
scheme i.e. "coap:" or "coaps:" and the authority portion of the URI, scheme, i.e., "coap:" or "coaps:", and the authority portion of the
e.g. "example.com:5683". If the port number is not specified in the URI, e.g., "example.com:5683". If the port number is not specified
authority, then the default ports numbers MUST be assumed for the in the authority, then the default port numbers MUST be assumed for
"coap:" and the "coaps:" scheme URIs. The default port for coap: the "coap:" and "coaps:" scheme URIs. The default port for "coap:"
scheme URIs is 5683 and the default port for coaps: scheme URIs is scheme URIs is 5683 and the default port for "coaps:" scheme URIs is
5684 [RFC7252]. 5684 [RFC7252].
Optionally, in the environments where a Local Registration Authority Optionally, in the environments where a Local RA or CA is deployed,
(LRA) or a Local CA is deployed, EEs can also use the CoAP service EEs can also use the CoAP service discovery mechanism [RFC7252] to
discovery mechanism [RFC7252] to discover the URI of the Local RA or discover the URI of the Local RA or CA. The CoAP CMP endpoints
CA. The CoAP CMP endpoints supporting service discovery MUST also supporting service discovery MUST also support resource discovery in
support resource discovery in the CoRE Link Format as described in the Constrained RESTful Environments (CoRE) Link Format, as described
[RFC6690]. The Link MUST include the 'ct' attribute defined in in [RFC6690]. The link MUST include the 'ct' attribute defined in
section 7.2.1 of [RFC7252] with the value of "application/pkixcmp" as Section 7.2.1 of [RFC7252] with the value of "application/pkixcmp",
defined in the CoAP Content-Formats IANA registry. as defined in the "CoAP Content-Formats" IANA registry.
2.3. CoAP Request Format 2.3. CoAP Request Format
The CMP PKIMessages MUST be DER encoded and sent as the body of the The CMP PKIMessages MUST be DER encoded and sent as the body of the
CoAP POST request. A CMP client MUST send each CoAP requests marked CoAP POST request. A CMP client MUST send each CoAP request marked
as a Confirmable message [RFC7252]. If the CoAP request is as a Confirmable message [RFC7252]. If the CoAP request is
successful then the CMP RA or CA MUST return a Success 2.xx response successful, then the CMP RA or CA MUST return a Success 2.xx response
code otherwise CMP RA or CA MUST return an appropriate Client Error code; otherwise, the CMP RA or CA MUST return an appropriate Client
4.xx or Server Error 5.xx response code. A CMP RA or CA may choose Error 4.xx or Server Error 5.xx response code. A CMP RA or CA may
to send a Piggybacked response [RFC7252] to the client or it MAY send choose to send a piggybacked response [RFC7252] to the client, or it
a Separate response [RFC7252] in case it takes some time for CA or RA MAY send a separate response [RFC7252] in case it takes some time for
to process the CMP transaction. the RA or CA to process the CMP transaction.
When transferring CMP PKIMesssage over CoAP the content-format When transferring CMP PKIMessage over CoAP, the content-format
"application/pkixcmp" MUST be used. "application/pkixcmp" MUST be used.
2.4. CoAP Block-Wise Transfer Mode 2.4. CoAP Block-Wise Transfer Mode
A CMP PKIMesssage consists of a header, body, protection, and A CMP PKIMessage consists of a header, body, protection, and
extraCerts structures which may contain many optional and potentially extraCerts structure, which may contain many optional and potentially
large fields. Thus, a CMP message can be much larger than the large fields. Thus, a CMP message can be much larger than the
Maximum Transmission Unit (MTU) of the outgoing interface of the Maximum Transmission Unit (MTU) of the outgoing interface of the
device. The EEs and RAs or CAs, MUST use the Block-Wise transfer device. The EEs and RAs or CAs MUST use the block-wise transfer mode
mode [RFC7959] to transfer such large messages instead of relying on [RFC7959] to transfer such large messages instead of relying on IP
IP fragmentation. fragmentation.
If a CoAP-to-HTTP proxy is in the path between EEs and CA or EEs and If a CoAP-to-HTTP proxy is in the path between EEs and an RA or EEs
RA then, if the server supports, it MUST use the chunked transfer and a CA and if the server supports, then it MUST use the chunked
encoding [RFC9112] to send data over the HTTP transport. The proxy transfer encoding [RFC9112] to send data over the HTTP transport.
MUST try to reduce the number of packets sent by using an optimal The proxy MUST try to reduce the number of packets sent by using an
chunk length for the HTTP transport. optimal chunk length for the HTTP transport.
2.5. Multicast CoAP 2.5. Multicast CoAP
CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination CMP PKIMessages sent over CoAP MUST NOT use a Multicast destination
address. address.
2.6. Announcement PKIMessage 2.6. Announcement PKIMessage
A CMP server may publish announcements, that can be event triggered A CMP server may publish announcements that can be triggered by an
or periodic, for the other PKI entities. Here is the list of CMP event or periodicly for the other PKI entities. Here is the list of
announcement messages prefixed by their respective ASN.1 identifier CMP announcement messages prefixed by their respective ASN.1
(section 5.1.2 [RFC4210]) identifier (see Section 5.1.2 of [RFC4210]):
[15] CA Key Update Announcement [15] CA Key Update Announcement
[16] Certificate Announcement [16] Certificate Announcement
[17] Revocation Announcement [17] Revocation Announcement
[18] CRL Announcement [18] CRL Announcement
An EE MAY use CoAP Observe option [RFC7641] to register itself to get An EE MAY use the CoAP Observe Option [RFC7641] to register itself to
any announcement messages from the RA or CA. The EE can send a GET get any announcement messages from the RA or CA. The EE can send a
request to the server's URI suffixed by "/ann". For example a path GET request to the server's URI suffixed by "/ann". For example, a
to register for announcement messages may look like this: path to register for announcement messages may look like this:
coap://www.example.com/.well-known/cmp/ann coap://www.example.com/.well-known/cmp/ann
coap://www.example.com/.well-known/cmp/p/<profileLabel>/ann coap://www.example.com/.well-known/cmp/p/<profileLabel>/ann
If the server supports CMP Announcements messages, then it MUST send If the server supports CMP announcement messages, then it MUST send
appropriate Success 2.xx response code, otherwise it MUST send an 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 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 for some reason the server cannot add the client to its list of
observers for the announcements, it can omit the Observe option observers for the announcements, it can omit the Observe Option
[RFC7641] in the response to the client. A client on receiving a [RFC7641] in the response to the client. Upon receiving a Success
2.xx success response without the Observe option [RFC7641] MAY try 2.xx response without the Observe Option [RFC7641], after some time,
after some time to register again for announcements from the CMP a client MAY try to register again for announcements from the CMP
server. Since server can remove the EE from the list of observers server. Since a server can remove the EE from the list of observers
for announcement messages, an EE SHOULD periodically re-register for announcement messages, an EE SHOULD periodically reregister
itself for announcement messages. itself for announcement messages.
Alternatively, an EE MAY periodically poll for the current status of Alternatively, an EE MAY periodically poll for the current status of
the CA via the "PKI Information Request" message, see section 6.5 of the CA via the "PKI Information Request" message; see Section 6.5 of
[RFC4210]. If supported, EEs MAY also use "Support Messages" defined [RFC4210]. If supported, EEs MAY also use "support messages" defined
in section 4.3 of Lightweight CMP Profile in Section 4.3 of Lightweight CMP Profile [RFC9483] to get
[I-D.ietf-lamps-lightweight-cmp-profile] to get information about the information about the CA status. These mechanisms will help
CA status. These mechanisms will help constrained devices, that are constrained devices that are acting as EEs to conserve resources by
acting as EEs, to conserve resources by eliminating the need to eliminating the need to create an endpoint for receiving
create an endpoint for receiving notifications from RA or CA. It notifications from the RA or CA. It will also simplify the
will also simplify the implementation of a CoAP-to-HTTP proxy. implementation of a CoAP-to-HTTP proxy.
3. Proxy Support 3. Proxy Support
This section provides guidance on using a CoAP-to-HTTP proxy between 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 EEs and RAs or CAs in order to avoid changes to the existing PKI
implementation. implementation.
Since CMP payload is the same over CoAP and HTTP transfer mechanisms, Since the CMP payload is the same over CoAP and HTTP transfer
a CoAP-to-HTTP cross-protocol proxy can be implemented based on mechanisms, a CoAP-to-HTTP cross-protocol proxy can be implemented
section 10 of [RFC7252]. The CoAP-to-HTTP proxy can either be based on Section 10 of [RFC7252]. The CoAP-to-HTTP proxy can either
located closer to the EEs or closer to the RA or CA. The proxy MAY be located closer to the EEs or closer to the RA or CA. The proxy
support service discovery and resource discovery as described in MAY support service discovery and resource discovery, as described in
section 2.2. The CoAP-to-HTTP proxy MUST function as a reverse Section 2.2. The CoAP-to-HTTP proxy MUST function as a reverse
proxy, only permitting connections to a limited set of pre-configured proxy, only permitting connections to a limited set of preconfigured
servers. It is out of scope of this document to specify how a servers. It is out of scope of this document to specify how a
reverse proxy can route CoAP client requests to one of the configured reverse proxy can route CoAP client requests to one of the configured
servers. Some recommended mechanisms are as follows: servers. Some recommended mechanisms are as follows:
* Use the Uri-Path option to identify a server. * Use the Uri-Path option to identify a server.
* Use separate hostnames for each of the configured servers and then * Use separate hostnames for each of the configured servers and then
use the Uri-Host option for routing the CoAP requests. use the Uri-Host option for routing the CoAP requests.
* Use separate hostnames for each of the configured servers and then * Use separate hostnames for each of the configured servers and then
use Server Name Indication [RFC8446] in case of "coaps://" scheme use Server Name Indication [RFC8446] in case of the "coaps://"
for routing CoAP requests. scheme for routing CoAP requests.
4. Security Considerations 4. Security Considerations
* If PKIProtection is used, the PKIHeader and PKIBody of the CMP * If PKIProtection is used, the PKIHeader and PKIBody of the CMP are
protocol are cryptographically protected against malicious cryptographically protected against malicious modifications. As
modifications. As such, UDP can be used without compromising the such, UDP can be used without compromising the security of the
security of the CMP protocol. Security Considerations for CoAP CMP. Security considerations for CoAP are defined in [RFC7252].
are defined in [RFC7252]. * The CMP does not provide confidentiality of the CMP payloads. If
confidentiality is desired, CoAP over DTLS [RFC9147] SHOULD be
* The CMP protocol does not provide confidentiality of the CMP used to provide confidentiality for the CMP payloads; although, it
payloads. If confidentiality is desired, CoAP over DTLS [RFC9147] cannot conceal that the CMP is used within the DTLS layer.
SHOULD be used to provide confidentiality for the CMP payloads,
although it cannot conceal that the CMP protocol is used within
the DTLS layer.
* Section 9.1 of [RFC7252] defines how to use DTLS [RFC9147] for * Section 9.1 of [RFC7252] defines how to use DTLS [RFC9147] for
securing the CoAP. DTLS [RFC9147] associations SHOULD be kept securing CoAP. DTLS [RFC9147] associations SHOULD be kept alive
alive and re-used where possible to amortize on the additional and reused where possible to amortize on the additional overhead
overhead of DTLS on constrained devices. of DTLS on constrained devices.
* An EE might not witness all of the Announcement messages when * An EE might not witness all of the announcement messages when
using the CoAP Observe option [RFC7641], since the Observe option using the CoAP Observe Option [RFC7641], since the Observe Option
is a "best-effort" approach and the server might lose its state is a "best-effort" approach and the server might lose its state
for subscribers to its announcement messages. The EEs may use an for subscribers to its announcement messages. The EEs may use an
alternate method described in section 2.6 to obtain time critical alternate method described in Section 2.6 to obtain time critical
changes such as CRL [RFC5280] updates. changes, such as Certificate Revocation List (CRL) [RFC5280]
updates.
* Implementations SHOULD use the available datagram size and avoid * Implementations SHOULD use the available datagram size and avoid
sending small datagrams containing partial CMP PKIMessage data in sending small datagrams containing partial CMP PKIMessage data in
order to reduce memory usage for packet buffering. order to reduce memory usage for packet buffering.
* A CoAP-to-HTTP proxy can also protect the PKI entities by handling * A CoAP-to-HTTP proxy can also protect the PKI entities by handling
UDP and CoAP messages. The proxy can mitigate attacks like denial UDP and CoAP messages. The proxy can mitigate attacks, like
of service attacks, replay attacks and resource-exhaustion attacks denial-of-service attacks, replay attacks, and resource-exhaustion
by enforcing basic checks like validating that the ASN.1 syntax is attacks, by enforcing basic checks, like validating that the ASN.1
compliant to CMP messages and validating the PKIMessage protection syntax is compliant to CMP messages and validating the PKIMessage
before sending them to PKI entities. protection before sending them to PKI entities.
* Since the Proxy may have access to the CMP-Level metadata and * Since the proxy may have access to the CMP-level metadata and
control over the flow of CMP messages therefore proper role based control over the flow of CMP messages, proper role-based access
access control should be in place. The proxy can be deployed at control should be in place. The proxy can be deployed at the edge
the edge of the "End Entities" network or in front of an RA and CA of the "end entities" network or in front of an RA and CA to
to protect them. The proxy however may itself be vulnerable to protect them. However, the proxy may itself be vulnerable to
resource-exhaustion attacks as it's required to buffer the CMP resource-exhaustion attacks as it's required to buffer the CMP
messages received over CoAP transport before sending it to the messages received over CoAP transport before sending it to the
HTTP endpoint. This can be mitigated by using short timers for HTTP endpoint. This can be mitigated by using short timers for
discarding the buffered messages and rate limiting clients based discarding the buffered messages and rate limiting clients based
on the resource usage. on the resource usage.
5. IANA Considerations 5. IANA Considerations
This document adds a new entry to the CoAP Content-Formats IANA IANA has registered "application/pkixcmp" (ID 259) in the "CoAP
Registry (https://www.iana.org/assignments/core-parameters/core- Content-Formats" registry <https://www.iana.org/assignments/core-
parameters.xhtml#content-formats) for the code of content-type parameters> to transfer CMP transactions over CoAP.
"application/pkixcmp", for transferring CMP transactions over CoAP,
from the identifier range 256-9999 reserved for IETF specifications.
Type name: application
Subtype name: pkixcmp
Encoding: Content may contain arbitrary octet values. The octet
values are the ASN.1 DER encoding of a PKI message, as defined in the
[RFC4210] specifications.
Reference: This document and [RFC4210]
This document also adds a new path segment "ann" to the CMP Well-
Known URI Path Segments (https://www.iana.org/assignments/cmp/
cmp.xhtml#cmp-well-known-uri) IANA registry for the EEs to register
themselves for the announcement messages.
Path Segment: ann
Description: The path to send a GET request with CoAP Observer Option
to register for CMP announcement messages.
Reference: This document.
This document references the cmp, in the Well-Known URIs Type name: application
(https://www.iana.org/assignments/well-known-uris/well-known- Subtype name: pkixcmp
uris.xhtml) IANA registry. Please add a reference of this document Reference: RFC 9482 [RFC4210]
to the Well-Known URIs (https://www.iana.org/assignments/well-known-
uris/well-known-uris.xhtml) IANA registry for that entry.
This document also refers the path segment "p" in the CMP Well-Known IANA has also registered a new path segment "ann" in the "CMP Well-
URI Path Segments (https://www.iana.org/assignments/cmp/ Known URI Path Segments" registry <https://www.iana.org/assignments/
cmp.xhtml#cmp-well-known-uri) IANA registry. Please add a reference cmp> for the EEs to register themselves for the announcement
of this document to the CMP Well-Known URI Path Segments messages.
(https://www.iana.org/assignments/cmp/cmp.xhtml#cmp-well-known-uri)
for that path segment.
[Note RFC Editor]: This document should be published together or Path Segment: ann
after the CMP version 3 [I-D.ietf-lamps-cmp-updates] as it references Description: The path to send a GET request with the CoAP Observe
IANA entries created by that Internet draft. Option to register for CMP announcement messages.
Reference: RFC 9482
6. Acknowledgments IANA has added this document as a reference for the "cmp" entry in
the "Well-Known URIs" registry <https://www.iana.org/assignments/
well-known-uris>.
The authors would like to thank Hendrik Brockhaus, David von Oheimb, IANA has also added this document as a reference for the "p" entry in
and Andreas Kretschmer for their guidance in writing the content of the "CMP Well-Known URI Path Segments" registry
this document and providing valuable feedback. <https://www.iana.org/assignments/cmp/>.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, "Internet X.509 Public Key Infrastructure Certificate
May 2017, <https://www.rfc-editor.org/info/rfc8174>. Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712, Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012, DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>. <https://www.rfc-editor.org/info/rfc6712>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[I-D.ietf-lamps-cmp-updates] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Management Protocol (CMP) Updates", Work in Progress, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Internet-Draft, draft-ietf-lamps-cmp-updates-23, 29 June
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cmp-updates-23>.
[I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", Work in
Progress, Internet-Draft, draft-ietf-lamps-lightweight-
cmp-profile-21, 17 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
lightweight-cmp-profile-21>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>. <https://www.rfc-editor.org/info/rfc8615>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
<https://www.rfc-editor.org/info/rfc6690>. June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>. <https://www.rfc-editor.org/info/rfc9147>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9480] Brockhaus, H., Ed., von Oheimb, D., and J. Gray,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, "Certificate Management Protocol (CMP) Updates", RFC 9480,
June 2022, <https://www.rfc-editor.org/info/rfc9112>. DOI 10.17487/RFC9480, October 2023,
<https://www.rfc-editor.org/info/rfc9480>.
7.2. Informative References [RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, October 2023,
<https://www.rfc-editor.org/info/rfc9483>.
6.2. Informative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
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 Authors' Addresses
Mohit Sahni (editor) Mohit Sahni (editor)
Palo Alto Networks Palo Alto Networks
3000 Tannery Way 3000 Tannery Way
Santa Clara, CA 95054 Santa Clara, CA 95054
United States of America United States of America
Email: msahni@paloaltonetworks.com Email: msahni@paloaltonetworks.com
Saurabh Tripathi (editor) Saurabh Tripathi (editor)
Palo Alto Networks Palo Alto Networks
3000 Tannery Way 3000 Tannery Way
Santa Clara, CA 95054 Santa Clara, CA 95054
United States of America United States of America
Email: stripathi@paloaltonetworks.com Email: stripathi@paloaltonetworks.com
 End of changes. 58 change blocks. 
256 lines changed or deleted 228 lines changed or added

This html diff was produced by rfcdiff 1.48.