rfc9482xml2.original.xml   rfc9482.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- change the "txt" on the previous line to "xml" to make this a valid XML2RFC
template -->
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC4210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.4210.xml">
<!ENTITY RFC6712 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.6712.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.7252.xml">
<!ENTITY RFC7959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.7959.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.8446.xml">
<!ENTITY RFC8323 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.8323.xml">
<!ENTITY RFC8615 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.8615.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.6690.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.5280.xml">
<!ENTITY RFC7641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.7641.xml">
<!ENTITY RFC9147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.9147.xml">
<!ENTITY RFC9112 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refere
nce.RFC.9112.xml">
<!ENTITY I-D.ietf-lamps-lightweight-cmp-profile SYSTEM "http://xml.resour
ce.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lamps-lightweight-cmp-profile
-21.xml">
<!ENTITY I-D.ietf-lamps-cmp-updates SYSTEM "http://xml.resource.org/publi
c/rfc/bibxml3/reference.I-D.draft-ietf-lamps-cmp-updates-23.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-ietf-ace-cmpv2-coap-transport-10" ipr="trust2
00902">
<front>
<title abbrev="CoAP Transfer for the CMP">CoAP Transfer for the C
ertificate Management Protocol</title>
<author fullname="Mohit Sahni" initials="M" role="editor" surname
="Sahni">
<organization>Palo Alto Networks</organization>
<address>
<postal>
<street>3000 Tannery Way</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>
<email>msahni@paloaltonetworks.com</email>
</address>
</author>
<author fullname="Saurabh Tripathi" initials="S" role="editor" su
rname="Tripathi">
<organization>Palo Alto Networks</organization>
<address>
<postal>
<street>3000 Tannery Way</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>
<email>stripathi@paloaltonetworks.com</email>
</address>
</author>
<!-- month and day will be generated automatically by XML2RFC;
be sure the year is current.-->
<date year="2023" />
<!-- IETF area is optional -->
<area>Authentication and Authorization for Constrained Environmen
ts</area>
<!--WG name at the upperleft corner of the doc, <!DOCTYPE rfc [
IETF is fine for non-WG IETF submissions --> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<workgroup>ACE</workgroup> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-ace-cmpv2-coap-transport-10" number="9 482" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" s ymRefs="true" sortRefs="true" version="3">
<!--add additional keywords here for IETF website search engine - <!-- xml2rfc v2v3 conversion 3.17.1 -->
-> <front>
<title abbrev="CoAP Transfer for CMP">Constrained Application Protocol (CoAP
) Transfer for the Certificate Management Protocol</title>
<seriesInfo name="RFC" value="9482"/>
<author fullname="Mohit Sahni" initials="M" role="editor" surname="Sahni">
<organization>Palo Alto Networks</organization>
<address>
<postal>
<street>3000 Tannery Way</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>United States of America</country>
</postal>
<email>msahni@paloaltonetworks.com</email>
</address>
</author>
<author fullname="Saurabh Tripathi" initials="S" role="editor" surname="Trip
athi">
<organization>Palo Alto Networks</organization>
<address>
<postal>
<street>3000 Tannery Way</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>United States of America</country>
</postal>
<email>stripathi@paloaltonetworks.com</email>
</address>
</author>
<date year="2023" month="October"/>
<area>sec</area>
<workgroup>ace</workgroup>
<abstract> <abstract>
<t>
<t> This document specifies the use of the Co
This document specifies the use of Constr nstrained Application Protocol (CoAP) as a transfer mechanism for the Certificat
ained Application Protocol (CoAP) as a transfer mechanism for the Certificate Ma e Management Protocol (CMP). CMP defines the interaction between various PKI ent
nagement Protocol (CMP). CMP defines the interaction between various PKI entitie ities for the purpose of certificate creation and management. CoAP is an HTTP-li
s for the purpose of certificate creation and management. CoAP is an HTTP-like c ke client-server protocol used by various constrained devices in the Internet of
lient-server protocol used by various constrained devices in the IoT space. Things space.
</t> </t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"> <t>
<t>
The Certificate Management Protocol (CMP) The Certificate Management Protocol (CMP)
<xref target="RFC4210" /> <xref target="RFC4210" format="default"/>
is used by the PKI entities for the generation an is used by the PKI entities for the generation an
d management of certificates. One of the requirements of Certificate Management d management of certificates. One of the requirements of CMP is to be independen
Protocol is to be independent of the transport protocol in use. CMP has mechanis t of the transport protocol in use. CMP has mechanisms to take care of required
ms to take care of required transactions, error reporting and protection of mess transactions, error reporting, and protection of messages.
ages. </t>
</t> <t>
<t> The Constrained Application Protocol (CoAP) defin
The Constrained Application Protocol (CoAP) defin ed in <xref target="RFC7252" format="default"/>, <xref target="RFC7959" format="
ed in <xref target="RFC7252" />, <xref target="RFC7959" /> and <xref target="RFC default"/>, and <xref target="RFC8323" format="default"/> is a client-server pro
8323" /> is a client-server protocol like HTTP. It is designed to be used by con tocol like HTTP. It is designed to be used by constrained devices over constrain
strained devices over constrained networks. The recommended transport for CoAP i ed networks. The recommended transport for CoAP is UDP; however, <xref target="R
s UDP, however <xref target="RFC8323" /> specifies the support of CoAP over TCP, FC8323" format="default"/> specifies the support of CoAP over TCP, TLS, and WebS
TLS and Websockets. ockets.
</t> </t>
<t> <t>
This document specifies the use of CoAP over UDP This document specifies the use of CoAP over UDP
as a transport medium for the CMP version 2 as a transport medium for
<xref target="RFC4210" />, <xref target="I-D.ietf <xref target="RFC4210" format="default">CMP versi
-lamps-cmp-updates"> CMP version 3 </xref> designated as CMP in this document an on 2</xref>, <xref target="RFC9480" format="default"> CMP version 3 </xref> (des
d <xref target="I-D.ietf-lamps-lightweight-cmp-profile">Lightweight CMP Profile< ignated as CMP in this document), and the <xref target="RFC9483" format="default
/xref>. This document, in general, follows the HTTP transfer for CMP specificati ">Lightweight CMP Profile</xref>. In general, this document follows the HTTP tra
ons defined in <xref target="RFC6712" /> and specifies the requirements for usin nsfer for CMP specifications defined in <xref target="RFC6712" format="default"/
g CoAP as a transfer mechanism for the CMP. > and specifies the requirements for using CoAP as a transfer mechanism for CMP.
</t> </t>
<t> <t>
This document also provides guidance on how to use a "CoAP-to-HTTP" proxy to eas This document also provides guidance on how to use a "CoAP-to-HTTP" proxy to eas
e adoption of CoAP transfer mechanism by enabling the interconnection with exist e adoption of a CoAP transfer mechanism by enabling the interconnection with exi
ing PKI entities already providing CMP over HTTP. sting PKI entities already providing CMP over HTTP.
</t> </t>
<section title="Terminology"> <section numbered="true" toc="default">
<t> <name>Requirements Language</name>
The key words "MUST", "MUST NOT", "REQUIR <t>
ED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",and "OPTIONAL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC2119" /> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC8174" /> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, and only when, they appear in all c be interpreted as
apitals, as shown here. described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</t> when, and only when, they appear in all capitals, as shown here.
</section> </t>
</section> </section>
<section title="CoAP Transfer Mechanism for CMP" anchor="sect-2"> </section>
<t> <section anchor="sect-2" numbered="true" toc="default">
<name>CoAP Transfer Mechanism for CMP</name>
<t>
A CMP transaction consists of exchanging PKIMessa ges A CMP transaction consists of exchanging PKIMessa ges
<xref target="RFC4210" /> <xref target="RFC4210" format="default"/>
between PKI End Entities (EEs), Registration Auth between PKI end entities (EEs), registration auth
orities (RAs), and Certification Authorities (CAs). If the EEs are constrained d orities (RAs), and certification authorities (CAs). If the EEs are constrained d
evices then they may prefer, as a CMP client, the use of CoAP instead of HTTP as evices, then they may prefer, as a CMP client, the use of CoAP instead of HTTP a
the transfer mechanism. s the transfer mechanism.
The RAs and CAs, in general, are not constrained In general, the RAs and CAs are not constrained a
and can support both CoAP and HTTP Client and Server implementations. nd can support both CoAP and HTTP client and server implementations.
This section specifies how to use CoAP as the tra This section specifies how to use CoAP as the tra
nsfer mechanism for the Certificate Management Protocol. nsfer mechanism for CMP.
</t> </t>
<section title="CoAP URI Format" anchor="sect-2.1"> <section anchor="sect-2.1" numbered="true" toc="default">
<t> <name>CoAP URI Format</name>
The CoAP URI format is described in secti <t>
on 6 of <xref target="RFC7252" />. The CoAP endpoints MUST support use of the pa The CoAP URI format is described in <xref
th prefix "/.well-known/" as defined in target="RFC7252" section="6" sectionFormat="of" format="default"/>. The CoAP en
<xref target="RFC8615" /> dpoints <bcp14>MUST</bcp14> support use of the path prefix "/.well-known/" as de
and the registered name "cmp" to help wit fined in
h endpoint discovery and interoperability. Optional path segments MAY be added a <xref target="RFC8615" format="default"/>
fter the registered application name (i.e. after "/.well-known/cmp") to provide and the registered name "cmp" to help wit
distinction. The path h endpoint discovery and interoperability. Optional path segments <bcp14>MAY</bc
segment 'p' followed by an arbitraryLabel p14> be added after the registered application name (i.e., after "/.well-known/c
&lt;name&gt; could for example support the differentiation of specific CAs or mp") to provide distinction. The path
certificate profiles. Further path segments, e.g., as specified in the Lightweig segment 'p' followed by an arbitraryLabel
ht CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], could indicate PKI mana &lt;name&gt; could, for example, support the differentiation of specific CAs o
gement operations using an operationLabel &lt;operation&gt;. A valid full CMP UR r certificate profiles. Further path segments, for example, as specified in <xre
I can look like this: f target="RFC9483">Lightweight CMP Profile</xref>, could indicate PKI management
</t> operations using an operationLabel &lt;operation&gt;. A valid full CMP URI can
<figure> look like this:
<artwork> </t>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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>
]]> ]]></artwork>
</artwork> </section>
</figure> <section anchor="sect-2.2" numbered="true" toc="default">
</section> <name>Discovery of CMP RA/CA</name>
<section title="Discovery of CMP RA/CA" anchor="sect-2.2" <t>
> The EEs can be configured with enough inf
<t> ormation to form the CMP server URI. The minimum information that can be configu
The EEs can be configured with enough inf red is the scheme, i.e., "coap:" or "coaps:", and the authority portion of the U
ormation to form the CMP server URI. The minimum information that can be configu RI, e.g., "example.com:5683". If the port number is not specified in the authori
red is the scheme i.e. "coap:" or "coaps:" and the authority portion of the URI, ty, then the default port numbers <bcp14>MUST</bcp14> be assumed for the "coap:"
e.g. "example.com:5683". If the port number is not specified in the authority, and "coaps:" scheme URIs. The default port for "coap:" scheme URIs is 5683 and
then the default ports numbers MUST be assumed for the "coap:" and the "coaps:" the default port for "coaps:" scheme URIs is 5684 <xref target="RFC7252" format=
scheme URIs. The default port for coap: scheme URIs is 5683 and the default port "default"/>.
for coaps: scheme URIs is 5684 <xref target="RFC7252" />. </t>
</t> <t>
<t> Optionally, in the environments where a L
Optionally, in the environments where a L ocal RA or CA is deployed, EEs can also use the CoAP service discovery mechanism
ocal Registration Authority (LRA) or a Local CA is deployed, EEs can also use th <xref target="RFC7252" format="default"/> to discover the URI of the Loca
e CoAP service discovery mechanism <xref target="RFC7252" /> to discover the l RA or CA. The CoAP CMP endpoints supporting service discovery <bcp14>MUST</bcp
URI of the Local RA or CA. The CoAP CMP endpoints supporting service discovery 14> also support resource discovery in the Constrained RESTful Environments (CoR
MUST also support resource discovery in the CoRE Link Format as described in <xr E) Link Format, as described in <xref target="RFC6690" format="default"/>. The l
ef target="RFC6690" />. The Link MUST include the 'ct' attribute defined in sect ink <bcp14>MUST</bcp14> include the 'ct' attribute defined in <xref target="RFC7
ion 7.2.1 of 252" section="7.2.1" sectionFormat="of" format="default"/> with the value of "ap
<xref target="RFC7252" /> with the value plication/pkixcmp", as defined in the "CoAP Content-Formats" IANA registry.
of "application/pkixcmp" as defined in the CoAP Content-Formats IANA registry. </t>
</t> </section>
</section> <section anchor="sect-2.3" numbered="true" toc="default">
<section title="CoAP Request Format" anchor="sect-2.3"> <name>CoAP Request Format</name>
<t> <t>
The CMP PKIMessages MUST be DER encoded a The CMP PKIMessages <bcp14>MUST</bcp14> b
nd sent as the body of the CoAP POST request. A CMP client MUST send each CoAP r e DER encoded and sent as the body of the CoAP POST request. A CMP client <bcp14
equests marked as a Confirmable message <xref target="RFC7252" />. If the CoAP r >MUST</bcp14> send each CoAP request marked as a Confirmable message <xref targe
equest is successful then the CMP RA or CA MUST return a Success 2.xx response c t="RFC7252" format="default"/>. If the CoAP request is successful, then the CMP
ode otherwise CMP RA or CA MUST return an appropriate Client Error 4.xx or Serve RA or CA <bcp14>MUST</bcp14> return a Success 2.xx response code; otherwise, the
r Error 5.xx response code. A CMP RA or CA may choose to send a Piggybacked resp CMP RA or CA <bcp14>MUST</bcp14> return an appropriate Client Error 4.xx or Ser
onse <xref target="RFC7252" /> to the client or it MAY send a Separate response ver Error 5.xx response code. A CMP RA or CA may choose to send a piggybacked re
<xref target="RFC7252" /> in case it takes some time for CA or RA to process the sponse <xref target="RFC7252" format="default"/> to the client, or it <bcp14>MAY
CMP transaction. </bcp14> send a separate response <xref target="RFC7252" format="default"/> in c
</t> ase it takes some time for the RA or CA to process the CMP transaction.
<t> </t>
When transferring CMP PKIMesssage over CoAP the conte <t>
nt-format "application/pkixcmp" MUST be used. When transferring CMP PKIMessage over CoAP, the conte
</t> nt-format "application/pkixcmp" <bcp14>MUST</bcp14> be used.
</section> </t>
<section title="CoAP Block-Wise Transfer Mode" anchor="se </section>
ct-2.4"> <section anchor="sect-2.4" numbered="true" toc="default">
<t> <name>CoAP Block-Wise Transfer Mode</name>
A CMP PKIMesssage consists of a header, b <t>
ody, protection, and extraCerts structures which may contain many optional and p A CMP PKIMessage consists of a header, bo
otentially large fields. Thus, a CMP message can be much larger than the Maximum dy, protection, and extraCerts structure, which may contain many optional and po
Transmission Unit (MTU) of the outgoing interface of the device. The EEs and RA tentially large fields. Thus, a CMP message can be much larger than the Maximum
s or CAs, MUST use the Block-Wise transfer mode Transmission Unit (MTU) of the outgoing interface of the device. The EEs and RAs
<xref target="RFC7959" /> to transfer suc or CAs <bcp14>MUST</bcp14> use the block-wise transfer mode
h large messages instead of relying on IP fragmentation. <xref target="RFC7959" format="default"/>
</t> to transfer such large messages instead of relying on IP fragmentation.
<t> </t>
If a CoAP-to-HTTP proxy is in the path be <t>
tween EEs and CA or EEs and RA then, if the server supports, it MUST use the chu If a CoAP-to-HTTP proxy is in the path be
nked transfer encoding <xref target="RFC9112" /> to send data over the HTTP tran tween EEs and an RA or EEs and a CA and if the server supports, then it <bcp14>M
sport. The proxy MUST try to reduce the number of packets sent by using an optim UST</bcp14> use the chunked transfer encoding <xref target="RFC9112" format="def
al chunk length for the HTTP transport. ault"/> to send data over the HTTP transport. The proxy <bcp14>MUST</bcp14> try
</t> to reduce the number of packets sent by using an optimal chunk length for the HT
</section> TP transport.
<section title="Multicast CoAP" anchor="sect-2.5"> </t>
<t> </section>
CMP PKIMessages sent over CoAP MUST NOT use a Multicast desti <section anchor="sect-2.5" numbered="true" toc="default">
nation address. <name>Multicast CoAP</name>
</t> <t>
</section> CMP PKIMessages sent over CoAP <bcp14>MUST NOT</bcp14> use a
Multicast destination address.
<section title="Announcement PKIMessage" anchor="sect-2.6 </t>
"> </section>
<t> <section anchor="sect-2.6" numbered="true" toc="default">
A CMP server may publish announcements, t <name>Announcement PKIMessage</name>
hat can be event triggered or periodic, for the other PKI entities. <t>
Here is the list of CMP announcement mess A CMP server may publish announcements th
ages prefixed by their respective ASN.1 identifier (section 5.1.2 <xref target=" at can be triggered by an event or periodicly for the other PKI entities.
RFC4210"/>) Here is the list of CMP announcement mess
</t> ages prefixed by their respective ASN.1 identifier (see <xref target="RFC4210" f
<figure> ormat="default" sectionFormat="of" section="5.1.2"/>):
<artwork> </t>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
[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
]]></artwork>
]]> <t>
</artwork> An EE <bcp14>MAY</bcp14> use the CoAP Obs
</figure> erve Option <xref target="RFC7641" format="default"/> to register itself to get
<t> any announcement messages from the RA or CA. The EE can send a GET request to th
An EE MAY use CoAP Observe option <xref t e server's URI suffixed by "/ann". For example, a path to register for announcem
arget="RFC7641" /> to register itself to get any announcement messages from the ent messages may look like this:
RA or CA. The EE can send a GET request to the server's URI suffixed by "/ann". </t>
For example a path to register for announcement messages may look like this: <artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork>
<![CDATA[
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
]]> ]]></artwork>
</artwork> <t>
</figure> If the server supports CMP announcement m
If the server supports CMP Announcements essages, then it <bcp14>MUST</bcp14> send an appropriate Success 2.xx response c
messages, then it MUST send appropriate Success 2.xx response code, otherwise it ode; otherwise, it <bcp14>MUST</bcp14> send an appropriate Client Error 4.xx or
MUST send an appropriate Client Error 4.xx or Server Error 5.xx response code. Server Error 5.xx response code. If for some reason the server cannot add the cl
If for some reason the server cannot add the client to its list of observers for ient to its list of observers for the announcements, it can omit the Observe Opt
the announcements, it can omit the Observe option <xref target="RFC7641" /> in ion <xref target="RFC7641" format="default"/> in the response to the client. Upo
the response to the client. A client on receiving a 2.xx success response withou n receiving a Success 2.xx response without the Observe Option <xref target="RFC
t the Observe option <xref target="RFC7641" /> MAY try after some time to regist 7641" format="default"/>, after some time, a client <bcp14>MAY</bcp14> try to re
er again for announcements from the CMP server. Since server can remove the EE f gister again for announcements from the CMP server. Since a server can remove th
rom the list of observers for announcement messages, an EE SHOULD periodically r e EE from the list of observers for announcement messages, an EE <bcp14>SHOULD</
e-register itself for announcement messages. bcp14> periodically reregister itself for announcement messages.
</t> </t>
<t> <t>
Alternatively, an EE MAY periodically poll for the current s Alternatively, an EE <bcp14>MAY</bcp14> periodically poll fo
tatus of the CA via the "PKI Information Request" message, see section 6.5 of <x r the current status of the CA via the "PKI Information Request" message; see <x
ref target="RFC4210" />. If supported, EEs MAY also use "Support Messages" defin ref target="RFC4210" section="6.5" sectionFormat="of" format="default"/>. If sup
ed in section 4.3 of <xref target="I-D.ietf-lamps-lightweight-cmp-profile">Light ported, EEs <bcp14>MAY</bcp14> also use "support messages" defined in <xref targ
weight CMP Profile</xref> to get information about the CA status. et="RFC9483" section="4.3" sectionFormat="of" format="default">Lightweight CMP P
These mechanisms will help constrained de rofile</xref> to get information about the CA status.
vices, that are acting as EEs, to conserve resources by eliminating the need to These mechanisms will help constrained de
create an endpoint for receiving notifications from RA or CA. It will also simpl vices that are acting as EEs to conserve resources by eliminating the need to cr
ify the implementation of a CoAP-to-HTTP proxy. eate an endpoint for receiving notifications from the RA or CA. It will also sim
</t> plify the implementation of a CoAP-to-HTTP proxy.
</section> </t>
</section> </section>
<section title="Proxy Support" anchor="sect-3"> </section>
<t> <section anchor="sect-3" numbered="true" toc="default">
<name>Proxy Support</name>
<t>
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. </t> 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. </t>
<t>
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 <xref target="RFC7252" section="10" sectionFormat="of" format="default
"/>. The CoAP-to-HTTP proxy can either be located closer to the EEs or closer to
the RA or CA. The proxy <bcp14>MAY</bcp14> support service discovery and resour
ce discovery, as described in <xref target="sect-2.2"/>. The CoAP-to-HTTP proxy
<bcp14>MUST</bcp14> function as a reverse proxy, only permitting connections to
a limited set of preconfigured servers. It is out of scope of this document to s
pecify how a reverse proxy can route CoAP client requests to one of the configur
ed servers. Some recommended mechanisms are as follows:
</t>
<ul spacing="normal">
<li>Use the Uri-Path option to identify a server.</li>
<li>Use separate hostnames for each of the configured servers and then u
se the Uri-Host option for routing the CoAP requests.</li>
<li>Use separate hostnames for each of the configured servers and then u
se Server Name Indication <xref target="RFC8446" format="default"/> in case of t
he "coaps://" scheme for routing CoAP requests.</li>
</ul>
<t/>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>Security Considerations</name>
<ul spacing="compact">
<li>
If PKIProtection is used, the PKIHeader and PKIBody of the CMP a
re cryptographically protected against malicious modifications. As such, UDP can
be used without compromising the security of the CMP. Security considerations f
or CoAP are defined in <xref target="RFC7252" format="default"/>.
</li>
<li>
The CMP does not provide confidentiality of the CMP payloads. If
confidentiality is desired, CoAP over DTLS <xref target="RFC9147" format="defau
lt"/> <bcp14>SHOULD</bcp14> be used to provide confidentiality for the CMP paylo
ads; although, it cannot conceal that the CMP is used within the DTLS layer.
</li>
<li>
<xref target="RFC7252" section="9.1" sectionForma
t="of" format="default"/> defines how to use DTLS <xref target="RFC9147" format=
"default"/> for securing CoAP. DTLS <xref target="RFC9147" format="default"/> as
sociations <bcp14>SHOULD</bcp14> be kept alive and reused where possible to amor
tize on the additional overhead of DTLS on constrained devices.
</li>
<li>
An EE might not witness all of the announcement messages when u
sing the CoAP Observe Option <xref target="RFC7641" format="default"/>, since th
e 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 meth
od described in <xref target="sect-2.6"/> to obtain time critical changes, such
as Certificate Revocation List (CRL) <xref target="RFC5280" format="default"/> u
pdates.
</li>
<li>
Implementations <bcp14>SHOULD</bcp14> use the ava
ilable datagram size and avoid sending small datagrams containing partial CMP PK
IMessage data in order to reduce memory usage for packet buffering.
</li>
<li>
A CoAP-to-HTTP proxy can also protect the PKI ent
ities by handling UDP and CoAP messages. The proxy can mitigate attacks, like de
nial-of-service attacks, replay attacks, and resource-exhaustion attacks, by enf
orcing basic checks, like validating that the ASN.1 syntax is compliant to CMP m
essages and validating the PKIMessage protection before sending them to PKI enti
ties.
</li>
<li>
Since the proxy may have access to the CMP-level
metadata and control over the flow of CMP messages, proper role-based access con
trol should be in place. The proxy can be deployed at the edge of the "end entit
ies" 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 it to the HTTP endp
oint. This can be mitigated by using short timers for discarding the buffered me
ssages and rate limiting clients based on the resource usage.
</li>
</ul>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>IANA Considerations</name>
<!-- Note: IANA removed the "Content Coding text from CoAP Content-Format 259" b
ased on feedback from the DE. -->
<t>
IANA has registered "application/pkixcmp" (ID 259) in the <eref t
arget="https://www.iana.org/assignments/core-parameters" brackets="angle">"CoAP
Content-Formats" registry</eref> to transfer CMP transactions over CoAP.
</t>
<dl newline="false" spacing="compact">
<dt>Type name:</dt>
<dd>application</dd>
<dt>Subtype name:</dt>
<dd>pkixcmp</dd>
<dt>Reference:</dt>
<dd>RFC 9482
<xref target="RFC4210" format="default"/></dd>
</dl>
<t>IANA has also registered a new path segment "ann" in the <eref target="
https://www.iana.org/assignments/cmp" brackets="angle">"CMP Well-Known URI Path
Segments" registry</eref> for the EEs to register themselves for the announcemen
t messages.
</t>
<dl newline="false" spacing="compact">
<dt>Path Segment:</dt>
<dd>ann</dd>
<dt>Description:</dt>
<dd>The path to send a GET request with the CoAP Observe Option to regist
er for CMP announcement messages.</dd>
<dt>Reference:</dt>
<dd>RFC 9482</dd>
</dl>
<t>
IANA has added this document as a reference for the "cmp" entry
in the <eref target="https://www.iana.org/assignments/well-known-uris" brackets=
"angle">"Well-Known URIs" registry</eref>.
</t>
<t>
IANA has also added this document as a reference for the "p" ent
ry in the <eref target="https://www.iana.org/assignments/cmp/" brackets="angle">
"CMP Well-Known URI Path Segments" registry</eref>.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
712.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
210.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
959.xml"/>
<t> <reference anchor="RFC9480" target="https://www.rfc-editor.org/info/rfc9480">
Since CMP payload is the same over CoAP and HTTP <front>
transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be implemented bas <title>Certificate Management Protocol (CMP) Updates</title>
ed on section 10 of <xref target="RFC7252" />. The CoAP-to-HTTP proxy can either <author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus' role='edit
be located closer to the EEs or closer to the RA or CA. The proxy MAY support s or'>
ervice discovery and resource discovery as described in section 2.2. The CoAP-to <organization />
-HTTP proxy MUST function as a reverse proxy, only permitting connections to a l </author>
imited set of pre-configured servers. It is out of scope of this document to spe <author initials='D' surname='von Oheimb' fullname='David von Oheimb'>
cify how a reverse proxy can route CoAP client requests to one of the configured <organization />
servers. Some recommended mechanisms are as follows: </author>
</t> <author initials="J" surname="Gray" fullname="John Gray">
<t> <organization/>
<list style="symbols"> </author>
<?rfc subcompact="yes"?> <date year='2023' month='October'/>
<t> </front>
Use the Uri-Path option to identi <seriesInfo name="RFC" value="9480"/>
fy a server. <seriesInfo name="DOI" value="10.17487/RFC9480"/>
</t> </reference>
<t>
Use separate hostnames for each o
f the configured servers and then use the Uri-Host option for routing the CoAP r
equests.
</t>
<t>
Use separate hostnames for each o
f the configured servers and then use Server Name Indication <xref target="RFC84
46" /> in case of "coaps://" scheme for routing CoAP requests.
</t>
</list>
</t>
<t></t>
</section>
<section title="Security Considerations" anchor="sect-4">
<list style="symbols">
<t>
If PKIProtection is used, the PKIHeader and PKIBody of the CMP p
rotocol are cryptographically protected against malicious modifications. As such
, UDP can be used without compromising the security of the CMP protocol. Securit
y Considerations for CoAP are defined in <xref target="RFC7252" />.
</t>
<t>
The CMP protocol does not provide confidentiality of the CMP pay
loads. If confidentiality is desired, CoAP over DTLS <xref target="RFC9147"/> SH
OULD be used to provide confidentiality for the CMP payloads, although it cannot
conceal that the CMP protocol is used within the DTLS layer.
</t>
<t>
Section 9.1 of <xref target="RFC7252" /> defines
how to use DTLS <xref target="RFC9147" /> for securing the CoAP. DTLS <xref targ
et="RFC9147" /> associations SHOULD be kept alive and re-used where possible to
amortize on the additional overhead of DTLS on constrained devices.
</t>
<t>
An EE might not witness all of the Announcement messages when u
sing the CoAP Observe option <xref target="RFC7641" />, since 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 CRL <xref target="RFC5280"/>
updates.
</t>
<t>
Implementations SHOULD use the available datagram
size and avoid sending small datagrams containing partial CMP PKIMessage data i
n order to reduce memory usage for packet buffering.
</t>
<t>
A CoAP-to-HTTP proxy can also protect the PKI ent
ities by handling UDP and CoAP messages. The proxy can mitigate attacks like den
ial of service attacks, replay attacks and resource-exhaustion attacks by enforc
ing basic checks like validating that the ASN.1 syntax is compliant to CMP messa
ges and validating the PKIMessage protection before sending them to PKI entities
.
</t>
<t>
Since the Proxy may have access to the CMP-Level
metadata and control over the flow of CMP messages therefore proper role based a
ccess 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. The proxy how
ever may itself be vulnerable to resource-exhaustion attacks as it's required to
buffer the CMP messages received over CoAP transport before sending it to the H
TTP endpoint. This can be mitigated by using short timers for discarding the buf
fered messages and rate limiting clients based on the resource usage.
</t>
</list>
</section>
<section title="IANA Considerations" anchor="sect-5">
<t>
This document adds a new entry to the <er
ef target="https://www.iana.org/assignments/core-parameters/core-parameters.xhtm
l#content-formats">CoAP Content-Formats IANA Registry</eref> for the code of con
tent-type "application/pkixcmp", for transferring CMP transactions over CoAP, fr
om the identifier range 256-9999 reserved for IETF specifications.
</t>
<t>
Type name: application
</t>
<t>
Subtype name: pkixcmp
</t>
<t>
Encoding: Content may contain arbitrary octet val
ues. The octet values are the ASN.1 DER encoding of a PKI message, as defined in
the
<xref target="RFC4210" />
specifications.
</t>
<t>
Reference: This document and
<xref target="RFC4210" />
</t>
<t>
This document also adds a new path segmen
t "ann" to the <eref target="https://www.iana.org/assignments/cmp/cmp.xhtml#cmp-
well-known-uri">CMP Well-Known URI Path Segments</eref> IANA registry for the EE
s to register themselves for the announcement messages.
</t>
<t>
Path Segment: ann
</t>
<t>
Description: The path to send a GET request with
CoAP Observer Option to register for CMP announcement messages.
</t>
<t>
Reference: This document.
</t>
<t>
This document references the cmp, in the <eref target="https://w
ww.iana.org/assignments/well-known-uris/well-known-uris.xhtml">Well-Known URIs</
eref> IANA registry. Please add a reference of this document to the <eref target
="https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml">Well-K
nown URIs</eref> IANA registry for that entry.
</t>
<t>
This document also refers the path segment "p" in the <eref targ
et="https://www.iana.org/assignments/cmp/cmp.xhtml#cmp-well-known-uri">CMP Well-
Known URI Path Segments</eref> IANA registry. Please add a reference of this doc
ument to the <eref target="https://www.iana.org/assignments/cmp/cmp.xhtml#cmp-we
ll-known-uri">CMP Well-Known URI Path Segments</eref> for that path segment.
</t>
<t>
[Note RFC Editor]: This document should be published together or aft
er the <xref target="I-D.ietf-lamps-cmp-updates"> CMP version 3 </xref> as it re
ferences IANA entries created by that Internet draft.
</t>
</section>
<section title="Acknowledgments" anchor="sect-6">
<t>
The authors would like to thank Hendrik Brockhaus, David von Ohei
mb, and Andreas Kretschmer for their guidance in writing the content of this doc
ument and providing valuable feedback.
</t>
</section>
</middle>
<back> <reference anchor="RFC9483" target="https://www.rfc-editor.org/info/rfc9483">
<front>
<title>Lightweight Certificate Management Protocol (CMP) Profile</title>
<author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus'>
<organization />
</author>
<author initials='D' surname='von Oheimb' fullname='David von Oheimb'>
<organization />
</author>
<author initials='S' surname='Fries' fullname='Steffen Fries'>
<organization />
</author>
<date year='2023' month='October'/>
</front>
<seriesInfo name="RFC" value="9483"/>
<seriesInfo name="DOI" value="10.17487/RFC9483"/>
</reference>
<!-- References Section --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title="Normative References"> 615.xml"/>
&RFC2119; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
&RFC8174; 690.xml"/>
&RFC6712; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&RFC4210; 641.xml"/>
&RFC7252; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&RFC7959; 147.xml"/>
&I-D.ietf-lamps-cmp-updates; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&I-D.ietf-lamps-lightweight-cmp-profile; 112.xml"/>
&RFC8615; </references>
&RFC6690; <references>
&RFC7641; <name>Informative References</name>
&RFC9147; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
&RFC9112; 280.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title="Informative References"> 446.xml"/>
&RFC5280; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC8446; 323.xml"/>
&RFC8323; </references>
</references> </references>
</back> <section anchor="sect-6" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors would like to thank <contact fullname="Hendrik Brockh
aus"/>, <contact fullname="David von Oheimb"/>, and <contact fullname="Andreas K
retschmer"/> for their guidance in writing the content of this document and prov
iding valuable feedback.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 15 change blocks. 
495 lines changed or deleted 460 lines changed or added

This html diff was produced by rfcdiff 1.48.