rfc9148xml2.original.xml   rfc9148.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[
<!ENTITY RFC0791 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!DOCTYPE rfc [
RFC.0791.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!ENTITY zwsp "&#8203;">
RFC.2119.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!ENTITY wj "&#8288;">
RFC.2460.xml">
<!ENTITY RFC4021 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4021.xml">
<!ENTITY RFC8422 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8422.xml">
<!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4944.xml">
<!ENTITY RFC5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5246.xml">
<!ENTITY RFC5273 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5273.xml">
<!ENTITY RFC5272 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5272.xml">
<!ENTITY RFC2585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2585.xml">
<!ENTITY RFC5705 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5705.xml">
<!ENTITY RFC5958 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5958.xml">
<!ENTITY RFC5967 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5967.xml">
<!ENTITY RFC6402 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6402.xml">
<!ENTITY RFC6090 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6090.xml">
<!ENTITY RFC6347 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6347.xml">
<!ENTITY RFC6690 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6690.xml">
<!ENTITY RFC7030 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7030.xml">
<!ENTITY RFC7049 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7049.xml">
<!ENTITY RFC7230 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7230.xml">
<!ENTITY RFC7251 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7251.xml">
<!ENTITY RFC7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7252.xml">
<!ENTITY RFC7925 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7925.xml">
<!ENTITY RFC7959 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7959.xml">
<!ENTITY RFC4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4919.xml">
<!ENTITY RFC5929 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5929.xml">
<!-- <!ENTITY RFC7525 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/refer
ence.RFC.7525.xml"> -->
<!ENTITY RFC7228 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7228.xml">
<!ENTITY RFC7299 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7299.xml">
<!ENTITY RFC7627 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7627.xml">
<!ENTITY RFC7748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7748.xml">
<!ENTITY RFC8075 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8075.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8174.xml">
<!ENTITY RFC8446 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8446.xml">
<!ENTITY I-D.ietf-anima-bootstrapping-keyinfra SYSTEM "http://xml.resource.org/p
ublic/rfc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/
reference.I-D.ietf-tls-dtls13.xml">
<!ENTITY I-D.ietf-tls-dtls-connection-id SYSTEM "https://xml2rfc.tools.ietf.org/
public/rfc/bibxml3/reference.I-D.ietf-tls-dtls-connection-id.xml">
<!ENTITY I-D.moskowitz-ecdsa-pki SYSTEM "https://xml2rfc.tools.ietf.org/public/r
fc/bibxml3/reference.I-D.moskowitz-ecdsa-pki.xml">
<!ENTITY I-D.ietf-core-multipart-ct SYSTEM "https://xml2rfc.tools.ietf.org/publi
c/rfc/bibxml3/reference.I-D.ietf-core-multipart-ct.xml">
<!ENTITY I-D.ietf-lamps-rfc5751-bis SYSTEM "https://xml2rfc.tools.ietf.org/publi
c/rfc/bibxml3/reference.I-D.ietf-lamps-rfc5751-bis.xml">
<!ENTITY I-D.draft-ietf-core-resource-directory-19 SYSTEM "https://xml2rfc.tools
.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-resource-directory-19
.xml">
<!ENTITY I-D.josefsson-sasl-tls-cb SYSTEM "https://xml2rfc.tools.ietf.org/public
/rfc/bibxml3/reference.I-D.josefsson-sasl-tls-cb.xml">
]> ]>
<?rfc strict="no" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true"
<?rfc toc="yes"?> category="std" ipr="trust200902" docName="draft-ietf-ace-coap-est-18" numbe
<?rfc tocdepth="4"?> r="9148"
<?rfc symrefs="yes"?> obsoletes="" updates="" submissionType="IETF" xml:lang="en"
<?rfc sortrefs="yes" ?> tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
<?rfc compact="yes" ?> version="3">
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-ace-coap-est-18">
<front> <front>
<title abbrev="EST-coaps">EST over secure CoAP (EST-coaps)</title> <title abbrev="EST-coaps">EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol</title>
<seriesInfo name="RFC" value="9148"/>
<author fullname="Peter van der Stok" initials="P." surname="van der Stok"> <author fullname="Peter van der Stok" initials="P." surname="van der Stok">
<organization>Consultant</organization> <organization>Consultant</organization>
<address> <address>
<email>consultancy@vanderstok.org</email> <email>stokcons@bbhmail.nl</email>
</address> </address>
</author> </author>
<author fullname="Panos Kampanakis" initials="P" surname="Kampanakis"> <author fullname="Panos Kampanakis" initials="P" surname="Kampanakis">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>pkampana@cisco.com</email> <email>pkampana@cisco.com</email>
</address> </address>
</author> </author>
<!-- <author initials="S.S." surname="Kumar" fullname="Sandeep S. Kumar">
<organization>Philips Lighting Research</organization> <author fullname="Michael C. Richardson" initials="M." surname="Richardson">
<organization abbrev="SSW">Sandelman Software Works
</organization>
<address> <address>
<postal>
<street>High Tech Campus 7</street>
<city>Eindhoven</city>
<region></region>
<code>5656 AE</code>
<country>NL</country>
</postal>
<email>ietf@sandeep.de</email>
</address>
</author> -->
<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization abbrev="SSW">Sandelman Software Works
</organization>
<address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/</uri> <uri>https://www.sandelman.ca/</uri>
</address> </address>
</author> </author>
<!-- <author fullname="Martin Furuhed" initials="M" surname="Furuhed">
<organization>Nexus Group</organization>
<address>
<email>martin.furuhed@nexusgroup.com</email>
</address>
</author> -->
<author fullname="Shahid Raza" initials="S" surname="Raza"> <author fullname="Shahid Raza" initials="S" surname="Raza">
<organization>RISE SICS </organization> <organization>RISE Research Institutes of Sweden</organization>
<address> <address>
<postal> <postal>
<street>Isafjordsgatan 22</street> <street>Isafjordsgatan 22</street>
<city>Kista</city> <city>Kista, Stockholm</city>
<region>Stockholm</region>
<code>16440</code>
<country>SE</country>
</postal>
<email>shahid@sics.se</email>
</address>
</author>
<date/> <code>16440</code>
<country>SE</country>
</postal>
<email>shahid.raza@ri.se</email>
</address>
</author>
<date month="March" year="2022"/>
<area>Security</area> <area>Security</area>
<workgroup>ACE</workgroup> <workgroup>ACE</workgroup>
<keyword>EST</keyword>
<keyword>CoAPS</keyword>
<keyword>Constrained-Voucher</keyword>
<keyword>Constrained-Enrollment</keyword>
<keyword>BRSKI</keyword>
<abstract> <abstract>
<t>Enrollment over Secure Transport (EST) is used as a certificate provisi oning <t>Enrollment over Secure Transport (EST) is used as a certificate provisi oning
protocol over HTTPS. Low-resource devices often use the lightweight Con strained protocol over HTTPS. Low-resource devices often use the lightweight Con strained
Application Protocol (CoAP) for message exchanges. This document define s how to Application Protocol (CoAP) for message exchanges. This document define s how to
transport EST payloads over secure CoAP (EST-coaps), which allows transport EST payloads over secure CoAP (EST-coaps), which allows
constrained devices to use existing EST functionality for provisioning certificates. constrained devices to use existing EST functionality for provisioning certificates.
<!-- Example low-resource use-cases for EST are: secure bootstrapping a
nd certificate enrollment. --> </t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<section anchor="changes" title="Change Log"> <t>"Classical" Enrollment over Secure Transport (EST) <xref target="RFC703
<t>EDNOTE: Remove this section before publication</t> 0" format="default"/>
<t> -18
<list style="empty">
<t>IESG Reviews fixes. </t>
<t>Removed spurious lines introduced in v-17 due to xml2rfc v3.</t>
</list>
</t>
<t> -17
<list style="empty">
<t>v16 remnants by Ben K.</t>
<t>Typos.</t>
</list>
</t>
<t> -16
<list style="empty">
<t>Updates to address Yaron S.'s Secdir review.</t>
<t>Updates to address David S.'s Gen-ART review.</t>
</list>
</t>
<t> -15
<list style="empty">
<t>Updates to addressed Ben's AD follow up feedback.</t>
</list>
</t>
<t> -14
<list style="empty">
<t>Updates to complete Ben's AD review feedback and discussions.</t>
</list>
</t>
<t> -13
<list style="empty">
<t>Updates based on AD's review and discussions </t>
<t>Examples redone without password </t>
</list>
</t>
<t> -12
<list style="empty">
<t>Updated section 5 based on Esko's comments and nits identified. </t
>
<t>Nits and some clarifications for Esko's new review from 5/21/2019. </t
>
<t>Nits and some clarifications for Esko's new review from 5/28/2019.
</t>
</list>
</t>
<t> -11
<list style="empty">
<t>Updated Server-side keygen to simplify motivation and added paragraphs
in Security considerations to point out that random numbers are still needed (f
eedback from Hannes).</t>
</list>
</t>
<t> -10
<list style="empty">
<t>Addressed WGLC comments</t>
<t>More consistent request format in the examples. </t>
<t>Explained root resource difference when there is resource discovery
</t>
<t>Clarified when the client is supposed to do discovery</t>
<t>Fixed nits and minor Option length inaccurracies in the examples. <
/t>
</list>
</t>
<t> -09
<list style="empty">
<t> WGLC comments taken into account </t>
<t> consensus about discovery of content-format </t>
<t> added additional path for content-format selection</t>
<t> merged DTLS sections </t>
</list>
</t>
<t> -08
<list style="empty">
<t>added application/pkix-cert Content-Format TBD287.</t>
<t> discovery text clarified </t>
<t> Removed text on ct negotiation in connection to multipart-core </t>
<t> removed text that duplicates or contradicts RFC7252 (thanks Klaus) <
/t>
<t> Stated that well-known/est is compulsory</t>
<t> Use of response codes clarified.</t>
<t> removed bugs: Max-Age and Content-Format Options in Request</t>
<t> Accept Option explained for est/skg and added in enroll example </t>
<t> Added second URI /skc for server-side key gen and a simple ce
rt (not PKCS#7)</t>
<t> Persistence of DTLS connection clarified. </t>
<t> Minor text fixes. </t>
</list>
</t>
<t> -07:
<list style="empty">
<t> redone examples from scratch with openssl </t>
<t>Updated authors.</t>
<t>Added CoAP RST as a MAY for an equivalent to an HTTP 204 messa
ge.</t>
<t>Added serialization example of the /skg CBOR response. </t>
<t>Added text regarding expired IDevIDs and persistent DTLS conne
ction that will start using the Explicit TA Database in the new DTLS connection.
</t>
<t>Nits and fixes</t>
<t>Removed CBOR envelop for binary data</t>
<t>Replaced TBD8 with 62. </t>
<t>Added RFC8174 reference and text. </t>
<t>Clarified MTI for server-side key generation and Content-Forma
ts. Defined the /skg MTI (PKCS#8) and the cases where CMS encryption will be use
d. </t>
<t>Moved Fragmentation section up because it was referenced in se
ctions above it.</t>
</list>
</t>
<t> -06:
<list style="empty">
<t>clarified discovery section, by specifying that no discovery may be n
eeded for /.well-known/est URI.</t>
<t>added resource type values for IANA</t>
<t>added list of compulsory to implement and optional functions. </t>
<t>Fixed issues pointed out by the idnits tool.</t>
<t>Updated CoAP response codes section with more mappings between
EST HTTP codes and EST-coaps CoAP codes.</t>
<t>Minor updates to the MTI EST Functions section.</t>
<t>Moved Change Log section higher.</t>
</list>
</t>
<t> -05:
<list style="empty">
<t>repaired again</t>
<t>TBD8 = 62 removed from C-F registration, to be done in CT draf
t.</t>
</list>
</t>
<t> -04:
<list style="empty">
<t> Updated Delayed response section to reflect short and long delay
options.</t>
</list>
</t>
<t> -03:
<list style="empty">
<t>Removed observe and simplified long waits</t>
<t>Repaired Content-Format specification</t>
</list>
</t>
<t> -02:
<list style="empty">
<t>Added parameter discussion in section 8</t>
<t>Concluded Content-Format specification using multipart-ct draft</t>
<t>examples updated </t>
</list>
</t>
<t> -01:
<list style="empty">
<t>Editorials done.</t>
<t>Redefinition of proxy to Registrar in <xref target="proxy"/>. Explained
better the role of https-coaps Registrar, instead of "proxy"</t>
<t>Provide "observe" Option examples </t>
<t> extended block message example. </t>
<t>inserted new server key generation text in <xref target="serverkey"/> a
nd motivated server key generation.</t>
<t>Broke down details for DTLS 1.3 </t>
<t>New Media-Type uses CBOR array for multiple Content-Format payloads</t>
<t>provided new Content-Format tables</t>
<t> new media format for IANA </t>
</list>
</t>
<t> -00
<list style="empty">
<t> copied from vanderstok-ace-coap-04</t>
</list>
</t>
</section> <!-- Change Log -->
<section anchor="intro" title="Introduction">
<t>"Classical" Enrollment over Secure Transport (EST) <xref target="RFC70
30"/>
is used for authenticated/authorized endpoint certificate enrollment (and is used for authenticated/authorized endpoint certificate enrollment (and
optionally key provisioning) through a Certificate Authority (CA) or optionally key provisioning) through a Certification Authority (CA) or
Registration Authority (RA). EST transports messages over HTTPS.</t> Registration Authority (RA). EST transports messages over HTTPS.</t>
<t>This document defines a new transport for EST based on the Constrained
<t>This document defines a new transport for EST based on the Constrained
Application Protocol (CoAP) since some Internet of Things (IoT) devices Application Protocol (CoAP) since some Internet of Things (IoT) devices
use CoAP instead of HTTP. Therefore, this specification utilizes DTLS use CoAP instead of HTTP. Therefore, this specification utilizes DTLS
<xref target="RFC6347"/> and CoAP <xref target="RFC7252"/> instead of <xref target="RFC6347" format="default"/> and CoAP <xref target="RFC7252" for
TLS <xref target="RFC8446"/> and HTTP <xref target="RFC7230"/>. </t> mat="default"/> instead of
TLS <xref target="RFC8446" format="default"/> and HTTP <xref target="RFC7230"
<t>EST responses can be relatively large and for this reason this format="default"/>. </t>
specification also uses CoAP Block-Wise Transfer <xref target="RFC7959"/> to <t>EST responses can be relatively large, and for this reason, this
specification also uses CoAP Block-Wise Transfer <xref target="RFC7959" forma
t="default"/> to
offer a fragmentation mechanism of EST messages at the CoAP layer. offer a fragmentation mechanism of EST messages at the CoAP layer.
</t> </t>
<t>This document also profiles the use of EST to support
<t>This document also profiles the use of EST to only support certificate-based client authentication only. Neither HTTP Basic nor Diges
certificate-based client authentication. HTTP Basic or Digest t
authentication (as described in Section 3.2.3 of authentication (as described in <xref target="RFC7030"
<xref target="RFC7030"/>) are not supported. </t> sectionFormat="of" section="3.2.3"/>) is supported. </t>
<!-- <t>IPv6 over Low-power Wireless Personal Area Networks (6LoWPANs) <xref target="RFC4944" /> on IEEE 802.15.4 <xref target="ieee802.15.4" /> wireless net works are becoming common in many industry application domains such as lighting controls. Although IEEE 802.15.4 defines how security can be enabled between nod es within a single mesh network, it does not specify the provisioning and manage ment of the keys. Therefore, securing a 6LoWPAN network with devices from multip le manufacturers with different provisioning techniques is often tedious and tim e consuming. An example use-case is the application of Bootstrapping of Remote S ecure Infrastructures (BRSKI) <xref target="I-D.ietf-anima-bootstrapping-keyinfr a"/> </t> --> </section>
<!-- <section anchor="scenario" title="EST operational differences"> <section anchor="terminology" numbered="true" toc="default">
<t>Only the differences to EST with respect to operational scenarios are d <name>Terminology</name>
escribed in this section. EST-coaps server differs from EST server as follows:
<list style="symbols">
<t>Replacement of TLS by DTLS and HTTP by CoAP, resulting in:
<list>
<t>DTLS-secured CoAP sessions between EST-coaps client and EST-coaps
server.</t>
</list></t>
<t>Only certificate-based client authentication is supported, which re
sults in:
<list>
<t>The EST-coaps client does not support HTTP Basic authentication
(as described in Section 3.2.3 of <xref target="RFC7030"/>).</t>
<t>The EST-coaps client does not support authentication at the app
lication layer (as described in Section 3.2.3 of <xref target="RFC7030"/>).</t>
</list></t>
</list></t>
</section> --> <!-- EST operational differences -->
</section> <!-- Introduction -->
<section anchor="terminology" title="Terminology"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>Many of the concepts in this document are taken from <xref target="RFC703 <t>Many of the concepts in this document are taken from <xref target="RFC7
0"/>. Consequently, much text is directly traceable to <xref target="RFC7030"/>. 030" format="default"/>. Consequently, much text is directly traceable to <xref
</t><!-- The same document structure is followed to point out the differences a target="RFC7030" format="default"/>. </t>
nd commonalities between EST and EST-coaps. -->
</section> <!-- Terminology -->
<section anchor="profile7925" title="DTLS and conformance to RFC7925 profiles" </section>
>
<t>This section describes how EST-coaps conforms to the profiles of low-reso
urce
devices described in <xref target="RFC7925"/>.
EST-coaps can transport certificates and private keys. Certificates
are responses to (re-)enrollment requests or requests for a trusted certi
ficate
list. Private keys can be transported as responses to a
server-side key generation request as described in Section 4.4 of
<xref target="RFC7030"/> (and subsections) and discussed in
<xref target="serverkey"/> of this document. </t>
<t>EST-coaps depends on a secure transport mechanism that secures the exc <section anchor="profile7925" numbered="true" toc="default">
hanged CoAP messages. DTLS is one such secure protocol. No other changes are nec <name>DTLS and Conformance to RFC 7925 Profiles</name>
essary regarding the secure transport of EST messages. </t><!-- DTLS handshakes <t>This section describes how EST-coaps conforms to the profiles of
use a retramsit times to handle packet loss in lossy environments. as explained low-resource devices described in <xref target="RFC7925"
in https://tools.ietf.org/html/rfc6347#section-3.2.1 --> format="default"/>. EST-coaps can transport certificates and private
keys. Certificates are responses to (re-)enrollment requests or requests
for a trusted certificate list. Private keys can be transported as
responses to a server-side key generation request as described in <xref
target="RFC7030" sectionFormat="of" section="4.4"/> (and subsections)
and discussed in <xref target="serverkey" format="default"/> of this
document. </t>
<t>EST-coaps depends on a secure transport mechanism that secures the exch
anged CoAP messages. DTLS is one such secure protocol. No other changes are nece
ssary regarding the secure transport of EST messages. </t>
<figure align="center" title="EST-coaps protocol layers" anchor="fig-est- <figure align="center" anchor="est-coaps-layers">
coaps-layers"><artwork><![CDATA[ <name>EST-coaps Protocol Layers</name>
<artwork align="center"><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| EST request/response messages | | EST request/response messages |
+------------------------------------------------+ +------------------------------------------------+
| CoAP for message transfer and signaling | | CoAP for message transfer and signaling |
+------------------------------------------------+ +------------------------------------------------+
| Secure Transport | | Secure Transport |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t> <t>
In accordance with sections 3.3 and 4.4 of <xref target="RFC7925" />, the In accordance with Sections <xref target="RFC7925" section="3.3"
sectionFormat="bare"/> and <xref target="RFC7925" section="4.4" sectionForma
t="bare"/> of <xref target="RFC7925" format="default"/>, the
mandatory cipher suite for DTLS in EST-coaps is mandatory cipher suite for DTLS in EST-coaps is
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251"/>. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 <xref target="RFC7251" format="default"/>
Curve secp256r1 MUST .
be supported <xref target="RFC8422"/>; this curve is equivalent to the Curve secp256r1 <bcp14>MUST</bcp14>
NIST P-256 curve. After the publication of <xref target="RFC7748" />, be supported <xref target="RFC8422" format="default"/>; this curve is equiva
lent to the
NIST P-256 curve. After the publication of <xref target="RFC7748" format="de
fault"/>,
support for Curve25519 will likely be required in the future by support for Curve25519 will likely be required in the future by
(D)TLS Profiles for the Internet of Things <xref target="RFC7925" />. (D)TLS profiles for the Internet of Things <xref target="RFC7925" format=
</t> "default"/>.
</t>
<!-- Removed DTLS normative language for DTLS. Keeping lowercase wording jus
t to serve as non-normative reminders -->
<!-- <xref target="RFC6090"/> includes a summary of the ECC algorithms.--
>
<t>DTLS 1.2 implementations must use the Supported Elliptic Curves and Su pported <t>DTLS 1.2 implementations must use the Supported Elliptic Curves and Su pported
Point Formats Extensions in <xref target="RFC8422"/>. Uncompressed point Point Formats Extensions in <xref target="RFC8422" format="default"/>. Uncom
format must also be supported. DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/> pressed point
format must also be supported. DTLS 1.3 <xref target="RFC9147" format="defau
lt"/>
implementations differ from DTLS 1.2 implementations differ from DTLS 1.2
because they do not support point format negotiation in favor of a single because they do not support point format negotiation in favor of a single
point format for each curve. Thus, support for DTLS 1.3 does not mandate point format for each curve. Thus, support for DTLS 1.3 does not mandate
point format extensions and negotiation. In addition, in DTLS 1.3 the point format extensions and negotiation. In addition, in DTLS 1.3, the
Supported Elliptic Curves extension has been renamed to Supported Groups. Supported Elliptic Curves extension has been renamed to Supported Groups.
</t> </t>
<t>CoAP was designed to avoid IP fragmentation. DTLS is used to secure CoAP
messages. However, fragmentation is still possible at the DTLS layer during the
DTLS handshake when using ECC ciphersuites. If fragmentation is necessary, "DTLS
provides a mechanism for fragmenting a handshake message over several records,
each of which can be transmitted separately, thus avoiding IP fragmentation" <xr
ef target="RFC6347"/>.</t>
<t>The authentication of the EST-coaps server by the EST-coaps
client is based on certificate authentication in the DTLS handshake.
The EST-coaps client MUST be configured with at least an Implicit TA
database which will enable the authentication of the server the
first time before updating its trust anchor (Explicit TA) <xref target="R
FC7030"/>.</t>
<t>The authentication of the EST-coaps client MUST be with a client certific
ate
in the DTLS handshake. This can either be
<list style="symbols">
<t>a previously issued client certificate (e.g., an existing certificate
issued
by the EST CA); this could be a common case for simple re-enrollm
ent of clients. </t>
<t>a previously installed certificate (e.g., manufacturer IDevID
<xref target="ieee802.1ar"/> or a certificate issued by some othe
r party). IDevID's are expected to have
a very long life, as long as the device, but under some conditions
could expire. In that case, the server MAY authenticate
a client certificate against its trust store although the certifi
cate
is expired (<xref target="sec"/>). </t>
</list></t>
<t>EST-coaps supports the certificate types and Trust Anchors (TA) that a
re specified for EST in Section 3 of <xref target="RFC7030"/>.
</t>
<t>As described in Section 2.1 of <xref target="RFC5272"/> proof-of-identity
refers to
a value that can be used to prove that an end-entity or client
is in the possession of and can use the private key corresponding
to the certified public key. Additionally, channel-binding
information can link proof-of-identity with an established connection.
Connection-based proof-of-possession is OPTIONAL for EST-coaps clients an
d servers. When proof-of-possession is desired, a set of actions are required re
garding the use of tls-unique, described in Section 3.5 in <xref target="RFC7030
"/>. The tls-unique information consists of the contents of the first "Finished"
message in the (D)TLS handshake between server and client <xref target="RFC5929
"/>. The client adds the "Finished" message as a ChallengePassword in the attrib
utes section of the PKCS#10 Request <xref target="RFC5967"/> to prove that the c
lient is indeed in control of the private key at the time of the (D)TLS session
establishment. </t>
<t>In the case of handshake message fragmentation, if proof-of-possession
is desired, the Finished
message added as the ChallengePassword in the CSR is calculated as specified
by the DTLS standards. We summarize it here for convenience. For DTLS 1.2, in t
he event of handshake message fragmentation, the Hash of the handshake messages
used in the MAC calculation of the Finished message must be computed on each rea
ssembled message, as if each message had not been fragmented (Section 4.2.6 of <
xref target="RFC6347"/>). The Finished message is calculated as shown in Section
7.4.9 of <xref target="RFC5246"/>. Similarly, for DTLS 1.3, the Finished messag
e must be computed as if each
handshake message had been sent as a single fragment (Section 5.8 of
<xref target="I-D.ietf-tls-dtls13"/>) following the algorithm described
in 4.4.4 of <xref target="RFC8446"/>. </t>
<!--<figure align="left"><artwork><![CDATA[
PRF(master_secret, finished_label, Hash(handshake_messages))
[0..verify_data_length-1];
]]></artwork></figure> -->
<!-- <figure align="left"><artwork><![CDATA[
HMAC(finished_key,
Transcript-Hash(Handshake Context,
Certificate*, CertificateVerify*))
* Only included if present. <t>CoAP was designed to avoid IP fragmentation. DTLS is used to secure
]]></artwork></figure> --> CoAP messages. However, fragmentation is still possible at the DTLS
layer during the DTLS handshake even when using Elliptic Curve
Cryptography (ECC) cipher suites. If fragmentation is necessary, "DTLS
provides a mechanism for fragmenting a handshake message over a number
of records, each of which can be transmitted separately, thus avoiding
IP fragmentation" <xref target="RFC6347" format="default"/>.</t>
<t>The authentication of the EST-coaps server by the EST-coaps client is
based on certificate authentication in the DTLS handshake. The
EST-coaps client <bcp14>MUST</bcp14> be configured with at least an
Implicit Trust Anchor database, which will enable the authentication
of the server the first time before updating its trust anchor (Explicit
TA) <xref target="RFC7030" format="default"/>.</t>
<t>The authentication of the EST-coaps client <bcp14>MUST</bcp14> be with
a client certificate
in the DTLS handshake. This can either be:
</t>
<ul spacing="normal">
<li>A previously issued client certificate (e.g., an existing
certificate issued by the EST CA); this could be a common case for
simple re-enrollment of clients. </li>
<li>A previously installed certificate (e.g., manufacturer IDevID
<xref target="IEEE802.1AR" format="default"/> or a certificate issued
by some other party). IDevID's are expected to have a very long life,
as long as the device, but under some conditions could expire. In that
case, the server <bcp14>MAY</bcp14> authenticate a client certificate
against its trust store though the certificate is expired (<xref
target="sec" format="default"/>). </li>
</ul>
<t>EST-coaps supports the certificate types and TAs that
are specified for EST in <xref target="RFC7030"
sectionFormat="of" section="3"/>.
</t>
<t>As described in <xref target="RFC5272" sectionFormat="of"
section="2.1"/>, proof-of-identity refers to a value that can be used to
prove that an end entity or client is in the possession of and can use
the private key corresponding to the certified public key. Additionally,
channel-binding information can link proof-of-identity with an
established connection. Connection-based proof-of-possession is
<bcp14>OPTIONAL</bcp14> for EST-coaps clients and servers. When
proof-of-possession is desired, a set of actions are required regarding
the use of tls-unique, described in <xref target="RFC7030"
sectionFormat="of" section="3.5"/>. The tls-unique information consists
of the contents of the first Finished message in the (D)TLS handshake
between server and client <xref target="RFC5929" format="default"/>. The
client adds the Finished message as a challengePassword in the
attributes section of the PKCS #10 CertificationRequest <xref
target="RFC5967" format="default"/> to prove that the client is indeed
in control of the private key at the time of the (D)TLS session
establishment. In the case of handshake message fragmentation, if
proof-of-possession is desired, the Finished message added as the
challengePassword in the Certificate Signing Request (CSR) is calculated
as specified by (D)TLS. We summarize it here for convenience. For DTLS
1.2, in the event of handshake message fragmentation, the hash of the
handshake messages used in the Message Authentication Code (MAC)
calculation of the Finished message must be computed on each reassembled
message, as if each message had not been fragmented (<xref
target="RFC6347" sectionFormat="of" section="4.2.6"/>). The Finished
message is calculated as shown in <xref target="RFC5246"
sectionFormat="of" section="7.4.9"/>. </t>
<t>In a constrained CoAP environment, endpoints can't always afford to establ <t>For (D)TLS 1.3, <xref target="RFC8446" sectionFormat="of"
ish a DTLS connection for every EST transaction. An EST-coaps DTLS connection MA section="C.5"/> describes the lack of channel bindings similar to
Y remain open for sequential EST transactions, which was not the case with <xref tls-unique.
target="RFC7030"/>. <xref target="I-D.ietf-kitten-tls-channel-bindings-for-tls13" format="d
For example, if a /crts request is followed by a /sen request, both can use t efault"/>
he same authenticated DTLS connection. However, when a /crts request is included can be used instead to derive a 32-byte tls-exporter binding from
in the set of sequential EST transactions, some additional security considerati the (D)TLS 1.3 master secret by using a PRF negotiated in the (D)TLS
ons apply regarding the use of the Implicit and Explicit TA database as explaine 1.3 handshake, "EXPORTER-Channel-Binding" with no terminating NUL as
d in <xref target="sec-est"/>.</t> the label, the ClientHello.random and ServerHello.random, and a
zero-length context string. When proof-of-possession is desired, the
client adds the tls-exporter value as a challengePassword in the
attributes section of the PKCS #10 CertificationRequest <xref
target="RFC5967" format="default"/> to prove that the client is
indeed in control of the private key at the time of the (D)TLS
session establishment. </t>
<t>Given that after a successful enrollment, it is more likely that a new EST <t>In a constrained CoAP environment, endpoints can't always afford to
transaction will not take place for a significant amount of time, the DTLS conn establish a DTLS connection for every EST transaction. An EST-coaps DTLS
ections SHOULD only be kept alive for EST messages that are relatively close to connection <bcp14>MAY</bcp14> remain open for sequential EST transactions,
each other. These could include a /sen immediatelly following a /crts when a dev which was not the case with <xref target="RFC7030" format="default"/>. For
ice is getting bootstrapped. In some cases, like NAT rebinding, keeping the stat example, if a /crts request is followed by a /sen request, both can use the
e of a connection is not possible when devices sleep for extended periods of tim same authenticated DTLS connection. However, when a /crts request is
e. In such occasions, <xref target="I-D.ietf-tls-dtls-connection-id"/> negotiate included in the set of sequential EST transactions, some additional
s a connection ID that can eliminate the need for new handshake and its addition security considerations apply regarding the use of the Implicit and
al cost; or DTLS session resumption provides a less costly alternative than re-d Explicit TA database as explained in <xref target="sec-est"
oing a full DTLS handshake. </t> format="default"/>.</t>
</section> <!-- 7925 profile --> <t>Given that after a successful enrollment, it is more likely that a
new EST transaction will not take place for a significant amount of
time, the DTLS connections <bcp14>SHOULD</bcp14> only be kept alive for
EST messages that are relatively close to each other. These could
include a /sen immediately following a /crts when a device is getting
bootstrapped. In some cases, like NAT rebinding, keeping the state of a
connection is not possible when devices sleep for extended periods of
time. In such occasions, <xref target="RFC9146"
format="default"/> negotiates a connection ID that can eliminate the
need for a new handshake and its additional cost; or, DTLS session
resumption provides a less costly alternative than redoing a full DTLS
handshake. </t>
</section>
<section anchor="design" title="Protocol Design"> <section anchor="design" numbered="true" toc="default">
<t>EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise Transfe <name>Protocol Design</name>
r <t>EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise Trans
<xref target="RFC7959"/> to avoid IP fer
fragmentation. The use of Blocks for the transfer of larger <xref target="RFC7959" format="default"/>, to avoid IP
EST messages is specified in <xref target="fragment"/>. fragmentation. The use of blocks for the transfer of larger
<xref target="fig-est-coaps-layers"/> shows the layered EST-coaps EST messages is specified in <xref target="fragment" format="default"/>.
<xref target="est-coaps-layers" format="default"/> shows the layered EST-
coaps
architecture.</t> architecture.</t>
<t>The EST-coaps protocol design follows closely the EST design. The suppo
<t>The EST-coaps protocol design follows closely the EST design. The support rted
ed
message types in EST-coaps are: message types in EST-coaps are:
<list style="symbols"> </t>
<t>CA certificate retrieval needed to receive the complete set of CA cer <ul spacing="normal">
tificates. </t> <li>CA certificate retrieval needed to receive the complete set of CA ce
<t>Simple enroll and re-enroll for a CA to sign client identity p rtificates. </li>
ublic key.</t> <li>Simple enroll and re-enroll for a CA to sign client identity public
<t>Certificate Signing Request (CSR) attribute messages that informs the keys.</li>
client <li>Certificate Signing Request (CSR) attribute messages that informs th
of the fields to include in a CSR.</t> e client
<t>Server-side key generation messages to provide a client identity priv of the fields to include in a CSR.</li>
ate key when the client chooses so. </t> <li>Server-side key generation messages to provide a client identity pri
</list></t> vate key when the client chooses so. </li>
<t> </ul>
While <xref target="RFC7030" /> permits a number of the EST functions to be us <t>
ed without While <xref target="RFC7030" format="default"/> permits a number of the EST fu
authentication, this specification requires that the client MUST be authentica nctions to be used without
ted authentication, this specification requires that the client <bcp14>MUST</bcp14
for all functions. </t><!-- because allowing unauthenticated requests introduc > be authenticated
es security concerns and amplification attacks --> for all functions. </t>
<section anchor="discovery" title = "Discovery and URIs">
<t>EST-coaps is targeted for low-resource networks with small packets. Two t
ypes of installations are possible: (1) rigid ones, where the address and the su
pported functions of the EST server(s) are known, and (2) a flexible one, where
the EST server and its supported functions need to be discovered.</t>
<t>For both types of installations, saving header space is important and sho <section anchor="discovery" numbered="true" toc="default">
rt EST-coaps URIs are specified in this document. These URIs are shorter than th <name>Discovery and URIs</name>
e ones in <xref target="RFC7030"/>. Two example EST-coaps resource path names ar <t>EST-coaps is targeted for low-resource networks with small packets. T
e: </t> wo types of installations are possible: (1) a rigid one, where the address and t
he supported functions of the EST server(s) are known, and (2) a flexible one, w
here the EST server and its supported functions need to be discovered.</t>
<t>For both types of installations, saving header space is important and
short EST-coaps URIs are specified in this document. These URIs are shorter tha
n the ones in <xref target="RFC7030" format="default"/>. Two example EST-coaps r
esource path names are: </t>
<figure align="left"><artwork><![CDATA[ <artwork><![CDATA[
coaps://example.com:<port>/.well-known/est/<short-est> coaps://example.com:<port>/.well-known/est/<short-est>
coaps://example.com:<port>/.well-known/est/ArbitraryLabel/<short-est> coaps://example.com:<port>/.well-known/est/ArbitraryLabel/<short-est>
]]></artwork></figure> ]]></artwork>
<!-- The ArbitraryLabel path-segment, if used, SHOULD be of the shortes <t>The short-est strings are defined in <xref target="est-uri" format="def
t length ault"/>.
possible (Sections 3.1 and 3.2.2 of <xref target="RFC7030"/>. -->
<t>The short-est strings are defined in <xref target="est-uri"/>.
Arbitrary Labels are usually defined and used by EST CAs in order Arbitrary Labels are usually defined and used by EST CAs in order
to route client requests to the appropriate certificate profile. to route client requests to the appropriate certificate profile.
Implementers should consider using short labels to minimize Implementers should consider using short labels to minimize
transmission overhead.</t> transmission overhead.</t>
<t>The EST-coaps server URIs, obtained through discovery of the
<t>The EST-coaps server URIs, obtained through discovery of the
EST-coaps resource(s) as shown below, are of the form: </t> EST-coaps resource(s) as shown below, are of the form: </t>
<figure align="left"><artwork><![CDATA[ <artwork><![CDATA[
coaps://example.com:<port>/<root-resource>/<short-est> coaps://example.com:<port>/<root-resource>/<short-est>
coaps://example.com:<port>/<root-resource>/ArbitraryLabel/<short-est> coaps://example.com:<port>/<root-resource>/ArbitraryLabel/<short-est>
]]></artwork></figure> ]]></artwork>
<t>Figure 5 in <xref target="RFC7030" sectionFormat="of"
<t>Figure 5 in Section 3.2.2 of <xref target="RFC7030"/> enumerates the op section="3.2.2"/> enumerates the operations and corresponding paths
erations and corresponding paths which are supported by EST. <xref target="est-u that are supported by EST. <xref target="est-uri" format="default"/>
ri"/> provides the mapping from the EST URI path to the shorter EST-coaps URI pa provides the mapping from the EST URI path to the shorter EST-coaps
th.</t> URI path.</t>
<texttable anchor="est-uri" title="Short EST-coaps URI path"> <table anchor="est-uri" align="center">
<ttcol align="left">EST</ttcol> <name>Short EST-coaps URI Path</name>
<ttcol align="left">EST-coaps</ttcol> <thead>
<tr>
<c> /cacerts </c> <c> /crts </c> <th align="left">EST</th>
<c> /simpleenroll </c> <c> /sen </c> <th align="left">EST-coaps</th>
<c> /simplereenroll </c> <c> /sren </c> </tr>
<c> /serverkeygen </c> <c> /skg (PKCS#7) </c> </thead>
<c> /serverkeygen </c> <c> /skc (application/pkix-cert)</c> <tbody>
<c> /csrattrs </c> <c> /att </c> <tr>
</texttable> <td align="left"> /cacerts </td>
<td align="left"> /crts </td>
<t>The /skg message is the EST /serverkeygen equivalent where the client </tr>
requests a certificate in PKCS#7 format and a private key. If the <tr>
client prefers a single application/pkix-cert certificate instead of PK <td align="left"> /simpleenroll </td>
CS#7, <td align="left"> /sen </td>
it will make an /skc request. In both cases (i.e., /skg, /skc) a privat </tr>
e key MUST be returned.</t> <tr>
<td align="left"> /simplereenroll </td>
<td align="left"> /sren </td>
</tr>
<tr>
<td align="left"> /serverkeygen </td>
<td align="left"> /skg (PKCS #7) </td>
</tr>
<tr>
<td align="left"> /serverkeygen </td>
<td align="left"> /skc (application/pkix-cert)</td>
</tr>
<tr>
<td align="left"> /csrattrs </td>
<td align="left"> /att </td>
</tr>
</tbody>
</table>
<t>The /skg message is the EST /serverkeygen equivalent where the
client requests a certificate in PKCS #7 format and a private key. If
the client prefers a single application/pkix-cert certificate instead
of PKCS #7, it will make an /skc request. In both cases (i.e., /skg,
/skc), a private key <bcp14>MUST</bcp14> be returned.</t>
<t>Clients and servers <bcp14>MUST</bcp14> support the short resource ES
T-coaps URIs. </t>
<t>Clients and servers MUST support the short resource EST-coaps URIs. </t <t>In the context of CoAP, the presence and location of (path to) the
> EST resources are discovered by sending a GET request to
<!-- Panos: Commented this out after a review from Carsten that pointed "/.well-known/core" including a resource type (RT) parameter with the
out that we can't make our minds what to use and we let the implementers use wh value "ace.est*" <xref target="RFC6690" format="default"/>. The example
at they want. So we decided to be more specific and pick short URIs only. --> below shows the discovery over CoAPS of the presence and location of
<!--The corresponding longer URIs from <xref target="RFC7030"/> MAY be EST-coaps resources. Linefeeds are included only for readability.</t>
supported.-->
<!-- Upon success, the return payload will contain the root resource of th <sourcecode type="core-link-format"><![CDATA[
e EST resources. The server MAY return all available resource paths and the used
content types. This is useful when multiple content types are supported by the
EST-coaps server and optional functions are available. -->
<t>In the context of CoAP, the presence and location of (path to) the EST
resources are discovered by sending a GET request to "/.well-known/core" includi
ng a resource type (RT) parameter with the value "ace.est*" <xref target="RFC669
0"/>. The example below shows the discovery over CoAPS of the presence and locat
ion of EST-coaps resources. Linefeeds are included only for readability.</t>
<figure><artwork align="left"><![CDATA[
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content RES: 2.05 Content
</est/crts>;rt="ace.est.crts";ct="281 TBD287", </est/crts>;rt="ace.est.crts";ct="281 287",
</est/sen>;rt="ace.est.sen";ct="281 TBD287", </est/sen>;rt="ace.est.sen";ct="281 287",
</est/sren>;rt="ace.est.sren";ct="281 TBD287", </est/sren>;rt="ace.est.sren";ct="281 287",
</est/att>;rt="ace.est.att";ct=285, </est/att>;rt="ace.est.att";ct=285,
</est/skg>;rt="ace.est.skg";ct=62, </est/skg>;rt="ace.est.skg";ct=62,
</est/skc>;rt="ace.est.skc";ct=62 </est/skc>;rt="ace.est.skc";ct=62
]]></artwork> ]]></sourcecode>
</figure> <t>The first three lines, describing ace.est.crts, ace.est.sen, and
<!-- Used quotes when multiple cts are returned as shown in draft-ietf-core- ace.est.sren, of the discovery response above <bcp14>MUST</bcp14> be
resource-directory-19 --> returned if the server supports resource discovery. The last three lines
<t>The first three lines, describing ace.est.crts, ace.est.sen, and ace.es are only included if the corresponding EST functions are implemented
t.sren, of the discovery response above MUST be returned if the server supports (see <xref target="est-implementation" format="default"/>). The
resource discovery. The last three lines are only included if the corresponding Content-Formats in the response allow the client to request one that is
EST functions are implemented (see <xref target="est-implementation"/>). The Con supported by the server. These are the values that would be sent in the
tent-Formats in the response allow the client to request one that is supported b client request with an Accept Option. </t>
y the server. These are the values that would be sent in the client request with
an Accept option. </t><!--This approach allows future servers to incorporate cu
rrently not specified content-formats and resources.-->
<!--Port numbers, not returned in the example, are assumed to be the defau
lt numbers 5683 and 5684 for CoAP and CoAPS respectively (Sections 12.6 and 12.7
of <xref target="RFC7252"/>). -->
<t>Discoverable port numbers can be returned in the response payload. A n example response payload for non-default CoAPS server port 61617 follows below . Linefeeds are included only for readability.</t> <t>Discoverable port numbers can be returned in the response payload. A n example response payload for non-default CoAPS server port 61617 follows below . Linefeeds are included only for readability.</t>
<figure><artwork align="left"><![CDATA[
<sourcecode type="core-link-format"><![CDATA[
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content RES: 2.05 Content
<coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts"; <coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts";
ct="281 TBD287", ct="281 287",
<coaps://[2001:db8:3::123]:61617/est/sen>;rt="ace.est.sen"; <coaps://[2001:db8:3::123]:61617/est/sen>;rt="ace.est.sen";
ct="281 TBD287", ct="281 287",
<coaps://[2001:db8:3::123]:61617/est/sren>;rt="ace.est.sren"; <coaps://[2001:db8:3::123]:61617/est/sren>;rt="ace.est.sren";
ct="281 TBD287", ct="281 287",
<coaps://[2001:db8:3::123]:61617/est/att>;rt="ace.est.att"; <coaps://[2001:db8:3::123]:61617/est/att>;rt="ace.est.att";
ct=285, ct=285,
<coaps://[2001:db8:3::123]:61617/est/skg>;rt="ace.est.skg"; <coaps://[2001:db8:3::123]:61617/est/skg>;rt="ace.est.skg";
ct=62, ct=62,
<coaps://[2001:db8:3::123]:61617/est/skc>;rt="ace.est.skc"; <coaps://[2001:db8:3::123]:61617/est/skc>;rt="ace.est.skc";
ct=62 ct=62
]]></artwork> ]]></sourcecode>
</figure>
<!--on port 5684--> <t>The server <bcp14>MUST</bcp14> support the default /.well-known/est
<t>The server MUST support the default /.well-known/est root resource. The server <bcp14>SHOULD</bcp14> support
root resource. The server SHOULD support
resource discovery when it supports non-default URIs resource discovery when it supports non-default URIs
(like /est or /est/ArbitraryLabel) or ports. The client (like /est or /est/ArbitraryLabel) or ports. The client
SHOULD use resource discovery when it is unaware <bcp14>SHOULD</bcp14> use resource discovery when it is unaware
of the available EST-coaps resources.</t><!-- or considers of the available EST-coaps resources.</t>
sending two Uri-Path Options to convey the resource
wasteful.-->
<t>Throughout this document the example root resource of /est is used.<
/t>
</section> <!-- discovery and URIs -->
<section anchor="implementation" title="Mandatory/optional EST Functions">
<t>
This specification contains a set of required-to-implement functions, optional f
unctions, and not specified functions. The unspecified functions are deemed too
expensive for low-resource devices in payload and calculation times.</t>
<t> <xref target="est-implementation"/> specifies the mandatory-to-implement or
optional implementation of the EST-coaps functions. Discovery of the existence o
f optional functions is described in <xref target="discovery"/>.</t>
<texttable anchor="est-implementation" title="List of EST-coaps functions">
<ttcol align="left">EST Functions</ttcol>
<ttcol align="left">EST-coaps implementation</ttcol>
<c> /cacerts </c> <c> MUST </c>
<c> /simpleenroll </c> <c> MUST </c>
<c> /simplereenroll </c> <c> MUST </c>
<c> /fullcmc </c> <c> Not specified </c>
<c> /serverkeygen </c> <c> OPTIONAL </c>
<c> /csrattrs </c> <c> OPTIONAL </c>
</texttable>
</section> <!-- Required/optional Functions --> <t>Throughout this document, the example root resource of /est is used.
</t>
</section>
<section anchor="format" title ="Payload formats"> <section anchor="implementation" numbered="true" toc="default">
<name>Mandatory/Optional EST Functions</name>
<t>
This specification contains a set of required-to-implement functions, optional
functions, and not-specified functions. The unspecified functions are deemed
too expensive for low-resource devices in payload and calculation times.</t>
<t> <xref target="est-implementation" format="default"/> specifies the
mandatory-to-implement or optional implementation of the EST-coaps
functions. Discovery of the existence of optional functions is
described in <xref target="discovery" format="default"/>.</t>
<table anchor="est-implementation" align="center">
<name>List of EST-coaps Functions</name>
<thead>
<tr>
<th align="left">EST Functions</th>
<th align="left">EST-coaps Implementation</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"> /cacerts </td>
<td align="left"> <bcp14>MUST</bcp14> </td>
</tr>
<tr>
<td align="left"> /simpleenroll </td>
<td align="left"> <bcp14>MUST</bcp14> </td>
</tr>
<tr>
<td align="left"> /simplereenroll </td>
<td align="left"> <bcp14>MUST</bcp14> </td>
</tr>
<tr>
<td align="left"> /fullcmc </td>
<td align="left"> Not specified </td>
</tr>
<tr>
<td align="left"> /serverkeygen </td>
<td align="left"> <bcp14>OPTIONAL</bcp14> </td>
</tr>
<tr>
<td align="left"> /csrattrs </td>
<td align="left"> <bcp14>OPTIONAL</bcp14> </td>
</tr>
</tbody>
</table>
</section>
<t>EST-coaps is designed for low-resource devices and hence does not need <section anchor="format" numbered="true" toc="default">
<name>Payload Formats</name>
<t>EST-coaps is designed for low-resource devices; hence, it does not ne
ed
to send Base64-encoded data. Simple binary is more efficient (30% small er payload for DER-encoded ASN.1) and to send Base64-encoded data. Simple binary is more efficient (30% small er payload for DER-encoded ASN.1) and
well supported by CoAP. Thus, the payload for a given Media-Type follow well supported by CoAP. Thus, the payload for a given media type follow
s the ASN.1 s the ASN.1
structure of the Media-Type and is transported in binary format.</t> structure of the media type and is transported in binary format.</t>
<!-- <xref target="cborpair"/> <xref target="format"/> specifies the paylo
ad
structure when multiple Media-Types
are present in the payload.-->
<t>The Content-Format (HTTP Content-Type equivalent) of the CoAP message d <t>The Content-Format (HTTP Content-Type equivalent) of the CoAP message
etermines which determines which EST message is transported in the CoAP payload. The
EST message is transported in the CoAP payload. The Media-Types specifi media types specified in the HTTP Content-Type header field (<xref
ed in the HTTP target="RFC7030" sectionFormat="of" section="3.2.4"/>) are specified by
Content-Type header field (Section 3.2.2 of <xref target="RFC7030"/>) a the Content-Format Option (12) of CoAP. The combination of URI-Path and
re Content-Format in EST-coaps <bcp14>MUST</bcp14> map to an allowed
specified by the Content-Format Option (12) of CoAP. The combination of combination of URI and media type in EST. The required Content-Formats
URI-Path for these requests and response messages are defined in <xref
and Content-Format in EST-coaps MUST map to an allowed combination of U target="Content-Formats" format="default"/>. The CoAP response codes are
RI and defined in <xref target="codes" format="default"/>.</t>
Media-Type in EST. The required Content-Formats for these requests and
response messages are defined in <xref target="Content-Formats"/>. The
CoAP response
codes are defined in <xref target="codes"/>.</t>
<!-- CoAP doesn't have a mechanism for negotiating the <t>Content-Format 287 can be used in place of 281 to carry a single
content formats of representations embedded in application/multipart-core certificate instead of a PKCS #7 container
representations. --> in a /crts, /sen, /sren, or /skg response.
<t>Content-Format TBD287 can be used in place of 281 to carry a single Content-Format 281 <bcp14>MUST</bcp14> be supported by EST-coaps servers.
certificate instead of a PKCS#7 container Servers <bcp14>MAY</bcp14> also support Content-Format 287.
in a /crts, /sen, /sren or /skg response.
Content-Format 281 MUST be supported by EST-coaps servers.
Servers MAY also support Content-Format TBD287.
It is up to the client to support only Content-Format 281, It is up to the client to support only Content-Format 281,
TBD287 or both. 287 or both.
The client will use The client will use
a COAP Accept Option in the request to express the a CoAP Accept Option in the request to express the
preferred response Content-Format. If an Accept Option is preferred response Content-Format. If an Accept Option is
not included in the request, the client is not expressing not included in the request, the client is not expressing
any preference and the server SHOULD choose format 281.</t> any preference and the server <bcp14>SHOULD</bcp14> choose format 281.</t>
<!--If the
preferred Content-Format cannot be returned, the server
MUST send a 4.06 (Not Acceptable) response, unless another
error code takes precedence for the response
<xref target="RFC7252"/>. -->
<t>Content-Format 286 is used in /sen, /sren and /skg requests <t>Content-Format 286 is used in /sen, /sren, and /skg requests
and 285 in /att responses. </t> and 285 in /att responses. </t>
<!-- <Section anchor="cborpair" title="Content-Format application/multipar
t-core"> -->
<!-- <t><spanx style="strong">application/multipart-core</spanx> </t>--
>
<!--The collection is encoded as a <xref target="RFC7049">CBOR array</x
ref> with
an even number of elements. The second, fourth, sixth, etc. element is a
binary
string containing a representation. The first, third, fifth, etc. element
is an
unsigned integer specifying the Content-Format identifier of the consecut
ive representation. -->
<t> <t>
A representation with Content-Format identifier 62 contains a collection o A representation with Content-Format identifier 62 contains a collection
f representations of representations along with their respective Content-Format. The
along with their respective Content-Format. The Content-Format identifies Content-Format identifies the media type application/multipart-core
the specified in <xref target="RFC8710"
Media-Type application/multipart-core specified in <xref target="I-D.ietf format="default"/>. For example, a collection, containing two
-core-multipart-ct"/>. representations in response to an EST-coaps server-side key generation
For example, a collection, containing two representations in response to /skg request, could include a private key in PKCS #8 <xref
a EST-coaps server-side target="RFC5958" format="default"/> with Content-Format identifier 284
key generation /skg request, could include a private key in PKCS#8 <xref (0x011C) and a single certificate in a PKCS #7 container with
target="RFC5958"/> Content-Format identifier 281 (0x0119). Such a collection would look
with Content-Format identifier 284 (0x011C) and a single certificate in a like [284,h'0123456789abcdef', 281,h'fedcba9876543210'] in diagnostic
PKCS#7 container Concise Binary Object Representation (CBOR) notation. The serialization of
with Content-Format identifier 281 (0x0119). such CBOR content would be:</t>
Such a collection would look like [284,h'0123456789abcdef', 281,h'fedcba9 <figure>
876543210'] <name>Multipart /skg Response Serialization</name>
in diagnostic CBOR notation. The serialization of such CBOR content would <sourcecode type="cbor-pretty"><![CDATA[
be </t>
<figure title="Multipart /skg response serialization"><artwork>
<![CDATA[
84 # array(4) 84 # array(4)
19 011C # unsigned(284) 19 011C # unsigned(284)
48 # bytes(8) 48 # bytes(8)
0123456789ABCDEF # "\x01#Eg\x89\xAB\xCD\xEF" 0123456789ABCDEF # "\x01#Eg\x89\xAB\xCD\xEF"
19 0119 # unsigned(281) 19 0119 # unsigned(281)
48 # bytes(8) 48 # bytes(8)
FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10" FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10"
]]></artwork></figure> ]]></sourcecode>
</figure>
<t>When the client makes an /skc request the certificate returned with <t>When the client makes an /skc request, the certificate returned
the private key with the private key is a single X.509 certificate (not a PKCS #7
is a single X.509 certificate (not a PKCS#7 container) with Content-For container) with Content-Format identifier 287 (0x011F) instead of
mat identifier 281. In cases where the private key is encrypted with Cryptographic
TBD287 (0x011F) instead of 281. Message Syntax (CMS) (as explained in <xref target="serverkey"
In cases where the private key is encrypted with CMS (as format="default"/>), the Content-Format identifier is 280 (0x0118)
explained in <xref target="serverkey"/>) the Content-Format identifier instead of 284. The Content-Format used in the response is summarized
is in <xref target="skg-skc" format="default"/>.</t>
280 (0x0118) instead of 284. The content format used in the response is <table anchor="skg-skc" align="center">
summarized in <xref target="skg-skc"/>.</t> <name>Response Content-Formats for /skg and /skc</name>
<thead>
<texttable anchor="skg-skc" title="response content formats for skg and skc"> <tr>
<ttcol align="left">Function</ttcol> <th align="left">Function</th>
<ttcol align="left">Response part 1</ttcol> <th align="left">Response, Part 1</th>
<ttcol align="left">Response part 2</ttcol> <th align="left">Response, Part 2</th>
</tr>
<c> /skg </c> <c> 284 </c> <c> 281</c> </thead>
<c> /skc </c> <c> 280 </c> <c> TBD287</c> <tbody>
</texttable> <tr>
<td align="left"> /skg </td>
<td align="left"> 284 </td>
<td align="left"> 281</td>
</tr>
<tr>
<td align="left"> /skc </td>
<td align="left"> 280 </td>
<td align="left"> 287</td>
</tr>
</tbody>
</table>
<t>The key and certificate representations are DER-encoded ASN.1,
in its binary form. An example is shown in <xref target="appskg" format="defa
ult"/>.</t>
<t>The key and certificate representations are DER-encoded ASN.1, </section>
in its native binary form. An example is shown in <xref target="appskg"/>.</t
>
<!-- </section> --> <!--Content-Format application/multipart-core --> <section numbered="true" toc="default">
<name>Message Bindings</name>
<t>The general EST-coaps message characteristics are:
</t>
<ul spacing="normal">
</section> <!-- Payload format --> <li>EST-coaps servers sometimes need to provide delayed
responses, which are preceded by an immediately returned
empty ACK or an ACK containing response code 5.03 as
explained in <xref target="pending" format="default"/>.
Thus, it is <bcp14>RECOMMENDED</bcp14> for implementers to
send EST-coaps requests in Confirmable (CON) CoAP
messages.</li>
<li>The CoAP Options used are Uri-Host, Uri-Path, Uri-Port,
Content-Format, Block1, Block2, and Accept. These CoAP Options are
used to communicate the HTTP fields specified in the EST REST
messages. The Uri-host and Uri-Port Options can be omitted from the
CoAP message sent on the wire. When omitted, they are logically
assumed to be the transport protocol destination address and port,
respectively. Explicit Uri-Host and Uri-Port Options are typically
used when an endpoint hosts multiple virtual servers and uses the
Options to route the requests accordingly. Other CoAP Options
should be handled in accordance with <xref target="RFC7252"
format="default"/>.</li>
<section title="Message Bindings"> <li>EST URLs are HTTPS based (https://); in CoAP, these are assumed
<t>The general EST-coaps message characteristics are: to be translated to CoAPS (coaps://).</li>
<list style="symbols"> </ul>
<!-- <t>The Ver, TKL, Token, and Message ID values of the CoAP header <t><xref target="est-uri" format="default"/> provides the mapping from t
are not affected by EST.</t> --> he EST URI path to the EST-coaps URI path.
<t>EST-coaps servers sometimes need to provide delayed response <xref target="messagebindings" format="default"/> includes some
s which are preceded by an immediately returned empty ACK practical examples of EST messages
or an ACK containing response code 5.03 as explained in <xref t
arget="pending"/>.
Thus, it is RECOMMENDED for implementers to send EST-coaps requ
ests in confirmable CON CoAP messages.</t>
<t>The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-For
mat,
Block1, Block2, and Accept.
These CoAP Options are used to communicate the HTTP fields spec
ified in the EST
REST messages. The Uri-host and Uri-Port Options can be omitted
from the COAP
message sent on the wire. When omitted, they are logically assu
med to be the transport protocol destination address and port respectively. Expl
icit Uri-Host and Uri-Port Options are typically used when an endpoint hosts mul
tiple virtual
servers and uses the Options to route the requests accordingly.
Other COAP Options should be handled in
accordance with <xref target="RFC7252"/>.</t>
<!-- Alternatively, if a UDP port to a server is blocked,
someone could send the DTLS packets to a known open port
on the server and use the Uri-Port to convey the intended port
he is attempting to reach. -->
<t>EST URLs are HTTPS based (https://), in CoAP these are assum
ed to be translated
to CoAPS (coaps://)</t>
</list></t>
<t><xref target="est-uri"/> provides the mapping from the EST URI path t
o the EST-coaps URI path.
<xref target="messagebindings"/> includes some practical example
s of EST messages
translated to CoAP.</t> translated to CoAP.</t>
</section> <!-- Message bindings --> </section>
<section anchor="codes" title="CoAP response codes"> <section anchor="codes" numbered="true" toc="default">
<t>Section 5.9 of <xref target="RFC7252"/> and Section 7 of <xref target=" <name>CoAP Response Codes</name>
RFC8075"/> <t><xref target="RFC7252" sectionFormat="of" section="5.9"/> and <xref
specify the mapping of HTTP response codes to CoAP response codes. target="RFC8075" sectionFormat="of" section="7"/> specify the mapping
The success code in response to an EST-coaps GET request (/crts, /att), of HTTP response codes to CoAP response codes. The success code in
is 2.05. Similarly, 2.04 is used in successful response to EST-coaps PO response to an EST-coaps GET request (/crts, /att) is 2.05. Similarly,
ST requests (/sen, /sren, /skg, /skc).</t> 2.04 is used in successful response to EST-coaps POST requests (/sen,
<!--2.01 Making 2.04 based on comment from Esko https://github.com/SanK /sren, /skg, /skc).</t>
umar2015/EST-coaps/issues/145#issuecomment-497029846 -->
<!-- Removing because we now use 2.04 based on comment
from Esko https://github.com/SanKumar2015/EST-coaps/issues/145#issuecommen
t-497029846
Section 7 of
<xref target="RFC8075"/> maps 2.02 (Deleted) or 2.04 (Changed) to an HT
TP
200 OK response, but 2.01 (Created) is more suitable for the creation
of certificates in the context of EST-coaps. -->
<t>EST makes use of HTTP 204 or 404 responses when a resource is not av ailable <t>EST makes use of HTTP 204 or 404 responses when a resource is not av ailable
for the client. In EST-coaps 2.04 is used in response to for the client. In EST-coaps, 2.04 is used in response to
a POST (/sen, /sren, /skg, /skc). 4.04 is a POST (/sen, /sren, /skg, /skc). 4.04 is
used when the resource is not available for the client. </t> used when the resource is not available for the client. </t>
<t>HTTP response code 202 with a Retry-After header field
<t>HTTP response code 202 with a Retry-After header field in <xref target="RFC7030" format="default"/> has no equivalent in CoAP.
in <xref target="RFC7030"/> has no equivalent in CoAP.
HTTP 202 with Retry-After is used in EST for delayed server HTTP 202 with Retry-After is used in EST for delayed server
responses. <xref target="pending"/> specifies how EST-coaps responses. <xref target="pending" format="default"/> specifies how EST- coaps
handles delayed messages with 5.03 responses with a Max-Age Option.</t> handles delayed messages with 5.03 responses with a Max-Age Option.</t>
<!-- In case a CoAP Option is unrecognized and <t>Additionally, EST's HTTP 400, 401, 403, 404, and 503 status codes ha
critical, the server is expected to return a 4.02 (Bad Option). ve
Moreover, if the Content-Format requested in the client their equivalent CoAP 4.00, 4.01, 4.03, 4.04, and 5.03 response codes
Accept Option, is not supported the server MUST return a 4.06 (Not Acce
ptable),
unless another error code takes precedence for the response.-->
<t>Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes hav
e
their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes
in EST-coaps. in EST-coaps.
<xref target="estcoaps-codes"/> summarizes the EST-coaps response codes <xref target="estcoaps-codes" format="default"/> summarizes the EST-coa
. </t> ps response codes. </t>
<table anchor="estcoaps-codes" align="center">
<texttable anchor="estcoaps-codes" title="EST-coaps response codes"> <name>EST-coaps Response Codes</name>
<ttcol align="left">operation</ttcol> <thead>
<ttcol align="left">EST-coaps response code</ttcol> <tr>
<ttcol align="left">Description</ttcol> <th align="left">Operation</th>
<th align="left">EST-coaps Response Code</th>
<c>/crts, /att</c> <c>2.05</c> <c>Success. Certs included in the re <th align="left">Description</th>
sponse payload.</c> </tr>
<c> </c> <c>4.xx / 5.xx</c> <c>Failure.</c> </thead>
<c>/sen, /skg, /sren, /skc</c> <c>2.04 <tbody>
<!-- 2.01 Making 2.04 based on comment from Esko https://github. <tr>
com/SanKumar2015/EST-coaps/issues/145#issuecomment-497029846 --> <td align="left">/crts, /att</td>
</c> <c>Success. Cert in <td align="left">2.05</td>
cluded in the response payload.</c> <td align="left">Success. Certs included in the response payload.<
<!-- Removing because we now always use 2.04 based on comment fr /td>
om Esko https://github.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497029 </tr>
846 <tr>
<c> </c> <c>2.04</c> <c>Success. Cert include <td align="left"> </td>
d in the delayed separate response payload. </c> --> <td align="left">4.xx / 5.xx</td>
<c> </c> <c>5.03</c> <c>Retry in Max-Age Opti <td align="left">Failure.</td>
on time.</c> </tr>
<c> </c> <c>4.xx / 5.xx</c> <c>Failure.</c> <tr>
</texttable> <td align="left">/sen, /skg, /sren, /skc</td>
<td align="left">2.04
</section> <!-- CoAP response codes --> </td>
<td align="left">Success. Cert included in the response payload.</
<section anchor="fragment" title="Message fragmentation"> td>
<t>DTLS defines fragmentation only for the handshake and not for secure da </tr>
ta exchange (DTLS records). <xref target="RFC6347"/> states that to avoid using <tr>
IP fragmentation, which involves error-prone datagram reconstitution, invokers o <td align="left"> </td>
f the DTLS record layer should size DTLS records so that they fit within any Pat <td align="left">5.03</td>
h MTU estimates obtained from the record layer. In addition, invokers residing o <td align="left">Retry in Max-Age Option time.</td>
n a 6LoWPAN over IEEE 802.15.4 <xref target="ieee802.15.4"/> network are recomme </tr>
nded to size CoAP messages such that each DTLS record will fit within one or two <tr>
IEEE 802.15.4 frames.</t> <td align="left"> </td>
<td align="left">4.xx / 5.xx</td>
<td align="left">Failure.</td>
</tr>
</tbody>
</table>
</section>
<!-- From <xref target="RFC0791"/> follows that the absolute minimum value <section anchor="fragment" numbered="true" toc="default">
of the IP MTU for IPv4 is as low as 68 bytes, which would leave only 40 bytes m <name>Message Fragmentation</name>
inus security overhead for a UDP payload. --> <t>DTLS defines fragmentation only for the handshake and not for
<t>That is not always possible in EST-coaps. Even though ECC certificates secure data exchange (DTLS records). <xref target="RFC6347"
are small in size, they can vary greatly based on signature algorithms, key size format="default"/> states that to avoid using IP fragmentation, which
s, and Object Identifier (OID) fields used. For 256-bit curves, common ECDSA cer involves error-prone datagram reconstitution, invokers of the DTLS
t sizes are 500-1000 bytes which could fluctuate further based on the algorithms record layer should size DTLS records so that they fit within any Path
, OIDs, Subject Alternative Names (SAN) and cert fields. For 384-bit curves, ECD MTU estimates obtained from the record layer. In addition, invokers
SA certificates increase in size and can sometimes reach 1.5KB. Additionally, th residing on 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks
ere are times when the EST cacerts response from the server can include multiple )
certificates that amount to large payloads. Section 4.6 of CoAP <xref target="R over IEEE 802.15.4 networks <xref target="IEEE802.15.4"
FC7252"/> describes the possible payload sizes: "if nothing is known about the s format="default"/> are recommended to size CoAP messages such
ize of the headers, good upper bounds are 1152 bytes for the message size and 10 that each DTLS record will fit within one or two IEEE 802.15.4
24 bytes for the payload size". Section 4.6 of <xref target="RFC7252"/> also sug frames.</t>
gests that IPv4 implementations may want to limit themselves to more conservativ
e IPv4 datagram sizes such as 576 bytes. Even with ECC, EST-coaps messages can s
till exceed MTU sizes on the Internet or 6LoWPAN <xref target="RFC4919"/> (Secti
on 2 of <xref target="RFC7959"/>). EST-coaps needs to be able to fragment messag
es into multiple DTLS datagrams.</t>
<t>To perform fragmentation in CoAP, <xref target="RFC7959"/> specifies <t>That is not always possible in EST-coaps. Even though ECC
the Block1 Option for fragmentation of the request payload and the Block2 Optio certificates are small in size, they can vary greatly based on signature
n for fragmentation of the return payload of a CoAP flow. As explained in Sectio algorithms, key sizes, and Object Identifier (OID) fields used. For
n 1 of <xref target="RFC7959"/>, block-wise transfers should be used in Confirma 256-bit curves, common Elliptic Curve Digital Signature Algorithm
ble CoAP messages to avoid the exacerbation of lost blocks. EST-coaps servers MU (ECDSA) cert sizes are 500-1000 bytes, which could fluctuate further
ST implement Block1 and Block2. EST-coaps clients MUST implement Block2. EST-coa based on the algorithms, OIDs, Subject Alternative Names (SANs), and cert
ps clients MUST implement Block1 only if they are expecting to send EST-coaps re fields. For 384-bit curves, ECDSA certificates increase in size and can
quests with a packet size that exceeds the Path MTU. </t><!-- <xref target="RFC7 sometimes reach 1.5KB. Additionally, there are times when the EST
959"/> defines SZX in the Block Option fields. SZX is used to convey the size of cacerts response from the server can include multiple certificates that
the blocks in the requests or responses. The EST-coaps client MAY specify the B amount to large payloads. <xref target="RFC7252" sectionFormat="of"
lock1 and Block2 sizes for the server and MAY process Block2 sizes from the serv section="4.6"/> (CoAP) describes the possible payload sizes: "if nothing
er. The EST-coaps server MAY specify the Block2 size for the client and MAY proc is known about the size of the headers, good upper bounds are 1152 bytes
ess Block1 and Block2 sizes from the client.--> for the message size and 1024 bytes for the payload size". <xref
target="RFC7252" sectionFormat="of" section="4.6"/> also suggests that
IPv4 implementations may want to limit themselves to more conservative
IPv4 datagram sizes such as 576 bytes. Even with ECC, EST-coaps messages
can still exceed MTU sizes on the Internet or 6LoWPAN <xref
target="RFC4919" format="default"/> (<xref target="RFC7959"
sectionFormat="of" section="2"/>). EST-coaps needs to be able to
fragment messages into multiple DTLS datagrams.</t>
<t>To perform fragmentation in CoAP, <xref target="RFC7959"
format="default"/> specifies the Block1 Option for fragmentation of
the request payload and the Block2 Option for fragmentation of the
return payload of a CoAP flow. As explained in <xref target="RFC7959"
sectionFormat="of" section="1"/>, block-wise transfers should be used
in Confirmable CoAP messages to avoid the exacerbation of lost
blocks. EST-coaps servers <bcp14>MUST</bcp14> implement Block1 and
Block2. EST-coaps clients <bcp14>MUST</bcp14> implement
Block2. EST-coaps clients <bcp14>MUST</bcp14> implement Block1 only if
they are expecting to send EST-coaps requests with a packet size that
exceeds the path MTU. </t>
<t><xref target="RFC7959"/> also defines Size1 and Size2 Options to provid <t><xref target="RFC7959" format="default"/> also defines Size1 and
e size information about the resource representation in a request and response. Size2 Options to provide size information about the resource
EST-client and server MAY support Size1 and Size2 Options. </t><!-- A Size1 resp representation in a request and response. The EST-coaps client and server
onse MAY be parsed by the EST-coaps client as a size indication of the resource <bcp14>MAY</bcp14> support Size1 and Size2 Options. </t>
in the server Block2 responses or by the server as a request for a size estimate
by the client. Similarly, the Size2 Option defined in <xref target="RFC7959"/>
MAY be parsed by the server as an indication of the size of the resource carried
in Block1 Options and by the client in the 4.13 (Request Entity Too Large) resp
onse as a maximum request size expected by the server.-->
<t>Examples of fragmented EST-coaps messages are shown in <xref target="bl <t>Examples of fragmented EST-coaps messages are shown in <xref target="bl
ockexamples"/>.</t> ockexamples" format="default"/>.</t>
</section> <!-- Message fragmentation --> </section>
<section anchor="pending" title="Delayed Responses"> <section anchor="pending" numbered="true" toc="default">
<t>Server responses can sometimes be delayed. According to Section 5.2.2 o <name>Delayed Responses</name>
f <t>Server responses can sometimes be delayed. According to <xref
<xref target="RFC7252" />, a slow server can acknowledge the request target="RFC7252" sectionFormat="of" section="5.2.2"/>, a slow server
and respond later with the requested resource representation. In partic can acknowledge the request and respond later with the requested
ular, resource representation. In particular, a slow server can respond to
a slow server can respond to an EST-coaps enrollment request with an em an EST-coaps enrollment request with an empty ACK with code 0.00
pty ACK with code 0.00, before sending the certificate to the client after a short delay. If
before sending the certificate to the client after a short delay. If the c the certificate response is large, the server will need more than one
ertificate Block2 block to transfer it. </t>
response is large, the server will need more than one Block2 block to t <t>This situation is shown in <xref target="fig-est-short-wait"
ransfer it. </t> format="default"/>. The client sends an enrollment request that uses
N1+1 Block1 blocks. The server uses an empty 0.00 ACK to announce the
delayed response, which is provided later with 2.04 messages
containing N2+1 Block2 Options. The first 2.04 is a Confirmable
message that is acknowledged by the client. Onwards, the client
acknowledges all subsequent Block2 blocks. The notation of <xref
target="fig-est-short-wait" format="default"/> is explained in <xref
target="cacertsblock" format="default"/>.</t>
<figure anchor="fig-est-short-wait">
<name>EST-coaps Enrollment with Short Wait</name>
<t>This <artwork name="" type="" align="left" alt=""><![CDATA[
situation is shown in <xref target="fig-est-short-wait"/>. The client s POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256)
ends an enrollment {CSR (frag# 1)} -->
request that uses N1+1 Block1 blocks. The server uses an empty 0.00 ACK
to announce
the delayed response which is provided later with 2.04 messages contain
ing N2+1 Block2 Options.
The first 2.04 is a confirmable message that is acknowledged by the cli
ent.
Onwards, the client acknowledges all subsequent Block2 blocks. The nota
tion of <xref target = "fig-est-short-wait"/> is explained in <xref target="cace
rtsblock"/>.</t>
<figure title="EST-COAP enrollment with short wait"
anchor="fig-est-short-wait"><artwork>
<![CDATA[
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
<-- (ACK) (1:0/1/256) (2.31 Continue) <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256)
{CSR (frag# 2)} -->
<-- (ACK) (1:1/1/256) (2.31 Continue) <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256)
{CSR (frag# N1+1)}-->
<-- (0.00 empty ACK) <-- (0.00 empty ACK)
| |
... Short delay before the certificate is ready ... ... Short delay before the certificate is ready ...
| |
<-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)} <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed)
(ACK) --> {Cert resp (frag# 1)}
(ACK) -->
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)} <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)}
]]></artwork></figure> ]]></artwork>
</figure>
<t>If the server is very slow (for example, manual intervention <t>If the server is very slow (for example, manual intervention is
is required which would take minutes), required, which would take minutes), it <bcp14>SHOULD</bcp14> respond
it SHOULD respond with an ACK containing response code 5.03 (Service unava with an ACK containing response code 5.03 (Service unavailable) and a
ilable) and a Max-Age Max-Age Option to indicate the time the client <bcp14>SHOULD</bcp14>
Option to indicate the time the client SHOULD wait before sending another wait before sending another request to obtain the content. After a
request to obtain the content. After a delay of Max-Age, delay of Max-Age, the client <bcp14>SHOULD</bcp14> resend the
the client SHOULD resend the identical CSR to the server. identical CSR to the server. As long as the server continues to
As long as the server continues to respond with response code 5.03 respond with response code 5.03 (Service Unavailable) with a Max-Age
(Service Unavailable) with a Max-Age Option, the client Option, the client will continue to delay for Max-Age and then resend
will continue to delay for Max-Age and then resend the the enrollment request until the server responds with the certificate
enrollment request until the server or the client abandons the request due to policy or other reasons. </t>
responds with the certificate or the client abandons the request for po <t>To demonstrate this scenario, <xref target="fig-est-long-wait"
licy or other reasons. </t> format="default"/> shows a client sending an enrollment request that
uses N1+1 Block1 blocks to send the CSR to the server. The server
needs N2+1 Block2 blocks to respond but also needs to take a long
delay (minutes) to provide the response. Consequently, the server uses
a 5.03 ACK response with a Max-Age Option. The client waits for a
period of Max-Age as many times as it receives the same 5.03 response
and retransmits the enrollment request until it receives a certificate
in a fragmented 2.04 response. </t>
<t>To demonstrate this scenario, <xref target="fig-est-long-wait"/> shows <figure anchor="fig-est-long-wait">
a client sending an enrollment <name>EST-coaps Enrollment with Long Wait</name>
request that uses N1+1 Block1 blocks to send the CSR to the server. The
server needs
N2+1 Block2 blocks to respond, but also needs to take a long delay (minute
s) to provide
the response. Consequently, the server uses a 5.03 ACK response with a Max
-Age Option. The client
waits for a period of Max-Age as many times as it receives the same 5.0
3 response and retransmits
the enrollment request until it receives a certificate in a fragmented 2.0
4 response. </t> <!-- 2.01 Making 2.04 based on comment from Esko https://githu
b.com/SanKumar2015/EST-coaps/issues/145#issuecomment-497029846 -->
<figure title="EST-COAP enrollment with long wait" <artwork name="" type="" align="left" alt=""><![CDATA[
anchor="fig-est-long-wait"><artwork> POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256)
<![CDATA[ {CSR (frag# 1)} -->
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
<-- (ACK) (1:0/1/256) (2.31 Continue) <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256)
{CSR (frag# 2)} -->
<-- (ACK) (1:1/1/256) (2.31 Continue) <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256)
{CSR (frag# N1+1)}-->
<-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age)
| |
| |
... Client tries again after Max-Age with identical payload ... ... Client tries again after Max-Age with identical payload ...
| |
| |
POST [2001:db8::2:1]:61616/est/sen(CON)(1:0/1/256){CSR (frag# 1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:0/1/256)
{CSR (frag# 1)}-->
<-- (ACK) (1:0/1/256) (2.31 Continue) <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256)
{CSR (frag# 2)} -->
<-- (ACK) (1:1/1/256) (2.31 Continue) <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256)
{CSR (frag# N1+1)}-->
| |
... Immediate response when certificate is ready ... ... Immediate response when certificate is ready ...
| |
<-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)} <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed)
{Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)} <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)}
]]></artwork></figure> ]]></artwork>
</figure>
<!-- <t>Comparing <xref target="fig-est-multiple-block"/> with <xref targe </section>
t="fig-est-long-wait"/> we
can see all the extra requests in the latter case after the Max-Age wai
t-time.</t> -->
</section> <!-- Delayed Responses -->
<section anchor="serverkey" title="Server-side Key Generation"> <section anchor="serverkey" numbered="true" toc="default">
<t>Private keys can be generated on the server to support <name>Server-Side Key Generation</name>
scenarios where serer-side key generation is needed. Such scenarios <t>Private keys can be generated on the server to support
scenarios where server-side key generation is needed. Such scenarios
include those where it is considered more secure to generate the include those where it is considered more secure to generate the
long-lived, random private key that identifies the client at the server , long-lived, random private key that identifies the client at the server ,
or where the resources spent to generate a random private key at the or where the resources spent to generate a random private key at the
client are considered scarce, or where the security policy requires client are considered scarce, or where the security policy requires
that the certificate public and corresponding private keys are that the certificate public and corresponding private keys are
centrally generated and controlled. As always, it is necessary centrally generated and controlled. As always, it is necessary
to use proper random numbers in various protocols such as (D)TLS (<xref to use proper random numbers in various protocols such as (D)TLS (<xref
target="sec-est"/>).</t> target="sec-est" format="default"/>).</t>
<t>When requesting server-side key generation, the client
<t>When requesting server-side key generation, the client
asks for the server or proxy to generate the private key and the certifica te, asks for the server or proxy to generate the private key and the certifica te,
which are transferred back to the client in the server-side key generation which are transferred back to the client in the server-side key generation
response. In all respects, the server treats the CSR as it would treat any response. In all respects, the server treats the CSR as it would treat any
enroll or re-enroll CSR; the only distinction here is that the server enroll or re-enroll CSR; the only distinction here is that the server
MUST ignore the public key values and signature in the CSR. These <bcp14>MUST</bcp14> ignore the public key values and signature in the CSR.
are included in the request only to allow re-use of existing These
are included in the request only to allow reuse of existing
codebases for generating and parsing such requests.</t> codebases for generating and parsing such requests.</t>
<t>The client /skg request is for a certificate in a PKCS #7 container
<t>The client /skg request is for a certificate in a PKCS#7 container
and private key in two application/multipart-core elements. and private key in two application/multipart-core elements.
Respectively, an /skc request is for a single application/pkix-cert Respectively, an /skc request is for a single application/pkix-cert
certificate and a private key. certificate and a private key.
The private key Content-Format requested by the client is indicated in the The private key Content-Format requested by the client is indicated in the
PKCS#10 CSR request. If the request contains SMIMECapabilities and PKCS #10 CSR request. If the request contains SMIMECapabilities and
DecryptKeyIdentifier or AsymmetricDecryptKeyIdentifier the client DecryptKeyIdentifier or AsymmetricDecryptKeyIdentifier, the client
is expecting Content-Format 280 for the private key. is expecting Content-Format 280 for the private key.
Then this private key is encrypted symmetrically or asymmetrically as Then, this private key is encrypted symmetrically or asymmetrically
per <xref target="RFC7030" />. per <xref target="RFC7030" format="default"/>.
The symmetric key or the asymmetric keypair establishment method is The symmetric key or the asymmetric keypair establishment method is
out of scope of this specification. out of scope of this specification.
A /skg or /skc request with a CSR without SMIMECapabilities
expects an application/multipart-core with an unencrypted PKCS#8 privat An /skg or /skc request with a CSR without SMIMECapabilities
e expects an application/multipart-core with an unencrypted PKCS #8 priva
te
key with Content-Format 284.</t> key with Content-Format 284.</t>
<t>
The EST-coaps server-side key generation response is returned with
Content-Format application/multipart-core <xref
target="RFC8710" format="default"/> containing
a CBOR array with four items (<xref target="format"
format="default"/>). The two representations (each consisting of
two CBOR array items) do not have to be in a particular order
since each representation is preceded by its Content-Format ID.
Depending on the request, the private key can be in unprotected
PKCS #8 format <xref target="RFC5958" format="default"/>
(Content-Format 284) or protected inside of CMS SignedData
(Content-Format 280). The SignedData, placed in the outermost
container, is signed by the party that generated the private key,
which may be the EST server or the EST CA. SignedData placed
within the Enveloped Data does not need additional signing as
explained in <xref target="RFC7030" sectionFormat="of"
section="4.4.2"/>. In summary, the symmetrically encrypted key is
included in the encryptedKey attribute in a KEKRecipientInfo
structure. In the case where the asymmetric encryption key is
suitable for transport key operations, the generated private key is
encrypted with a symmetric key. The symmetric key itself is
encrypted by the client-defined (in the CSR) asymmetric public key
and is carried in an encryptedKey attribute in a
KeyTransRecipientInfo structure. Finally, if the asymmetric
encryption key is suitable for key agreement, the generated
private key is encrypted with a symmetric key. The symmetric key
itself is encrypted by the client defined (in the CSR) asymmetric
public key and is carried in a recipientEncryptedKeys attribute
in a KeyAgreeRecipientInfo. </t>
<t> <t><xref target="RFC7030" format="default"/> recommends the use of
The EST-coaps server-side key generation response is returned with Co additional encryption of the returned private key. For the context
ntent-Format of this specification, clients and servers that choose to support
application/multipart-core <xref target="I-D.ietf-core-multipart- server-side key generation <bcp14>MUST</bcp14> support unprotected
ct"/> (PKCS #8) private keys (Content-Format 284). Symmetric or asymmetric
containing a CBOR array with four items (<xref target="format"/>) encryption of the private key (CMS EnvelopedData, Content-Format
. 280) <bcp14>SHOULD</bcp14> be supported for deployments where
The two representations (each consisting of two CBOR array items) do no end-to-end encryption is needed between the client and a
t have to be in a particular order since each representation is server. Such cases could include architectures where an entity
preceded by its Content-Format ID. between the client and the CA terminates the DTLS connection
Depending on the request, the private key can be in unprotected P (Registrar in <xref target="RAfig" format="default"/>). Though
KCS#8 <xref target="RFC5958"/> <xref target="RFC7030" format="default"/> strongly recommends that
format (Content-Format 284) or protected inside of CMS SignedData clients request the use of CMS encryption on top of the TLS
(Content-Format 280). The SignedData, placed in the outermost con channel's protection, this document does not make such a
tainer, is signed by the party that recommendation; CMS encryption can still be used when mandated by
generated the private key, which may be the EST server or the use case. </t>
the EST CA. SignedData placed within the Enveloped Data does not
need additional signing as explained in Section 4.4.2
of <xref target="RFC7030" />. In summary, the symmetrically encry
pted key
is included in the encryptedKey attribute in a KEKRecipientInfo s
tructure.
In the case where the asymmetric encryption key is suitable for t
ransport key
operations the generated private key is encrypted with a symmetri
c key. The
symmetric key itself is encrypted by the client-defined (in the CSR) asy
mmetric public key
and is carried in an encryptedKey attribute in a KeyTransRecipien
tInfo structure.
Finally, if the asymmetric encryption key is suitable for key agr
eement,
the generated private key is encrypted with a symmetric key. The
symmetric key itself is encrypted by the client defined (in the C
SR) asymmetric public key and
is carried in an recipientEncryptedKeys attribute in a KeyAgreeRe
cipientInfo. </t>
<!-- The EnvelopedData is
returned in the response as an "application/pkcs7-mime" or "application-pkix_
cert" part with an
smime-type parameter of "server-generated-key" and a Content-
Transfer-Encoding of "Base64". -->
<t><xref target="RFC7030" /> recommends the use of additional encryptio </section>
n of the
returned private key. For the context of this specification, clients an
d servers
that choose to support server-side key generation MUST support unprotec
ted (PKCS#8)
private keys (Content-Format 284). Symmetric or asymmetric encryption of the
private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported
for deployments where end-to-end encryption is needed
between the client and a server. Such cases could include architectures
where an entity between the client and the CA terminates the DTLS conne
ction
(Registrar in <xref target="RAfig"/>).
Although <xref target="RFC7030"/> strongly recommends that clients req
uest the use of CMS encryption on top of the TLS channel's protection, this doc
ument does not make such a recommendation; CMS encryption can still be used whe
n mandated by the use-case. </t>
<!-- Panos: Commented this out. EST mandated two layers of encryption but
did not say how the extra encryption can be established. It is counter-intuitive
to say we don't trust the DTLS connection and we require more encryption on top
of it. Due to how hard it is to establish the keys for the extra encryption and
that if the DTLS channel is not secure we have bigger problems, I do not agree
this paragraph should be here. -->
<!--<t>Following <xref target="RFC7030"/>: "It is strongly RECOMMENDED tha
t the clients request that the returned private key be afforded the additional s
ecurity of the Cryptographic Message Syntax (CMS) EnvelopedData in addition to t
he TLS-provided security to protect against unauthorized disclosure."</t> -->
</section> <!-- Server-side Key Generation --> </section>
</section> <!-- protocol design-->
<section anchor="proxy" title="HTTPS-CoAPS Registrar"> <section anchor="proxy" numbered="true" toc="default">
<t>In real-world deployments, the EST server will not always reside within <name>HTTPS-CoAPS Registrar</name>
the CoAP boundary. The EST server can exist outside the constrained netwo <t>In real-world deployments, the EST server will not always reside within
rk the CoAP boundary. The EST server can exist outside the constrained netwo
in which case it will support TLS/HTTP instead of CoAPS. In such environm rk,
ents in which case it will support TLS/HTTP instead of CoAPS. In such environm
ents,
EST-coaps is used by the client within the CoAP boundary and TLS is used to EST-coaps is used by the client within the CoAP boundary and TLS is used to
transport the EST messages outside the CoAP boundary. A Registrar at the edge transport the EST messages outside the CoAP boundary. A Registrar at the edge
is required to operate between the CoAP environment and the external HTTP is required to operate between the CoAP environment and the external HTTP
network as shown in network as shown in
<xref target="RAfig"/>. </t> <xref target="RAfig" format="default"/>. </t>
<!-- <t>When not explicitly needed, it is RECOMMENDED to use direct connecti
ons between EST server and client</t> -->
<figure align="left" anchor="RAfig" title="EST-coaps-to-HTTPS Registrar a <figure anchor="RAfig">
t the CoAP boundary."><artwork><![CDATA[ <name>EST-coaps-to-HTTPS Registrar at the CoAP Boundary</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
Constrained Network Constrained Network
.------. .----------------------------. .------. .----------------------------.
| CA | |.--------------------------.| | CA | |.--------------------------.|
'------' || || '------' || ||
| || || | || ||
.------. HTTP .-----------------. CoAPS .-----------. || .------. HTTP .------------------. CoAPS .-----------. ||
| EST |<------->|EST-coaps-to-HTTPS|<------->| EST Client| || | EST |<------->|EST-coaps-to-HTTPS|<------->| EST Client| ||
|Server|over TLS | Registrar | '-----------' || |Server|over TLS | Registrar | '-----------' ||
'------' '-----------------' || '------' '------------------' ||
|| || || ||
|'--------------------------'| |'--------------------------'|
'----------------------------' '----------------------------'
]]></artwork></figure> ]]></artwork>
<t>The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream and </figure>
initiate EST connections over TLS upstream. The Registrar MUST authentica <t>The EST-coaps-to-HTTPS Registrar <bcp14>MUST</bcp14> terminate EST-coap
te s downstream and
and optionally authorize the client requests while it MUST be authenticat initiate EST connections over TLS upstream. The Registrar <bcp14>MUST</bc
ed p14> authenticate
and optionally authorize the client requests while it <bcp14>MUST</bcp14>
be authenticated
by the EST server or CA. The trust relationship between the Registrar by the EST server or CA. The trust relationship between the Registrar
and the EST server SHOULD be pre-established for the Registrar to proxy and the EST server <bcp14>SHOULD</bcp14> be pre-established for the Regis trar to proxy
these connections on behalf of various clients.</t> these connections on behalf of various clients.</t>
<t>When enforcing Proof-of-Possession (PoP) linking, the DTLS tls-unique
value of the (D)TLS session is used to prove that the private key
corresponding to the public key is in the possession of the client and wa
s used to
establish the connection as explained in <xref target="profile7925"/>.
The PoP linking information is lost between the
EST-coaps client and the EST server when a Registrar is present.
The EST server becomes aware of the
presence of a Registrar from its TLS client certificate that includes
id-kp-cmcRA <xref target="RFC6402"/> extended key usage extension (EKU).
As
explained in Section 3.7 of <xref target="RFC7030"/>, the "EST server SHO
ULD
apply an authorization policy consistent with a Registrar client. For exa
mple,
it could be configured to accept PoP linking information that does not ma
tch
the current TLS session because the authenticated EST client Registrar ha
s
verified this information when acting as an EST server".</t>
<t><xref target="est-uri"/> contains the URI mappings between EST-coaps and
EST
that the Registrar MUST adhere to. <xref target="codes"/> of this
specification and Section 7 of <xref target="RFC8075"/> define the mappin
gs
between EST-coaps and HTTP response codes, that determine how the Registr
ar
MUST translate CoAP response codes from/to HTTP status codes. The mapping
from
CoAP Content-Format to HTTP Content-Type is defined in <xref target="Cont
ent-Formats"/>.
Additionally, a conversion from CBOR major type 2 to Base64 encoding MUST
take
place at the Registrar. If
CMS end-to-end encryption is employed for the private key, the encrypted
CMS EnvelopedData blob MUST be converted at the Registrar to binary CBOR
type 2 downstream to the client. This is a format conversion that does
not require decryption of the CMS EnvelopedData.</t>
<t>A deviation from the mappings in <xref target="est-uri"/> could take p <t>When enforcing Proof-of-Possession (POP) linking, the tls-unique or
lace if tls-exporter value of the session for DTLS 1.2 and DTLS 1.3, respectively,
clients that leverage server-side key generation preferred for the enroll is used to prove that the private key corresponding to the public key is
ed in the possession of the client and was used to establish the connection
keys to be generated by the Registrar in the case the CA does not as explained in <xref target="profile7925" format="default"/>. The POP
support server-side key generation. Such a Registrar is responsible linking information is lost between the EST-coaps client and the EST
for generating a new CSR signed by a new key which will be returned to th server when a Registrar is present. The EST server becomes aware of the
e presence of a Registrar from its TLS client certificate that includes
client along with the certificate from the CA. In these cases, the Regist the id-kp-cmcRA extended key usage (EKU) extension <xref
rar target="RFC6402" format="default"/>. As explained in <xref
MUST use random number generation with proper entropy. </t> target="RFC7030" sectionFormat="of" section="3.7"/>, the "EST server
<bcp14>SHOULD</bcp14> apply authorization policy consistent with an RA
client ... the EST server could be configured to accept POP linking
information that does not match the current TLS session because the
authenticated EST client RA has verified this information when acting as
an EST server".</t>
<t><xref target="est-uri" format="default"/> contains the URI mappings
between EST-coaps and EST that the Registrar <bcp14>MUST</bcp14> adhere
to. <xref target="codes" format="default"/> of this specification and
<xref target="RFC8075" sectionFormat="of" section="7"/> define the
mappings between EST-coaps and HTTP response codes that determine how
the Registrar <bcp14>MUST</bcp14> translate CoAP response codes from/to
HTTP status codes. The mapping from CoAP Content-Format to HTTP
Content-Type is defined in <xref target="Content-Formats"
format="default"/>. Additionally, a conversion from CBOR major type 2
to Base64 encoding <bcp14>MUST</bcp14> take place at the Registrar. If
CMS end-to-end encryption is employed for the private key, the encrypted
CMS EnvelopedData blob <bcp14>MUST</bcp14> be converted at the Registrar
to binary CBOR type 2 downstream to the client. This is a format
conversion that does not require decryption of the CMS
EnvelopedData.</t>
<t>A deviation from the mappings in <xref target="est-uri"
format="default"/> could take place if clients that leverage server-side
key generation preferred for the enrolled keys to be generated by the
Registrar in the case the CA does not support server-side key
generation. Such a Registrar is responsible for generating a new CSR
signed by a new key that will be returned to the client along with the
certificate from the CA. In these cases, the Registrar
<bcp14>MUST</bcp14> use random number generation with proper
entropy. </t>
<t>Due to fragmentation of large messages into blocks, an
EST-coaps-to-HTTP Registrar <bcp14>MUST</bcp14> reassemble the blocks
before translating the binary content to Base64 and consecutively relay
the message upstream. </t>
<t>The EST-coaps-to-HTTP Registrar <bcp14>MUST</bcp14> support resource
discovery according to the rules in <xref target="discovery"
format="default"/>. </t>
<t>Due to fragmentation of large messages into blocks, an EST-coaps-to-HT
TP
Registrar MUST reassemble the BLOCKs before translating the binary conten
t to
Base64, and consecutively relay the message upstream. </t>
<t>The EST-coaps-to-HTTP Registrar MUST support resource discovery according
to the rules in <xref target="discovery"/>. </t><!-- The available actions o
f the Registrars MUST be
announced with as many resource paths necessary. -->
<!-- The discovery of the EST server
in the HTTP environment follow the rules specified in <xref target="RFC70
30"/> -->
<!-- Next paragraph should be removed because e2e encryption is possible.
No need for the registrar to decrypt -->
<!-- <t>When server-side key generation is used, if the private key is pr
otected using symmetric keys then the Registrar needs to encrypt the private key
down to the client with one symmetric key and decrypt it from the server with a
nother. If no private key encryption takes place the Registrar will be able to s
ee the key as it establishes a separate connection to the server. In the case of
asymmetrically encrypted private key, the Registrar may not be able to decrypt
it if the server encrypted it with a public key that corresponds to a private ke
y that belongs to the client. </t> -->
</section> </section>
<section numbered="true" toc="default">
<name>Parameters</name>
<t>This section addresses transmission parameters described in Sections
<xref target="RFC7252" sectionFormat="bare" section="4.7"/> and <xref
target="RFC7252" sectionFormat="bare" section="4.8"/> of <xref target="RFC
7252"/>. EST does not
impose any unique values on the CoAP parameters in <xref
target="RFC7252" format="default"/>, but the setting of the CoAP
parameter values may have consequence for the setting of the EST
parameter values. </t>
<section title="Parameters">
<t>This section addresses transmission parameters described
in sections 4.7 and 4.8 of <xref target="RFC7252"/>.
EST does not impose any unique values on the CoAP parameters
in <xref target="RFC7252"/>, but the setting of the CoAP parameter values
may have consequence for the setting of the EST parameter values. </t>
<!-- <figure align="center"><artwork><![CDATA[
ACK_TIMEOUT | 2 seconds |
ACK_RANDOM_FACTOR | 1.5 |
MAX_RETRANSMIT | 4 |
NSTART | 1 |
DEFAULT_LEISURE | 5 seconds |
PROBING_RATE | 1 byte/second | ]]></artwork></figure> -->
<!-- using Nexus Certificate Manager with Californium for
CoAP support, communicating with a ContikiOS and tinyDTLS based
client, from RISE SICS, -->
<t> <t>
Implementations should follow the default CoAP configuration Implementations should follow the default CoAP configuration
parameters <xref target="RFC7252"/>. parameters <xref target="RFC7252" format="default"/>. However,
However, depending on the implementation scenario, retransmissions depending on the implementation scenario, retransmissions and timeouts
and timeouts can also occur on other networking layers, can also occur on other networking layers, governed by other
governed by other configuration parameters. When a change in a configuration parameters. When a change in a server parameter has
server parameter has taken place, the parameter values in the communicati taken place, the parameter values in the communicating endpoints
ng endpoints MUST be adjusted as necessary. Examples of how parameters <bcp14>MUST</bcp14> be adjusted as necessary. Examples of how
could be adjusted include higher layer congestion protocols, parameters could be adjusted include higher-layer congestion
provisioning agents and configurations included in firmware updates.</t> protocols, provisioning agents, and configurations included in
firmware updates.</t>
<t>Some further comments about some specific parameters, mainly from
Table 2 in <xref target="RFC7252" format="default"/>, include the followi
ng:
</t>
<t>Some further comments about some specific parameters, mainly from <dl>
Table 2 in <xref target="RFC7252"/>:
<list style="symbols">
<t>NSTART: A parameter that controls the number of simultaneous
outstanding interactions that a client maintains to a given server.
An EST-coaps client is expected to control at most one interaction with
a given server, which is the default NSTART value
defined in <xref target="RFC7252"/>.</t>
<t>DEFAULT_LEISURE: This setting is only relevant in multicast scenarios,
outside the scope of EST-coaps.</t>
<t>PROBING_RATE: A parameter which specifies the rate of re-sending
non-confirmable messages. In the rare situations that non-confirmable m
essages are used, the default PROBING_RATE value defined in <xref target="RFC725
2"/> applies.</t>
</list></t>
<t>Finally, the Table 3 parameters in <xref target="RFC7252"/> are mainly
derived from Table 2. Directly changing parameters on one table would
affect parameters on the other.</t>
</section>
<section anchor="deploy-limit" title = "Deployment limitations">
<t>Although EST-coaps paves the way for the utilization of EST by constraine
d devices in constrained networks, some classes of devices <xref target="RFC7228
" /> will not have enough resources to handle the payloads that come with EST-co
aps. The specification of EST-coaps is intended to ensure that EST works for net
works of constrained devices that choose to limit their communications stack to
DTLS/CoAP. It is up to the network designer to decide which devices execute the
EST protocol and which do not.</t>
</section> <!-- Deployment limits -->
<section anchor="iana" title="IANA Considerations"> <dt>NSTART:
</dt>
<dd>A parameter that controls the number of simultaneous outstanding
interactions that a client maintains to a given server. An EST-coaps client
is expected to control at most one interaction with a given server, which is
the default NSTART value defined in <xref target="RFC7252" format="default"/>.
</dd>
<section anchor="Content-Formats" title="Content-Format Registry"> <dt>DEFAULT_LEISURE:
<t>Additions to the sub-registry "CoAP Content-Formats", within the "CoRE Pa </dt>
rameters" <dd>A setting that is only relevant in multicast scenarios and is outside the sc
registry <xref target="COREparams"/> are specified in <xref target="Conte ope of
nt-Format"/>. EST-coaps.
These have been registered provisionally in the IETF Review or IESG Appro </dd>
val range (256-9999).</t>
<texttable anchor="Content-Format" title="New CoAP Content-Formats"> <dt>PROBING_RATE:
<ttcol align="left">HTTP Content-Type</ttcol> </dt>
<ttcol align="right">ID</ttcol> <dd>A parameter that specifies the rate of resending Non-confirmable
<ttcol align="left">Reference</ttcol> messages. In the rare situations that Non-confirmable messages are used, the
default PROBING_RATE value defined in <xref target="RFC7252"
format="default"/> applies.
</dd>
<c>application/pkcs7-mime; smime-type=server-generated-key</c><c>280</c> <c><x </dl>
ref target="RFC7030"/> <xref target="I-D.ietf-lamps-rfc5751-bis"/> [ThisRFC]</c>
<c>application/pkcs7-mime; smime-type=certs-only</c> <c>281</c> <c><x
ref target="I-D.ietf-lamps-rfc5751-bis"/> [ThisRFC]</c>
<c>application/pkcs8</c> <c>284</c> <c><x
ref target="RFC5958"/> <xref target="I-D.ietf-lamps-rfc5751-bis"/> [ThisRFC]</c>
<c>application/csrattrs</c> <c>285</c> <c><x
ref target="RFC7030"/> </c>
<c>application/pkcs10</c> <c>286</c> <c><x
ref target="RFC5967"/> <xref target="I-D.ietf-lamps-rfc5751-bis"/> [ThisRFC]</c>
<c>application/pkix-cert</c> <c>TBD287</c> <
c> <xref target="RFC2585"/> [ThisRFC]</c>
</texttable>
<t>It is suggested that 287 is allocated to TBD287.</t> <t>Finally, the Table 3 parameters in <xref target="RFC7252" format="defau
lt"/> are mainly
derived from Table 2. Directly changing parameters on one table would
affect parameters on the other.</t>
</section>
<section anchor="deploy-limit" numbered="true" toc="default">
<name>Deployment Limitations</name>
<t>Although EST-coaps paves the way for the utilization of EST by constrai
ned devices in constrained networks, some classes of devices <xref target="RFC72
28" format="default"/> will not have enough resources to handle the payloads tha
t come with EST-coaps. The specification of EST-coaps is intended to ensure that
EST works for networks of constrained devices that choose to limit their commun
ications stack to DTLS/CoAP. It is up to the network designer to decide which de
vices execute the EST protocol and which do not.</t>
</section>
</section> <!-- Content-Format registry --> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="Content-Formats" numbered="true" toc="default">
<name>Content-Formats Registry</name>
<t>IANA has registered the following Content-Formats given in <xref targ
et="Content-Format" format="default"/> in the "CoAP Content-Formats" subregistry
within the "CoRE Parameters"
registry <xref target="CORE-PARAMS" format="default"/>.
These have been registered in the IETF Review or IESG Approval range (256
-9999).</t>
<section anchor="resource-type" title="Resource Type registry"> <table anchor="Content-Format" align="center">
<t>This memo registers new Resource Type (rt=) Link Target Attributes <name>New CoAP Content-Formats</name>
in the "Resource Type (rt=) Link Target Attribute Values" <thead>
<tr>
<th align="left">Media Type</th>
<th align="right">ID</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">application/pkcs7-mime; smime-type=server-generat
ed-key</td>
<td align="right">280</td>
<td align="left">
<xref target="RFC7030" format="default"/> <xref target="RFC8551"
format="default"/> RFC 9148</td>
</tr>
<tr>
<td align="left">application/pkcs7-mime; smime-type=certs-only</td
>
<td align="right">281</td>
<td align="left">
<xref target="RFC8551" format="default"/> RFC 9148</td>
</tr>
<tr>
<td align="left">application/pkcs8</td>
<td align="right">284</td>
<td align="left">
<xref target="RFC5958" format="default"/> <xref target="RFC8551"
format="default"/> RFC 9148</td>
</tr>
<tr>
<td align="left">application/csrattrs</td>
<td align="right">285</td>
<td align="left">
<xref target="RFC7030" format="default"/> RFC 9148</td>
</tr>
<tr>
<td align="left">application/pkcs10</td>
<td align="right">286</td>
<td align="left">
<xref target="RFC5967" format="default"/> <xref target="RFC8551"
format="default"/> RFC 9148</td>
</tr>
<tr>
<td align="left">application/pkix-cert</td>
<td align="right">287</td>
<td align="left">
<xref target="RFC2585" format="default"/> RFC 9148</td>
</tr>
</tbody>
</table>
</section>
<section anchor="resource-type" numbered="true" toc="default">
<name>Resource Type Registry</name>
<t>IANA has registered the following Resource Type (rt=) Link Target Att
ributes
given in <xref target="rt-table"/> in the "Resource Type (rt=) Link Target At
tribute Values"
subregistry under the "Constrained RESTful Environments (CoRE) subregistry under the "Constrained RESTful Environments (CoRE)
Parameters" registry. Parameters" registry.
<list style="symbols"> </t>
<t>rt="ace.est.crts". This resource depicts the support
of EST get cacerts.</t>
<t>rt="ace.est.sen". This resource depicts the support
of EST simple enroll.</t>
<t>rt="ace.est.sren". This resource depicts the support
of EST simple reenroll.</t>
<t>rt="ace.est.att". This resource depicts the support
of EST get CSR attributes.</t>
<t>rt="ace.est.skg". This resource depicts the support
of EST server-side key generation with the returned
certificate in a PKCS#7 container.</t>
<t>rt="ace.est.skc". This resource depicts the support
of EST server-side key generation with the returned
certificate in application/pkix-cert format.</t>
</list>
</t>
<t></t>
</section> <!-- Resource Type registry -->
<section anchor="well-known-uris" title="Well-Known URIs Registry"> <table anchor="rt-table">
<t>A new additional reference is requested for <name>New Resource Type (rt=) Link Target Attributes</name>
the est URI in the Well-Known URIs registry: </t> <thead>
<texttable> <tr>
<ttcol align='center'>URI Suffix</ttcol> <th>Value</th>
<ttcol align='center'>Change Controller</ttcol> <th>Description</th>
<ttcol align='center'>References</ttcol> <th>Reference</th>
<ttcol align='center'>Status</ttcol> </tr>
<ttcol align='center'>Related Information</ttcol> </thead>
<ttcol align='center'>Date Registered</ttcol> <tbody>
<ttcol align='center'>Date Modified</ttcol> <tr>
<c>est</c> <td>ace.est.crts</td>
<c>IETF</c> <td>This resource depicts the support of EST GET cacerts.</td>
<c>[RFC7030] [THIS RFC]</c> <td>RFC 9148</td>
<c>permanent</c> </tr>
<c></c> <tr>
<c>2013-08-16</c> <td>ace.est.sen</td>
<c>[THIS RFC's publication date]</c> <td>This resource depicts the support of EST simple enroll.</td>
</texttable> <td>RFC 9148</td>
</section> <!-- Well Known URIs registry --> </tr>
<tr>
<td>ace.est.sren</td>
<td>This resource depicts the support of EST simple reenroll.</td>
<td>RFC 9148</td>
</tr>
<tr>
<td>ace.est.att</td>
<td>This resource depicts the support of EST GET CSR attributes.</td>
<td>RFC 9148</td>
</tr>
<tr>
<td>ace.est.skg</td>
<td>This resource depicts the support of EST server-side key generation wi
th the returned certificate in a PKCS #7 container.</td>
<td>RFC 9148</td>
</tr>
<tr>
<td>ace.est.skc</td>
<td>This resource depicts the support of EST server-side key generation wi
th the returned certificate in application/pkix-cert format.</td>
<td>RFC 9148</td>
</tr>
</tbody>
</table>
</section>
</section> <!-- IANA consideration --> <section anchor="well-known-uris" numbered="true" toc="default">
<name>Well-Known URIs Registry</name>
<t>IANA has added an additional reference to
the est URI in the "Well-Known URIs" registry: </t>
<section anchor="sec" title="Security Considerations"> <dl>
<section anchor="sec-est" title="EST server considerations"> <dt>URI Suffix:</dt> <dd>est</dd>
<t>The security considerations of Section 6 of <xref target="RFC7030"/> ar <dt>Change Controller:</dt> <dd>IETF</dd>
e only <dt>References:</dt> <dd><xref target="RFC7030" format="default"/> RFC 9148</d
partially valid for the purposes of this document. As HTTP Basic Authen d>
tication is <dt>Status:</dt> <dd>permanent</dd>
not supported, the considerations expressed for using passwords do not <dt>Related Information:</dt> <dd></dd>
apply. The other portions of the <dt>Date Registered:</dt> <dd>2013-08-16</dd>
security considerations of <xref target="RFC7030"/> continue to apply.</t> <dt>Date Modified:</dt> <dd>2020-04-29</dd>
</dl>
</section>
<t>Modern security protocols require random numbers to be available dur </section>
ing
the protocol run, for example for nonces and ephemeral (EC) Diffie-Hellman
key
generation. This capability to generate random numbers is also needed
when the constrained device generates the private key (that corresponds
to the public key enrolled in the CSR). When server-side key generation is
used, the constrained device depends on the server to generate the
private key randomly, but it still needs locally generated random numbers
for use in security protocols, as explained in Section 12 of <xref targ
et="RFC7925"/>.
Additionally, the transport of keys generated at the server is inherent
ly risky.
For those deploying server-side key generation, analysis SHOULD be done
to establish whether server-side key generation increases
or decreases the probability of digital identity theft.</t>
<t>It is important to note that, as pointed out in <xref target="PsQs"/>, <section anchor="sec" numbered="true" toc="default">
sources contributing to the randomness <name>Security Considerations</name>
<section anchor="sec-est" numbered="true" toc="default">
<name>EST Server Considerations</name>
<t>The security considerations in <xref target="RFC7030"
sectionFormat="of" section="6"/> are only partially valid for the
purposes of this document. As HTTP Basic Authentication is not
supported, the considerations expressed for using passwords do not
apply. The other portions of the security considerations in <xref
target="RFC7030" format="default"/> continue to apply.</t>
<t>Modern security protocols require random numbers to be available
during the protocol run, for example, for nonces and ephemeral (EC)
Diffie-Hellman key generation. This capability to generate random
numbers is also needed when the constrained device generates the
private key (that corresponds to the public key enrolled in the
CSR). When server-side key generation is used, the constrained device
depends on the server to generate the private key randomly, but it
still needs locally generated random numbers for use in security
protocols, as explained in <xref target="RFC7925"
sectionFormat="of" section="12"/>. Additionally, the transport of keys
generated at
the server is inherently risky. For those deploying server-side key
generation, analysis <bcp14>SHOULD</bcp14> be done to establish
whether server-side key generation increases or decreases the
probability of digital identity theft.</t>
<t>It is important to note that, as pointed out in <xref target="PsQs" f
ormat="default"/>, sources contributing to the randomness
pool used to generate random numbers on laptops or desktop PCs, pool used to generate random numbers on laptops or desktop PCs,
such as mouse movement, timing of keystrokes, or air turbulence such as mouse movement, timing of keystrokes, or air turbulence
on the movement of hard drive heads, on the movement of hard drive heads,
are not available on many constrained devices. are not available on many constrained devices.
Other sources have to be used or dedicated hardware has to be added. Other sources have to be used or dedicated hardware has to be added.
Selecting hardware for an IoT device that is capable of producing Selecting hardware for an IoT device that is capable of producing
high-quality random numbers is therefore important <xref target="RSAfact"/ >.</t> high-quality random numbers is therefore important <xref target="RSA-FACT" format="default"/>.</t>
<!--Remark that the initial /crts request uses the implicit database, and <t>As discussed in <xref target="RFC7030" sectionFormat="of"
that a compromised implicit database has as consequence that all subsequent exch section="6"/>, it is
anges from that client are jeopardized. --> </t>
<t>As discussed in Section 6 of <xref target="RFC7030"/>, it is
"RECOMMENDED that the Implicit Trust Anchor database used for <blockquote>
EST server authentication is carefully managed to reduce the chance of <bcp14>RECOMMENDED</bcp14> that the Implicit Trust Anchor database used for
a EST server authentication be carefully managed to reduce the chance of a
third-party CA with poor certification practices jeopardizing authentic third-party CA with poor certification practices from being trusted.
ation. Disabling the Implicit Trust Anchor database after successfully receiving the
Disabling the Implicit Trust Anchor database after successfuly receivin Distribution of CA certificates response (<xref target="RFC7030"
g the format="default" sectionFormat="comma" section="6"/>)
Distribution of CA certificates response (Section 4.1.3) limits any vulnerability to the first TLS exchange.
limits any risk to the first TLS exchange". Alternatively, in a case </blockquote>
where a /sen request immediately follows a /crts, a client
MAY choose to keep the connection authenticated by the Implicit <t>
TA open for efficiency reasons (<xref target="profile7925"/>). A client
that interleaves Alternatively, in a case where a /sen request immediately follows a /crts, a
EST-coaps /crts request with other requests in the same DTLS connection client <bcp14>MAY</bcp14> choose to keep the connection authenticated by the
SHOULD Implicit TA open for efficiency reasons (<xref target="profile7925"
revalidate the server certificate chain against the updated Explicit TA format="default"/>). A client that interleaves EST-coaps /crts request with
from other requests in the same DTLS connection <bcp14>SHOULD</bcp14> revalidate
the /crts response before proceeding with the subsequent requests. If t the server certificate chain against the updated Explicit TA from the /crts
he response before proceeding with the subsequent requests. If the server
server certificate chain does not authenticate against the database, th certificate chain does not authenticate against the database, the client
e client SHOULD close the <bcp14>SHOULD</bcp14> close the connection without completing the rest of
connection without completing the rest of the requests. The updated Exp the requests. The updated Explicit TA <bcp14>MUST</bcp14> continue to be
licit used in new DTLS connections.</t>
TA MUST continue to be used in new DTLS connections.</t> <t>In cases where the Initial Device Identifier (IDevID) used to authent
<t>In cases where the IDevID used to authenticate the client is expired th icate the client is
e server expired, the server <bcp14>MAY</bcp14> still authenticate the client bec
MAY still authenticate the client because IDevIDs are expected to live ause IDevIDs
as long are expected to live as long as the device itself (<xref
as the device itself (<xref target="profile7925"/>). In such occasions, target="profile7925" format="default"/>). In such occasions, checking
checking the certificate revocation status or authorizing the client using
the certificate revocation status or authorizing the client using anoth another method is important for the server to raise its confidence
er method that the client can be trusted. </t>
is important for the server to raise its confidence that the client can <t>In accordance with <xref target="RFC7030" format="default"/>, TLS
be trusted. </t> cipher suites that include "_EXPORT_" and "_DES_" in their names <bcp14>
<t>In accordance with <xref target="RFC7030"/>, TLS cipher suites that MUST
include NOT</bcp14> be used. More recommendations for secure use of TLS and DTLS
"_EXPORT_" and "_DES_" in their names MUST NOT be used. More are
recommendations for secure use of TLS and DTLS are included in <xref ta included in <xref target="BCP195" format="default"/>.</t>
rget="BCP195"/>.</t><!--<xref target="RFC7525"/>-->
<t>As described in CMC, Section 6.7 of <xref target="RFC5272"/>, "For keys <t>As described in Certificate Management over CMS (CMC), <xref
that can target="RFC5272" sectionFormat="of" section="6.7"/>, "For keys that can
be used as signature keys, signing the certification request with the p be used as signature keys, signing the certification request with the
rivate key private key serves as a POP on that key pair". In (D)TLS 1.2, the
serves as a PoP on that key pair". The inclusion of tls-unique in the c inclusion of tls-unique in the certificate request links the
ertificate proof-of-possession to the (D)TLS proof-of-identity. This implies but
request links the proof-of-possession to the TLS proof-of-identity. Thi does not prove that only the authenticated client currently has access
s implies to the private key.</t>
but does not prove that only the authenticated client currently has acc
ess to the <t>What's more, CMC POP linking uses tls-unique as it is defined in
private key.</t> <xref target="RFC5929" format="default"/>. The 3SHAKE attack <xref
<t>What's more, CMC PoP linking uses tls-unique as it is defined in target="TRIPLESHAKE" format="default"/> poses a risk by allowing an
<xref target="RFC5929"/>. The 3SHAKE attack <xref target="tripleshake"/ on-path active attacker to leverage session resumption and
> renegotiation to inject itself between a client and server even when
poses a risk by allowing a man-in-the-middle to channel binding is in use. Implementers should use the Extended Master
leverage session resumption and renegotiation to Secret Extension in DTLS <xref target="RFC7627" format="default"/> to
inject himself between a client and server even when channel binding is prevent such attacks. In the context of this specification, an
in use. Implementers should use the Extended Master Secret attacker could invalidate the purpose of the POP linking
Extension in DTLS <xref target="RFC7627"/> to prevent such attacks. challengePassword in the client request by resuming an EST-coaps
In the context of this specification, an attacker could connection. Even though the practical risk of such an attack to
invalidate the purpose of the PoP linking ChallengePassword in the clie EST-coaps is not devastating, we would rather use a more secure
nt channel-binding mechanism.
request by resuming an EST-coaps connection. Even though the practical In this specification, we still depend on the tls-unique
risk of such an attack to EST-coaps is not devastating, mechanism defined in <xref target="RFC5929" format="default"/> for DTLS 1.
we would rather use a more secure channel binding mechanism. 2
Such a mechanism could include an updated tls-unique value generation because a 3SHAKE attack does not expose messages exchanged
like the tls-unique-prf defined in <xref target="I-D.josefsson-sasl-tls with EST-coaps. But for DTLS 1.3,
-cb"/> <xref target="I-D.ietf-kitten-tls-channel-bindings-for-tls13" format="d
by using a TLS exporter <xref target="RFC5705"/> in TLS 1.2 or TLS 1.3' efault"/>
s is used instead to derive a 32-byte tls-exporter binding
updated exporter (Section 7.5 of <xref target="RFC8446"/>) value in in place of the tls-unique value in the CSR. That would alleviate the r
place of the tls-unique value in the CSR. Such mechanism isks
has not been standardized yet. Adopting a channel from the 3SHAKE attack <xref target="TRIPLESHAKE" format="default"/>.
binding value generated from an exporter would break backwards compatib </t>
ility for an RA that proxies through to a classic EST server.
Thus, in this specification we still depend on the tls-unique mechanism <t>Interpreters of ASN.1 structures should be aware of the use of inval
defined in <xref target="RFC5929"/>, especially since a 3SHAKE attack id ASN.1
does not expose messages exchanged with EST-coaps.</t>
<t>Interpreters of ASN.1 structures should be aware of the use of invalid
ASN.1
length fields and should take appropriate measures to guard against buf fer overflows, length fields and should take appropriate measures to guard against buf fer overflows,
stack overruns in particular, and malicious content in general.</t> stack overruns in particular, and malicious content in general.</t>
</section>
</section> <!-- EST server considerations --> <section anchor="sec-proxy" numbered="true" toc="default">
<name>HTTPS-CoAPS Registrar Considerations</name>
<section anchor="sec-proxy" title="HTTPS-CoAPS Registrar considerations"> <t>The Registrar proposed in <xref target="proxy" format="default"/>
<t>The Registrar proposed in <xref target="proxy"/> must be deployed with must be deployed with care and only when direct client-server
care, connections are not possible. When POP linking is used, the Registrar
and only when direct client-server connections are not possible. When terminating the DTLS connection establishes a new TLS connection with
PoP linking is used the the upstream CA. Thus, it is impossible for POP linking to be enforced
Registrar terminating the DTLS connection establishes a new TLS conne end to end for the EST transaction. The EST server could be configured
ction with the upstream to accept POP linking information that does not match the current TLS
CA. Thus, it is impossible for PoP linking to be enforced end-to- session because the authenticated EST Registrar is assumed to have
end for the EST verified POP linking downstream to the client.</t>
transaction. The EST server could be configured to accept PoP lin <t>The introduction of an EST-coaps-to-HTTP Registrar assumes the
king information
that does not match the current TLS session because the authentic
ated EST Registrar is assumed to have verified PoP linking downstream to the cli
ent.</t>
<t>The introduction of an EST-coaps-to-HTTP Registrar assumes the
client can authenticate client can authenticate
the Registrar using its implicit or explicit TA database. It also assumes the Registrar using its implicit or explicit TA database. It also assumes
the Registrar has a trust relationship with the upstream EST serv er in order the Registrar has a trust relationship with the upstream EST serv er in order
to act on behalf of the clients. When a client uses the Implicit TA to act on behalf of the clients. When a client uses the Implicit TA
database for certificate validation, it SHOULD confirm if the ser ver database for certificate validation, it <bcp14>SHOULD</bcp14> con firm if the server
is acting as an RA by the presence of the id-kp-cmcRA EKU is acting as an RA by the presence of the id-kp-cmcRA EKU
<xref target="RFC6402"/> in the server certificate. </t><!-- If t <xref target="RFC6402" format="default"/> in the server certifica
he server certificate does not include te. </t>
the EKU, it is RECOMMENDED that the client includes Identity and
PoP Information" (<xref target="profile7925"/>) in requests.-->
<t>In a server-side key generation case, if no end-to-end encryption is
used, the Registrar may be able see the private key as it acts as a m
an-in-the-middle.
Thus, the client puts its trust on the Registrar not exposing the
private key. </t>
<t>Clients that leverage server-side key generation without end-to-end enc
ryption
of the private key (<xref target="serverkey"/>) have no knowledge
if the Registrar will be generating the private key and enrolling the
certificates
with the CA or if the CA will be responsible for generating the key.
In such cases, the existence of a Registrar requires the client to pu
t
its trust on the registrar when it is generating the
private key. </t>
</section> <!-- proxy considerations -->
</section> <!-- Security considerations -->
<section anchor="contrib" title="Contributors"> <t>In a server-side key generation case, if no end-to-end encryption
<!-- Nexus has participated in interoperability tests which resulted in n is used, the Registrar may be able see the private key as it acts as
ew a man in the middle. Thus, the client puts its trust on the
insights that were added in the draft. --> Registrar not exposing the private key. </t>
<t>Martin Furuhed contributed to the EST-coaps specification by providing fe <t>Clients that leverage server-side key generation without end-to-end
edback encryption of the private key (<xref target="serverkey"
based on the Nexus EST over CoAPS server implementation that started in 2 format="default"/>) have no knowledge as to whether the Registrar will b
015. e
Sandeep Kumar kick-started this specification and was instrumental in generating the private key and enrolling the certificates with the CA
drawing attention to the importance of the subject. </t> or if the CA will be responsible for generating the key. In such
</section> <!-- Contributors --> cases, the existence of a Registrar requires the client to put its
trust on the Registrar when it is generating the private key. </t>
</section>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The authors are very grateful to Klaus Hartke for his detailed explanatio
ns on
the use of Block with DTLS and his support for the Content-Format specifi
cation.
The authors would like to thank Esko Dijk and Michael Verschoor for the v
aluable
discussions that helped in shaping the solution. They would also like to
thank Peter
Panburana for his feedback on technical details of the solution. Construc
tive comments
were received from Benjamin Kaduk, Eliot Lear, Jim Schaad, Hannes Tschofe
nig, Julien
Vermillard, John Manuel, Oliver Pfaff, Pete Beal and Carsten Bormann.</t>
<t>Interop tests were done by Oliver Pfaff, Thomas Werner, Oskar Camezind,
Bjorn Elmers and Joel Hoglund.</t>
<t>Robert Moskowitz provided code to create the examples.</t>
</section> <!-- Acknowledgements -->
</middle> </middle>
<back>
<back> <displayreference target="I-D.ietf-kitten-tls-channel-bindings-for-tls13" to="T
<references title="Normative References"> LS13-CHANNEL-BINDINGS"/>
&RFC2119; <displayreference target="I-D.moskowitz-ecdsa-pki" to="PKI-GUIDE"/>
&RFC2585; <references>
&RFC5246; <name>References</name>
&RFC5958; <references>
&RFC5967; <name>Normative References</name>
&RFC6347; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC6690; FC.2119.xml"/>
&RFC7030; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!--&RFC7049;--> FC.2585.xml"/>
&RFC7252; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC7925; FC.5246.xml"/>
&RFC7959; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8075; FC.5958.xml"/>
&RFC8174; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8422; FC.5967.xml"/>
&RFC8446; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&I-D.ietf-tls-dtls13; FC.6347.xml"/>
&I-D.ietf-core-multipart-ct; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&I-D.ietf-lamps-rfc5751-bis; FC.6690.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7030.xml"/>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<references title="Informative References"> FC.7252.xml"/>
<!-- &RFC0791; --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5272; FC.7925.xml"/>
<!-- &RFC4944; --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!--&RFC5273;--> FC.7959.xml"/>
&RFC5705; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- &RFC6090; --> FC.8075.xml"/>
&RFC6402; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC7230; FC.8174.xml"/>
<!-- &RFC7231; --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC7228; FC.8422.xml"/>
&RFC7251; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC7299; FC.8446.xml"/>
&RFC7627;
&RFC4919; <!-- reference.I-D.ietf-tls-dtls13 RFC 9147
&RFC5929; -->
&RFC7748; <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147">
<!-- &RFC7525; --> <front>
<!-- &I-D.ietf-anima-bootstrapping-keyinfra; --> <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
&I-D.ietf-tls-dtls-connection-id; <author initials='E' surname='Rescorla' fullname='Eric Rescorla'/>
<!-- &I-D.draft-ietf-core-resource-directory-19; --> <author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'/>
&I-D.moskowitz-ecdsa-pki; <author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'/>
&I-D.josefsson-sasl-tls-cb; <date month='August' year='2021'/>
<reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">< </front>
front> <seriesInfo name="RFC" value="9147"/>
<title>Recommendations for Secure Use of Transport Layer Security (TLS) an <seriesInfo name="DOI" value="10.17487/RFC9147"/>
d Datagram Transport Layer Security (DTLS)</title> </reference>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer"/>
<author initials="R." surname="Holz" fullname="Ralph Holz"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="P." surname="Saint-Andre" fullname="Saint-Andre"/> FC.8710.xml"/>
<date year="2015" month="May"/>
</front><seriesInfo name="BCP" value="195"/><seriesInfo name="RFC" value="75 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
25"/></reference> FC.8551.xml"/>
<reference anchor="ieee802.15.4">
<front> </references>
<title>IEEE Standard 802.15.4-2006</title> <references>
<author surname="Institute of Electrical and Electronics Engineers"> <name>Informative References</name>
</author>
<date month="" year="2006" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5
</front> 272.xml"/>
</reference>
<reference anchor="ieee802.1ar"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.6402.xml"/>
<title>IEEE 802.1AR Secure Device Identifier</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author surname="Institute of Electrical and Electronics Engineers"> FC.7230.xml"/>
</author>
<date month="December" year="2009" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.7228.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="PsQs"> FC.7251.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in Netwo FC.7299.xml"/>
rk Devices</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author surname="Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex FC.7627.xml"/>
Halderman"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.4919.xml"/>
<date month="August" year="2012" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.5929.xml"/>
<seriesInfo name="USENIX Security Symposium 2012" value="ISBN 978-93197 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
1-95-9"/> FC.7748.xml"/>
</reference>
<reference anchor="tripleshake"> <!-- I-D.ietf-tls-dtls-connection-id companion document RFC 9146 -->
<front> <reference anchor="RFC9146" target="https://www.rfc-editor.org/info/rfc9146">
<title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Authent <front>
ication over TLS</title> <title>Connection Identifiers for DTLS 1.2</title>
<author surname="Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cedric <author initials='E' surname='Rescorla' fullname='Eric Rescorla' role="editor"/>
Fournet, Alfredo Pironti, Pierre-Yves Strub"> <author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig' role="edi
tor"/>
<author initials='T' surname='Fossati' fullname='Thomas Fossati'/>
<author initials='A' surname='Kraus' fullname='Achim Kraus'/>
<date month='August' year='2021'/>
</front>
<seriesInfo name="RFC" value="9146"/>
<seriesInfo name="DOI" value="10.17487/RFC9146"/>
</reference>
<!-- I-D.moskowitz-ecdsa-pki expired 2021 Aug 4. Explicit verion number used to
get author initials correct. -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.moskowitz-ecdsa-pki-10.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/refere
nce.I-D.ietf-kitten-tls-channel-bindings-for-tls13.xml"/>
<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7525.xml"/>
</referencegroup>
<reference anchor="IEEE802.15.4">
<front>
<title>IEEE 802.15.4-2020 - IEEE Standard for Low-Rate Wireless
Networks</title>
<author>
<organization>IEEE</organization>
</author> </author>
<date month="May" year="2014" /> <date month="May" year="2020"/>
</front> </front>
<seriesInfo name="IEEE Security and Privacy" value="ISBN 978-1-4799-468 </reference>
6-0"/>
</reference> <reference anchor="IEEE802.1AR">
<reference anchor="RSAfact"> <front>
<front> <title>IEEE Standard for Local and metropolitan area networks -
<title>Factoring RSA keys from certified smart cards: Coppersmith in the Secure Device Identity</title>
wild</title> <author>
<author surname="Daniel J. Bernstein1, Yun-An Chang, Chen-Mou Cheng, Li- <organization>IEEE
Ping Chou, Nadia Heninger, Tanja Lange, Nicko van Someren"> </organization>
</author> </author>
<date month="August" year="2013" /> <date month="December" year="2009"/>
</front> </front>
<seriesInfo name="Advances in Cryptology - " value="ASIACRYPT 2013"/> </reference>
</reference>
<reference anchor="COREparams" target="https://www.iana.org/assignments/core
-parameters/core-parameters.xhtml">
<front>
<title>Constrained RESTful Environments (CoRE) Parameters</title>
<author surname="IANA"/>
<date/>
</front>
</reference>
</references>
<section anchor="messagebindings" title="EST messages to EST-coaps"> <reference anchor="PsQs">
<t>This section shows similar examples to the ones presented in Appendix A o <front>
f <title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in N
<xref target="RFC7030"/>. The payloads in the examples are the hex encode etwork Devices</title>
d binary, <author initials="N." surname="Heninger" fullname="Nadia Heninger"/>
generated with 'xxd -p', of the PKI certificates created following <author initials="Z." surname="Durumeric" fullname="Zakir Durumeric"/>
<xref target="I-D.moskowitz-ecdsa-pki"/>. Hex is used for visualization <author initials="E." surname="Wustrow" fullname="Eric Wustrow"/>
purposes because a binary representation cannot be rendered well in text. <author initials="J." surname="Alex Halderman" fullname="J. Alex Halderman"/>
The hexadecimal representations would not be transported in hex, but in b <date month="August" year="2012"/>
inary. </front>
The payloads are shown unencrypted. In practice the message content would <refcontent>USENIX Security Symposium 2012</refcontent>
be <seriesInfo name="ISBN" value="978-931971-95-9"/>
transferred over an encrypted DTLS channel. </t> </reference>
<!-- [EDNOTE: No need for these details of how these were generated from
I-D.moskowitz-ecdsa-pki. ] <reference anchor="TRIPLESHAKE">
In particular, the shell scripts from section 4.2 (create root certificat <front>
e), section 6.2 (Create the 802.1AR intermediate certificate) and section 6.3 (C <title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Aut
reate an 802.1AR IdevID certificate) have been used. The 802.1AR IdevID certific hentication over TLS</title>
ate is signed by the 802.1AR intermediate certificate that is signed by the auto
-signed root certificate.--> <author initials="B." surname="Bhargavan" fullname="Karthikeyan Bhargavan"/>
<t>The certificate responses included in the examples contain Content-Format <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavau
281 (application/pkcs7). If the client had requested Content-Format d"/>
TBD287 (application/pkix-cert) by querying /est/skc, the <author initials="C." surname="Fournet" fullname="Cedric Fournet"/>
server would respond with a single DER binary certificate in the multipar <author initials="A." surname="Pironti" fullname="Alfredo Pironti"/>
t-core container.</t> <author initials="P." surname="Strub" fullname="Pierre-Yves Strub"/>
<t>These examples assume a short resource path of "/est". Even though omi <date month="May" year="2014"/>
tted </front>
from the examples for brevity, before making the EST-coaps requests, a cl <seriesInfo name="ISBN" value="978-1-4799-4686-0"/>
ient <seriesInfo name="DOI" value="10.1109/SP.2014.14"/>
would learn about the server supported EST-coaps resources with a GET req </reference>
uest
for /.well-known/core?rt=ace.est* as explained in <xref target="discovery <reference anchor="RSA-FACT">
"/>.</t> <front>
<t>The corresponding CoAP headers are only shown in <xref target="cacerts"/> <title>Factoring RSA keys from certified smart cards: Coppersmith in
. the wild</title>
<author initials="D." surname="Bernstein" fullname="Daniel J. Bernstein"/>
<author initials="Y." surname="Chang" fullname="Yun-An Chang"/>
<author initials="C." surname="Cheng" fullname="Chen-Mou Cheng"/>
<author initials="L." surname="Chou" fullname="Li-Ping Chou"/>
<author initials="N." surname="Heninger" fullname="Nadia Heninger"/>
<author initials="T." surname="Lange" fullname="Tanja Lange"/>
<author initials="N." surname="Someren" fullname="Nicko van Someren"/>
<date month="August" year="2013"/>
</front>
<refcontent>Advances in Cryptology - ASIACRYPT 2013</refcontent>
</reference>
<reference anchor="CORE-PARAMS" target="https://www.iana.org/assignments
/core-parameters/">
<front>
<title>Constrained RESTful Environments (CoRE) Parameters</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references>
<section anchor="messagebindings" numbered="true" toc="default">
<name>EST Messages to EST-coaps</name>
<t>This section shows similar examples to the ones presented in <xref
target="RFC7030" sectionFormat="of" section="A"/>. The payloads in the
examples are the hex-encoded binary, generated with 'xxd -p', of the PKI
certificates created following <xref target="I-D.moskowitz-ecdsa-pki"
format="default"/>. Hex is used for visualization purposes because a
binary representation cannot be rendered well in text. The hexadecimal
representations would not be transported in hex, but in binary. The
payloads are shown unencrypted. In practice, the message content would be
transferred over an encrypted DTLS channel. </t>
<t>The certificate responses included in the examples contain
Content-Format 281 (application/pkcs7). If the client had requested
Content-Format 287 (application/pkix-cert), the server would respond with
a single DER binary certificate. That certificate would be in a
multipart-core container specifically in the case of a response to a
/est/skc query.</t>
<t>These examples assume a short resource path of "/est". Even though
omitted from the examples for brevity, before making the EST-coaps
requests, a client would learn about the server supported EST-coaps
resources with a GET request for /.well-known/core?rt=ace.est* as
explained in <xref target="discovery" format="default"/>.</t>
<t>The corresponding CoAP headers are only shown in <xref target="cacerts"
format="default"/>.
Creating CoAP headers is assumed to be generally understood.</t> Creating CoAP headers is assumed to be generally understood.</t>
<t>The message content breakdown is presented in <xref target="cont_break down"/>.</t>
<section title="cacerts" anchor="cacerts"> <t>The message content is presented in plain text in <xref
<t>In EST-coaps, a cacerts message can be:</t> target="cont_breakdown" format="default"/>.</t>
<figure align="left"><artwork><![CDATA[ <section anchor="cacerts" numbered="true" toc="default">
<name>cacerts</name>
<t>In EST-coaps, a cacerts message can be the following:</t>
<artwork><![CDATA[
GET example.com:9085/est/crts GET example.com:9085/est/crts
(Accept: 281) (Accept: 281)
]]></artwork></figure> ]]></artwork>
<t>The corresponding CoAP header fields are shown below. The
use of block and DTLS are worked out in <xref target= "blockexamples"/> <t>The corresponding CoAP header fields are shown below. The use of
.</t> block and DTLS are shown in <xref target="blockexamples"
<figure><artwork> format="default"/>.</t>
<![CDATA[ Ver = 1
<sourcecode type="coap"><![CDATA[
Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.01 is GET) Code = 0x01 (0.01 is GET)
Token = 0x9a (client generated) Token = 0x9a (client generated)
Options Options
Option (Uri-Host) Option (Uri-Host)
Option Delta = 0x3 (option# 3) Option Delta = 0x3 (option# 3)
Option Length = 0xB Option Length = 0xB
Option Value = "example.com" Option Value = "example.com"
Option (Uri-Port) Option (Uri-Port)
Option Delta = 0x4 (option# 3+4=7) Option Delta = 0x4 (option# 3+4=7)
skipping to change at line 1431 skipping to change at line 1552
Option Value = "est" Option Value = "est"
Option (Uri-Path) Option (Uri-Path)
Option Delta = 0x0 (option# 11+0=11) Option Delta = 0x0 (option# 11+0=11)
Option Length = 0x4 Option Length = 0x4
Option Value = "crts" Option Value = "crts"
Option (Accept) Option (Accept)
Option Delta = 0x6 (option# 11+6=17) Option Delta = 0x6 (option# 11+6=17)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Payload = [Empty] Payload = [Empty]
]]></artwork></figure> ]]></sourcecode>
<t>As specified in <xref target="RFC7252" sectionFormat="of"
section="5.10.1"/>, the Uri-Host and Uri-Port Options can be omitted
if they coincide with the transport protocol destination address and
port, respectively.</t>
<t>As specified in Section 5.10.1 of <xref target="RFC7252"/>, <t>A 2.05 Content response with a cert in EST-coaps will then be the follo
the Uri-Host and Uri-Port Options can be omitted if they wing:</t>
coincide with the transport protocol destination address <artwork><![CDATA[
and port respectively.</t>
<!--
The Uri-Host and Uri-Port Options can be omitted if they
coincide with the transport protocol destination address and
port respectively. Explicit Uri-Host and Uri-Port Options
are typically used when an endpoint hosts multiple virtual
servers and uses the Options to route the requests accordingly.
Alternatively, if a UDP port to a server is blocked,
someone could send the DTLS packets to a known open port
on the server and use the Uri-Port to convey the intended port
he is attempting to reach.-->
<t>A 2.05 Content response with a cert in EST-coaps will then be </t>
<figure align="left"><artwork><![CDATA[
2.05 Content (Content-Format: 281) 2.05 Content (Content-Format: 281)
{payload with certificate in binary format} {payload with certificate in binary format}
]]></artwork></figure> ]]></artwork>
<t>with CoAP fields </t> <t>With the following CoAP fields:</t>
<figure><artwork>
<![CDATA[ <sourcecode type="coap"><![CDATA[
Ver = 1 Ver = 1
T = 2 (ACK) T = 2 (ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied from request by server) Token = 0x9a (copied from request by server)
Options Options
Option (Content-Format) Option (Content-Format)
Option Delta = 0xC (option# 12) Option Delta = 0xC (option# 12)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
skipping to change at line 1492 skipping to change at line 1603
97edb8a0c72ab0d405f05d4fe29b997a14ccce89008313d09666b6ce375c 97edb8a0c72ab0d405f05d4fe29b997a14ccce89008313d09666b6ce375c
595fcc8e37f8e4354497011be90e56794bd91ad951ab45a3818430818130 595fcc8e37f8e4354497011be90e56794bd91ad951ab45a3818430818130
1d0603551d0e041604141df1208944d77b5f1d9dcb51ee244a523f3ef5de 1d0603551d0e041604141df1208944d77b5f1d9dcb51ee244a523f3ef5de
301f0603551d230418301680141df1208944d77b5f1d9dcb51ee244a523f 301f0603551d230418301680141df1208944d77b5f1d9dcb51ee244a523f
3ef5de300f0603551d130101ff040530030101ff300e0603551d0f0101ff 3ef5de300f0603551d130101ff040530030101ff300e0603551d0f0101ff
040403020106301e0603551d110417301581136365727469667940657861 040403020106301e0603551d110417301581136365727469667940657861
6d706c652e636f6d300a06082a8648ce3d040302034800304502202b891d 6d706c652e636f6d300a06082a8648ce3d040302034800304502202b891d
d411d07a6d6f621947635ba4c43165296b3f633726f02e51ecf464bd4002 d411d07a6d6f621947635ba4c43165296b3f633726f02e51ecf464bd4002
2100b4be8a80d08675f041fbc719acf3b39dedc85dc92b3035868cb2daa8 2100b4be8a80d08675f041fbc719acf3b39dedc85dc92b3035868cb2daa8
f05db196a1003100 f05db196a1003100
]]></artwork></figure> ]]></sourcecode>
<t>The breakdown of the payload is shown in <xref target="cacertsdis"/>. < <t>The payload is shown in plain text in <xref target="cacertsdis"
/t> format="default"/>. </t>
</section> <!-- cacerts --> </section>
<section title="enroll / reenroll"> <section numbered="true" toc="default">
<t> <name>enroll / reenroll</name>
During the (re-)enroll exchange the EST-coaps client uses a CSR
(Content-Format 286) request in the POST request payload.
The Accept option tells the server that the client is expecting
Content-Format 281 (PKCS#7) in the response.
As shown in <xref target="enrolldis"/>, the CSR contains a
ChallengePassword which is used for PoP linking (<xref target="pr
ofile7925"/>).
</t>
<figure align="left"><artwork><![CDATA[ <t>
During the (re-)enroll exchange, the EST-coaps client uses a CSR
(Content-Format 286) request in the POST request payload. The
Accept Option tells the server that the client is expecting
Content-Format 281 (PKCS #7) in the response. As shown in <xref
target="enrolldis" format="default"/>, the CSR contains a
challengePassword, which is used for POP linking (<xref
target="profile7925" format="default"/>).
</t>
<artwork><![CDATA[
POST [2001:db8::2:321]:61616/est/sen POST [2001:db8::2:321]:61616/est/sen
(Token: 0x45) (Token: 0x45)
(Accept: 281) (Accept: 281)
(Content-Format: 286) (Content-Format: 286)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
3082018b30820131020100305c310b3009060355040613025553310b3009 3082018b30820131020100305c310b3009060355040613025553310b3009
skipping to change at line 1530 skipping to change at line 1644
2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f 2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f
028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75 028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75
f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109 f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109
0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e 0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e
7634332323403d204e787e60303b06092a864886f70d01090e312e302c30 7634332323403d204e787e60303b06092a864886f70d01090e312e302c30
2a0603551d1104233021a01f06082b06010505070804a013301106092b06 2a0603551d1104233021a01f06082b06010505070804a013301106092b06
010401b43b0a01040401020304300a06082a8648ce3d0403020348003045 010401b43b0a01040401020304300a06082a8648ce3d0403020348003045
02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab 02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab
ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc
1135a1e84eed754377 1135a1e84eed754377
]]></artwork></figure> ]]></artwork>
<t>
<t>
After verification of the CSR by the server, a 2.04 Changed response After verification of the CSR by the server, a 2.04 Changed response
with the issued certificate will be returned to the client. with the issued certificate will be returned to the client.
</t> </t>
<artwork><![CDATA[
<figure align="left"><artwork><![CDATA[
2.04 Changed 2.04 Changed
(Token: 0x45) (Token: 0x45)
(Content-Format: 281) (Content-Format: 281)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
3082026e06092a864886f70d010702a082025f3082025b0201013100300b 3082026e06092a864886f70d010702a082025f3082025b0201013100300b
06092a864886f70d010701a08202413082023d308201e2a0030201020208 06092a864886f70d010701a08202413082023d308201e2a0030201020208
skipping to change at line 1567 skipping to change at line 1679
c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50c c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50c
ff958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b56 ff958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b56
38e59fd9a3818a30818730090603551d1304023000301d0603551d0e0416 38e59fd9a3818a30818730090603551d1304023000301d0603551d0e0416
041496600d8716bf7fd0e752d0ac760777ad665d02a0301f0603551d2304 041496600d8716bf7fd0e752d0ac760777ad665d02a0301f0603551d2304
183016801468d16551f951bfc82a431d0d9f08bc2d205b1160300e060355 183016801468d16551f951bfc82a431d0d9f08bc2d205b1160300e060355
1d0f0101ff0404030205a0302a0603551d1104233021a01f06082b060105 1d0f0101ff0404030205a0302a0603551d1104233021a01f06082b060105
05070804a013301106092b06010401b43b0a01040401020304300a06082a 05070804a013301106092b06010401b43b0a01040401020304300a06082a
8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94 8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94
91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d 91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d
832a4d336a08ad67df20f1506421188a0ade6d349236a1003100 832a4d336a08ad67df20f1506421188a0ade6d349236a1003100
]]></artwork></figure> ]]></artwork>
<t>The breakdown of the request and response is shown in <t>The request and response is shown in plain text in <xref
<xref target="enrolldis"/>.</t> target="enrolldis" format="default"/>.</t>
<!-- <t>As described in <xref target="pending" />, if
the server is not able to provide a response
immediately, it sends an empty ACK with response
code 5.03 (Service Unavailable) and the Max-Age Option.
See <xref target="fig-est-long-wait"/> for an example exchange.</
t> -->
</section> <!-- enroll / reenroll -->
<section anchor="appskg" title="serverkeygen"> </section>
<t>In a serverkeygen exchange the CoAP POST request looks like </t>
<figure align="left"><artwork><![CDATA[ <section anchor="appskg" numbered="true" toc="default">
<name>serverkeygen</name>
<t>In a serverkeygen exchange, the CoAP POST request looks like the foll
owing:</t>
<artwork><![CDATA[
POST 192.0.2.1:8085/est/skg POST 192.0.2.1:8085/est/skg
(Token: 0xa5) (Token: 0xa5)
(Accept: 62) (Accept: 62)
(Content-Format: 286) (Content-Format: 286)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
3081d03078020100301631143012060355040a0c0b736b67206578616d70 3081d03078020100301631143012060355040a0c0b736b67206578616d70
6c653059301306072a8648ce3d020106082a8648ce3d03010703420004c8 6c653059301306072a8648ce3d020106082a8648ce3d03010703420004c8
b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50cff b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50cff
958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b5638 958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b5638
e59fd9a000300a06082a8648ce3d040302034800304502207c553981b1fe e59fd9a000300a06082a8648ce3d040302034800304502207c553981b1fe
349249d8a3f50a0346336b7dfaa099cf74e1ec7a37a0a760485902210084 349249d8a3f50a0346336b7dfaa099cf74e1ec7a37a0a760485902210084
79295398774b2ff8e7e82abb0c17eaef344a5088fa69fd63ee611850c34b 79295398774b2ff8e7e82abb0c17eaef344a5088fa69fd63ee611850c34b
0a 0a
]]></artwork></figure> ]]></artwork>
<t>The response would follow <xref target="RFC8710" format="default"/> a
<t>The response would follow <xref target="I-D.ietf-core-multipart-ct"/> nd could look like the following:</t>
and could look like </t> <artwork><![CDATA[
<figure align="left"><artwork><![CDATA[
2.04 Changed 2.04 Changed
(Token: 0xa5) (Token: 0xa5)
(Content-Format: 62) (Content-Format: 62)
[ The hexadecimal representations below would NOT be transported [ The hexadecimal representations below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
84 # array(4) 84 # array(4)
19 011C # unsigned(284) 19 011C # unsigned(284)
skipping to change at line 1639 skipping to change at line 1743
3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351 3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351
cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75f602f915 cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75f602f915
2618f816a2b23b5638e59fd9a37b307930090603551d1304023000302c06 2618f816a2b23b5638e59fd9a37b307930090603551d1304023000302c06
096086480186f842010d041f161d4f70656e53534c2047656e6572617465 096086480186f842010d041f161d4f70656e53534c2047656e6572617465
64204365727469666963617465301d0603551d0e0416041496600d8716bf 64204365727469666963617465301d0603551d0e0416041496600d8716bf
7fd0e752d0ac760777ad665d02a0301f0603551d2304183016801496600d 7fd0e752d0ac760777ad665d02a0301f0603551d2304183016801496600d
8716bf7fd0e752d0ac760777ad665d02a0300a06082a8648ce3d04030203 8716bf7fd0e752d0ac760777ad665d02a0300a06082a8648ce3d04030203
48003045022100e95bfa25a08976652246f2d96143da39fce0dc4c9b26b9 48003045022100e95bfa25a08976652246f2d96143da39fce0dc4c9b26b9
cce1f24164cc2b12b602201351fd8eea65764e3459d324e4345ff5b2a915 cce1f24164cc2b12b602201351fd8eea65764e3459d324e4345ff5b2a915
38c04976111796b3698bf6379ca1003100 38c04976111796b3698bf6379ca1003100
]]></artwork></figure> ]]></artwork>
<t>The private key in the response above is without CMS EnvelopedData
<t>The private key in the response above is without CMS EnvelopedData and has no additional encryption beyond DTLS (<xref target="serverkey"
and has no additional encryption beyond DTLS (<xref target="serverkey"/ format="default"/>).</t>
>).</t> <t>The request and response is shown in plain text in <xref
<t>The breakdown of the request and response is shown target="disskgrequest" format="default"/>.</t>
in <xref target="disskgrequest"/></t> </section>
</section> <!-- serverkeygen -->
<section title="csrattrs"> <section numbered="true" toc="default">
<t>Below is a csrattrs exchange </t> <name>csrattrs</name>
<figure align="left"><artwork><![CDATA[ <t>The following is a csrattrs exchange:</t>
<artwork><![CDATA[
REQ: REQ:
GET example.com:61616/est/att GET example.com:61616/est/att
RES: RES:
2.05 Content 2.05 Content
(Content-Format: 285) (Content-Format: 285)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
307c06072b06010101011630220603883701311b131950617273652053455 307c06072b06010101011630220603883701311b131950617273652053455
420617320322e3939392e31206461746106092a864886f70d010907302c06 420617320322e3939392e31206461746106092a864886f70d010907302c06
0388370231250603883703060388370413195061727365205345542061732 0388370231250603883703060388370413195061727365205345542061732
0322e3939392e32206461746106092b240303020801010b06096086480165 0322e3939392e32206461746106092b240303020801010b06096086480165
03040202 03040202
]]></artwork></figure> ]]></artwork>
<t>A 2.05 Content response should contain attributes which are relevant <t>A 2.05 Content response should contain attributes that are
for the authenticated client. This example is copied from Section A.2 relevant for the authenticated client. This example is copied from
in <xref target="RFC7030"/>, where the base64 representation is replace <xref target="RFC7030" sectionFormat="of" section="A.2"/>, where the
d base64 representation is replaced with a hexadecimal representation of
with a hexadecimal representation of the equivalent binary format. the equivalent binary format. The EST-coaps server returns attributes
The EST-coaps server returns attributes that the client can ignore that the client can ignore if they are unknown to the client.</t>
if they are unknown to him.</t> </section>
</section> <!-- csrattrs -->
</section> <!-- EST messages to EST-coaps -->
<section anchor="blockexamples" title="EST-coaps Block message examples"> </section>
<t>Two examples are presented in this section:
<list style="numbers"> <section anchor="blockexamples" numbered="true" toc="default">
<t>a cacerts exchange shows the use of Block2 and the block headers</t> <name>EST-coaps Block Message Examples</name>
<t>an enroll exchange shows the Block1 and Block2 size negotiatio <t>Two examples are presented in this section:
n for request and </t>
response payloads.</t> <ol spacing="normal" type="1">
</list> </t> <li>A cacerts exchange shows the use of Block2 and the block headers.</l
<t>The payloads are shown unencrypted. In practice the message contents i>
<li>An enroll exchange shows the Block1 and Block2 size negotiation
for request and response payloads.</li>
</ol>
<t>The payloads are shown unencrypted. In practice, the message contents
would be binary formatted and transferred over an encrypted DTLS tunnel. would be binary formatted and transferred over an encrypted DTLS tunnel.
The corresponding CoAP headers are only shown in <xref target="cacertsblo ck"/>. The corresponding CoAP headers are only shown in <xref target="cacertsblo ck" format="default"/>.
Creating CoAP headers is assumed to be generally known.</t> Creating CoAP headers is assumed to be generally known.</t>
<section anchor="cacertsblock" numbered="true" toc="default">
<name>cacerts</name>
<section anchor="cacertsblock" title="cacerts"> <t>This section provides a detailed example of the messages using DTLS
<t>This section provides a detailed example of the messages using DTLS and B and CoAP Option Block2. The example block length is taken as 64,
LOCK which gives an SZX value of 2.</t>
option Block2. The example block length is taken as 64 which gives an <t>The following is an example of a cacerts exchange over DTLS. The
SZX value of 2.</t> content length of the cacerts response in <xref target="RFC7030"
<t>The following is an example of a cacerts exchange over DTLS. The content sectionFormat="of" section="A.1"/> contains 639 bytes in binary in
length of this example. The CoAP message adds around 10 bytes in this example,
the cacerts response in appendix A.1 of <xref target="RFC7030"/> contains and the DTLS record around 29 bytes. To avoid IP fragmentation, the
639 CoAP Block Option is used and an MTU of 127 is assumed to stay within
bytes in binary in this example. The CoAP message adds around 10 bytes in one IEEE 802.15.4 packet. To stay below the MTU of 127, the payload is
this exmple, split in 9 packets with a payload of 64 bytes each, followed by a
the DTLS record around 29 bytes. To avoid IP fragmentation, the CoAP Bloc last tenth packet of 63 bytes. The client sends an IPv6 packet
k Option containing a UDP datagram with DTLS record protection that
is used and an MTU of 127 is assumed to stay within one IEEE 802.15.4 pac encapsulates a CoAP request 10 times (one fragment of the request per
ket. To stay block). The server returns an IPv6 packet containing a UDP datagram
below the MTU of 127, the payload is split in 9 packets with a payload of with the DTLS record that encapsulates the CoAP response. The CoAP
64 bytes request-response exchange with block option is shown below. Block
each, followed by a last tenth packet of 63 bytes. The client sends an IP Option is shown in a decomposed way (block-option:NUM/M/size)
v6 packet indicating the kind of Block Option (2 in this case) followed by a
containing a UDP datagram with DTLS record protection that encapsulates a colon, and then the block number (NUM), the more bit (M = 0 in Block2
CoAP response means it is last block), and block size with exponent
request 10 times (one fragment of the request per block). The server retu (2<sup>(SZX+4)</sup>) separated by slashes. The Length 64 is used with
rns an IPv6 packet containing a UDP datagram with the SZX=2. The CoAP Request is sent Confirmable (CON), and the
DTLS record that encapsulates the CoAP response. The CoAP request-respons Content-Format of the response, even though not shown, is 281
e exchange with block (application/pkcs7-mime; smime-type=certs-only). The transfer of the
option is shown below. Block Option is shown in a decomposed way (block-o 10 blocks with partially filled block NUM=9 is shown below.</t>
ption:NUM/M/size)
indicating the kind of Block Option (2 in this case) followed by a colon, <sourcecode type="coap"><![CDATA[
and then the block
number (NUM), the more bit (M = 0 in Block2 response means it is last blo
ck), and block size
with exponent (2**(SZX+4)) separated by slashes. The Length 64 is used w
ith SZX=2. The CoAP Request is sent confirmable (CON) and the Content-Format
of the response, even though not shown, is 281 (application/pkcs7-mime; s
mime-type=certs-only).
The transfer of the 10 blocks with partially filled block NUM=9 is shown
below </t>
<figure align="left"><artwork><![CDATA[
GET example.com:9085/est/crts (2:0/0/64) --> GET example.com:9085/est/crts (2:0/0/64) -->
<-- (2:0/1/64) 2.05 Content <-- (2:0/1/64) 2.05 Content
GET example.com:9085/est/crts (2:1/0/64) --> GET example.com:9085/est/crts (2:1/0/64) -->
<-- (2:1/1/64) 2.05 Content <-- (2:1/1/64) 2.05 Content
| |
| |
| |
GET example.com:9085/est/crts (2:9/0/64) --> GET example.com:9085/est/crts (2:9/0/64) -->
<-- (2:9/0/64) 2.05 Content <-- (2:9/0/64) 2.05 Content
]]></artwork></figure> ]]></sourcecode>
<t>The header of the GET request looks like the following:</t>
<t>The header of the GET request looks like</t> <sourcecode type="coap"><![CDATA[
<figure><artwork>
<![CDATA[
Ver = 1 Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.1 GET) Code = 0x01 (0.1 GET)
Token = 0x9a (client generated) Token = 0x9a (client generated)
Options Options
Option (Uri-Host) Option (Uri-Host)
Option Delta = 0x3 (option# 3) Option Delta = 0x3 (option# 3)
Option Length = 0xB Option Length = 0xB
Option Value = "example.com" Option Value = "example.com"
Option (Uri-Port) Option (Uri-Port)
skipping to change at line 1750 skipping to change at line 1865
Option Value = "est" Option Value = "est"
Option (Uri-Path)Uri-Path) Option (Uri-Path)Uri-Path)
Option Delta = 0x0 (option# 11+0=11) Option Delta = 0x0 (option# 11+0=11)
Option Length = 0x4 Option Length = 0x4
Option Value = "crts" Option Value = "crts"
Option (Accept) Option (Accept)
Option Delta = 0x6 (option# 11+6=17) Option Delta = 0x6 (option# 11+6=17)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Payload = [Empty] Payload = [Empty]
]]></artwork></figure> ]]></sourcecode>
<t>The Uri-Host and Uri-Port Options can be omitted if they coincide
with the transport protocol destination address and port,
respectively. Explicit Uri-Host and Uri-Port Options are typically
used when an endpoint hosts multiple virtual servers and uses the
Options to route the requests accordingly. </t>
<t>The Uri-Host and Uri-Port Options can be omitted if they <t>To provide further details on the CoAP headers, the first two and the las
coincide with the transport protocol destination address and t blocks are
port respectively. Explicit Uri-Host and Uri-Port Options written out below. The header of the first Block2 response looks like the
are typically used when an endpoint hosts multiple virtual following:</t>
servers and uses the Options to route the requests accordingly. </t>
<!-- Alternatively, if a UDP port to a server is blocked,
someone could send the DTLS packets to a known open port
on the server and use the Uri-Port to convey the intended port
he is attempting to reach.-->
<t>For further detailing the CoAP headers, the first two and the last blocks <sourcecode type="coap"><![CDATA[
are Ver = 1
written out below. The header of the first Block2 response looks like</t>
<figure><artwork>
<![CDATA[ Ver = 1
T = 2 (ACK) T = 2 (ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied from request by server) Token = 0x9a (copied from request by server)
Options Options
Option Option
Option Delta = 0xC (option# 12 Content-Format) Option Delta = 0xC (option# 12 Content-Format)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Option Option
Option Delta = 0xB (option# 12+11=23 Block2) Option Delta = 0xB (option# 12+11=23 Block2)
skipping to change at line 1787 skipping to change at line 1898
Option Value = 0x0A (block#=0, M=1, SZX=2) Option Value = 0x0A (block#=0, M=1, SZX=2)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
Payload = Payload =
3082027b06092a864886f70d010702a082026c308202680201013100300b 3082027b06092a864886f70d010702a082026c308202680201013100300b
06092a864886f70d010701a082024e3082024a308201f0a0030201020209 06092a864886f70d010701a082024e3082024a308201f0a0030201020209
009189bc 009189bc
]]></artwork></figure> ]]></sourcecode>
<t>The header of the second Block2 response looks like the following:</t
>
<t>The second Block2:</t> <sourcecode type="coap"><![CDATA[
<figure><artwork> Ver = 1
<![CDATA[ Ver = 1
T = 2 (means ACK) T = 2 (means ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied from request by server) Token = 0x9a (copied from request by server)
Options Options
Option Option
Option Delta = 0xC (option# 12 Content-Format) Option Delta = 0xC (option# 12 Content-Format)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Option Option
Option Delta = 0xB (option 12+11=23 Block2) Option Delta = 0xB (option 12+11=23 Block2)
skipping to change at line 1813 skipping to change at line 1924
Option Value = 0x1A (block#=1, M=1, SZX=2) Option Value = 0x1A (block#=1, M=1, SZX=2)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
Payload = Payload =
df9c99244b300a06082a8648ce3d0403023067310b300906035504061302 df9c99244b300a06082a8648ce3d0403023067310b300906035504061302
5553310b300906035504080c024341310b300906035504070c024c413114 5553310b300906035504080c024341310b300906035504070c024c413114
30120603 30120603
]]></sourcecode>
<t>The header of the tenth and final Block2 response looks like the foll
owing:</t>
]]></artwork></figure> <sourcecode type="coap"><![CDATA[
Ver = 1
<t>The 10th and final Block2:</t>
<figure><artwork>
<![CDATA[ Ver = 1
T = 2 (means ACK) T = 2 (means ACK)
Code = 0x45 (2.05 Content) Code = 0x45 (2.05 Content)
Token = 0x9a (copied from request by server) Token = 0x9a (copied from request by server)
Options Options
Option Option
Option Delta = 0xC (option# 12 Content-Format) Option Delta = 0xC (option# 12 Content-Format)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Option Option
Option Delta = 0xB (option# 12+11=23 Block2 ) Option Delta = 0xB (option# 12+11=23 Block2 )
skipping to change at line 1840 skipping to change at line 1950
Option Value = 0x92 (block#=9, M=0, SZX=2) Option Value = 0x92 (block#=9, M=0, SZX=2)
[ The hexadecimal representation below would NOT be transported [ The hexadecimal representation below would NOT be transported
in hex, but in binary. Hex is used because a binary representation in hex, but in binary. Hex is used because a binary representation
cannot be rendered well in text. ] cannot be rendered well in text. ]
Payload = Payload =
2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a 2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a
e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1 e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1
003100 003100
]]></artwork></figure> ]]></sourcecode>
</section> <!-- cacerts block example --> </section>
<section anchor="enrollblock" title="enroll / reenroll"> <section anchor="enrollblock" numbered="true" toc="default">
<t> <name>enroll / reenroll</name>
In this example, the requested Block2 size of 256 bytes, required by the c <t>
lient, In this example, the requested Block2 size of 256 bytes, required by the
is transferred to the server in the very first request message. The blo client, is transferred to the server in the very first request
ck size message. The block size of 256 is equal to (2<sup>(SZX+4)</sup>), which
256=(2**(SZX+4)) which gives SZX=4. The notation for block numbering is gives SZX=4. The notation for block numbering is the same as in <xref
the same target="cacertsblock" format="default"/>. The header fields and the
as in <xref target="cacertsblock"/>. The header fields and the payload payload are omitted for brevity.
are </t>
omitted for brevity.
</t>
<figure title="EST-COAP enrollment with multiple blocks"
anchor="fig-est-multiple-block"><artwork>
<![CDATA[
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> <figure anchor="fig-est-multiple-block">
<name>EST-coaps Enrollment with Multiple Blocks</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256)
{CSR (frag# 1)} -->
<-- (ACK) (1:0/1/256) (2.31 Continue) <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256)
{CSR (frag# 2)} -->
<-- (ACK) (1:1/1/256) (2.31 Continue) <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR(frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256)
{CSR(frag# N1+1)}-->
| |
...........Immediate response ......... ...........Immediate response .........
| |
<-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp (frag# 1)} <-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed)
{Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp (frag# 2)} <-- (ACK) (2:1/1/256)(2.04 Changed)
{Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) --> POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} <-- (ACK) (2:N2/0/256) (2.04 Changed)
{Cert resp (frag# N2+1)}
]]></artwork></figure> ]]></artwork>
</figure>
<t>N1+1 blocks have been transferred from client to the server and N2+1 bl <t>N1+1 blocks have been transferred from client to server, and N2+1 blo
ocks have been cks have been
transferred from server to client.</t> transferred from server to client.</t>
</section> <!-- enroll block example --> </section>
</section> <!-- EST-coaps Block message examples -->
<section anchor="cont_breakdown" title="Message content breakdown"> </section>
<t>This appendix presents the breakdown of the hexadecimal dumps of the
binary payloads shown in <xref target="messagebindings"/>. <section anchor="cont_breakdown" numbered="true" toc="default">
<name>Message Content Breakdown</name>
<t>This appendix presents the hexadecimal dumps of the binary payloads
in plain text shown in <xref target="messagebindings"
format="default"/>.
</t> </t>
<section anchor="cacertsdis" title="cacerts"> <section anchor="cacertsdis" numbered="true" toc="default">
<t>The breakdown of cacerts response containing one root CA certificate is <name>cacerts</name>
</t> <t>The cacerts response containing one root CA certificate is
<figure align="left"><artwork><![CDATA[ presented in plain text in the following: </t>
<sourcecode type="asn.1"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 831953162763987486 (0xb8bb0fe604f6a1e) Serial Number: 831953162763987486 (0xb8bb0fe604f6a1e)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=CA, L=LA, O=Example Inc, Issuer: C=US, ST=CA, L=LA, O=Example Inc,
OU=certification, CN=Root CA OU=certification, CN=Root CA
Validity Validity
Not Before: Jan 31 11:27:03 2019 GMT Not Before: Jan 31 11:27:03 2019 GMT
Not After : Jan 26 11:27:03 2039 GMT Not After : Jan 26 11:27:03 2039 GMT
skipping to change at line 1931 skipping to change at line 2054
CA:TRUE CA:TRUE
X509v3 Key Usage: critical X509v3 Key Usage: critical
Certificate Sign, CRL Sign Certificate Sign, CRL Sign
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
email:certify@example.com email:certify@example.com
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:2b:89:1d:d4:11:d0:7a:6d:6f:62:19:47:63:5b: 30:45:02:20:2b:89:1d:d4:11:d0:7a:6d:6f:62:19:47:63:5b:
a4:c4:31:65:29:6b:3f:63:37:26:f0:2e:51:ec:f4:64:bd:40: a4:c4:31:65:29:6b:3f:63:37:26:f0:2e:51:ec:f4:64:bd:40:
02:21:00:b4:be:8a:80:d0:86:75:f0:41:fb:c7:19:ac:f3:b3: 02:21:00:b4:be:8a:80:d0:86:75:f0:41:fb:c7:19:ac:f3:b3:
9d:ed:c8:5d:c9:2b:30:35:86:8c:b2:da:a8:f0:5d:b1:96 9d:ed:c8:5d:c9:2b:30:35:86:8c:b2:da:a8:f0:5d:b1:96
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <!-- cacerts payload breakdown -->
<section anchor="enrolldis" title="enroll / reenroll">
<t>The breakdown of the enrollment request is </t>
<figure align="left"><artwork><![CDATA[ <section anchor="enrolldis" numbered="true" toc="default">
<name>enroll / reenroll</name>
<t>The enrollment request is presented in plain text in the
following:</t>
<sourcecode type="asn.1"><![CDATA[
Certificate Request: Certificate Request:
Data: Data:
Version: 0 (0x0) Version: 0 (0x0)
Subject: C=US, ST=CA, L=LA, O=example Inc, Subject: C=US, ST=CA, L=LA, O=example Inc,
OU=IoT/serialNumber=Wt1234 OU=IoT/serialNumber=Wt1234
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
56:38:e5:9f:d9 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
Attributes: Attributes:
challengePassword: <256-bit PoP linking value> challengePassword: <256-bit POP linking value>
Requested Extensions: Requested Extensions:
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
othername:<unsupported> othername:<unsupported>
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd: 30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd:
1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38: 1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38:
92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b: 92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b:
c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77 c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77
]]></sourcecode>
]]></artwork></figure> <t>The CSR contains a challengePassword, which is used for POP linking
(<xref target="profile7925" format="default"/>). The CSR also contains
<t>The CSR contains a ChallengePassword which is used for an id-on-hardwareModuleName hardware identifier to customize the
PoP linking (<xref target="profile7925"/>). The CSR also contains returned certificate to the requesting device (See <xref
an id-on-hardwareModuleName hardware identifier to customize the target="RFC7299" format="default"/> and <xref
returned certificate to the requesting device (See <xref target ="RFC7299"/> and target="I-D.moskowitz-ecdsa-pki" format="default"/>).</t>
<xref target="I-D.moskowitz-ecdsa-pki"/>).</t> <t>The issued certificate presented in plain text in the following:</t>
<sourcecode type="asn.1"><![CDATA[
<t>The breakdown of the issued certificate is </t>
<figure align="left"><artwork><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 9112578475118446130 (0x7e7661d7b54e4632) Serial Number: 9112578475118446130 (0x7e7661d7b54e4632)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=CA, O=Example Inc, Issuer: C=US, ST=CA, O=Example Inc,
OU=certification, CN=802.1AR CA OU=certification, CN=802.1AR CA
Validity Validity
Not Before: Jan 31 11:29:16 2019 GMT Not Before: Jan 31 11:29:16 2019 GMT
Not After : Dec 31 23:59:59 9999 GMT Not After : Dec 31 23:59:59 9999 GMT
skipping to change at line 2017 skipping to change at line 2138
X509v3 Key Usage: critical X509v3 Key Usage: critical
Digital Signature, Key Encipherment Digital Signature, Key Encipherment
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
othername:<unsupported> othername:<unsupported>
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:c0:d8:19:96:d2:50:7d:69:3f:3c:48:ea:a5: 30:46:02:21:00:c0:d8:19:96:d2:50:7d:69:3f:3c:48:ea:a5:
ee:94:91:bd:a6:db:21:40:99:d9:81:17:c6:3b:36:13:74:cd: ee:94:91:bd:a6:db:21:40:99:d9:81:17:c6:3b:36:13:74:cd:
86:02:21:00:a7:74:98:9f:4c:32:1a:5c:f2:5d:83:2a:4d:33: 86:02:21:00:a7:74:98:9f:4c:32:1a:5c:f2:5d:83:2a:4d:33:
6a:08:ad:67:df:20:f1:50:64:21:18:8a:0a:de:6d:34:92:36 6a:08:ad:67:df:20:f1:50:64:21:18:8a:0a:de:6d:34:92:36
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <!-- Re-enroll message breakdown -->
<section anchor="disskgrequest" title="serverkeygen"> <section anchor="disskgrequest" numbered="true" toc="default">
<t>The following is the breakdown of the server-side key generation request <name>serverkeygen</name>
.</t> <t>The following is the server-side key generation request presented in
<figure align="left"><artwork><![CDATA[ plain text:</t>
<sourcecode type="asn.1"><![CDATA[
Certificate Request: Certificate Request:
Data: Data:
Version: 0 (0x0) Version: 0 (0x0)
Subject: O=skg example Subject: O=skg example
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
skipping to change at line 2046 skipping to change at line 2167
56:38:e5:9f:d9 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
Attributes: Attributes:
a0:00 a0:00
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:7c:55:39:81:b1:fe:34:92:49:d8:a3:f5:0a:03: 30:45:02:20:7c:55:39:81:b1:fe:34:92:49:d8:a3:f5:0a:03:
46:33:6b:7d:fa:a0:99:cf:74:e1:ec:7a:37:a0:a7:60:48:59: 46:33:6b:7d:fa:a0:99:cf:74:e1:ec:7a:37:a0:a7:60:48:59:
02:21:00:84:79:29:53:98:77:4b:2f:f8:e7:e8:2a:bb:0c:17: 02:21:00:84:79:29:53:98:77:4b:2f:f8:e7:e8:2a:bb:0c:17:
ea:ef:34:4a:50:88:fa:69:fd:63:ee:61:18:50:c3:4b:0a ea:ef:34:4a:50:88:fa:69:fd:63:ee:61:18:50:c3:4b:0a
]]></artwork></figure> ]]></sourcecode>
<t>The following is the private key content of the server-side key
<t>Following is the breakdown of the private key content generation response presented in plain text: </t>
of the server-side key generation response. </t>
<figure align="left"><artwork><![CDATA[ <artwork><![CDATA[
Private-Key: (256 bit) Private-Key: (256 bit)
priv: priv:
61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e: 61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e:
6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f: 6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f:
0c:37 0c:37
pub: pub:
04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
56:38:e5:9f:d9 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
]]></artwork></figure> ]]></artwork>
<t>The following is the certificate in the server-side key generation
<t>The following is the breakdown of the certificate response payload presented in plain text:</t>
in the server-side key generation response payload.</t>
<figure align="left"><artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
b3:31:3e:8f:3f:c9:53:8e b3:31:3e:8f:3f:c9:53:8e
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: O=skg example Issuer: O=skg example
Validity Validity
Not Before: Sep 4 07:44:03 2019 GMT Not Before: Sep 4 07:44:03 2019 GMT
Not After : Aug 30 07:44:03 2039 GMT Not After : Aug 30 07:44:03 2039 GMT
skipping to change at line 2109 skipping to change at line 2228
96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0
X509v3 Authority Key Identifier: X509v3 Authority Key Identifier:
keyid: keyid:
96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:e9:5b:fa:25:a0:89:76:65:22:46:f2:d9:61: 30:45:02:21:00:e9:5b:fa:25:a0:89:76:65:22:46:f2:d9:61:
43:da:39:fc:e0:dc:4c:9b:26:b9:cc:e1:f2:41:64:cc:2b:12: 43:da:39:fc:e0:dc:4c:9b:26:b9:cc:e1:f2:41:64:cc:2b:12:
b6:02:20:13:51:fd:8e:ea:65:76:4e:34:59:d3:24:e4:34:5f: b6:02:20:13:51:fd:8e:ea:65:76:4e:34:59:d3:24:e4:34:5f:
f5:b2:a9:15:38:c0:49:76:11:17:96:b3:69:8b:f6:37:9c f5:b2:a9:15:38:c0:49:76:11:17:96:b3:69:8b:f6:37:9c
]]></artwork></figure> ]]></sourcecode>
</section> <!-- serverkey generation breakdown --> </section>
</section> <!-- Message Content Brakdown --> </section>
</back> <section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors are very grateful to <contact fullname="Klaus Hartke"/>
for his detailed explanations on the use of Block with DTLS and his
support for the Content-Format specification. The authors would like to
thank <contact fullname="Esko Dijk"/> and <contact fullname="Michael
Verschoor"/> for the valuable discussions that helped in shaping the
solution. They would also like to thank <contact fullname="Peter
Panburana"/> for his feedback on technical details of the
solution. Constructive comments were received from <contact
fullname="Benjamin Kaduk"/>, <contact fullname="Eliot Lear"/>, <contact
fullname="Jim Schaad"/>, <contact fullname="Hannes Tschofenig"/>,
<contact fullname="Julien Vermillard"/>, <contact fullname="John
Manuel"/>, <contact fullname="Oliver Pfaff"/>, <contact fullname="Pete
Beal"/>, and <contact fullname="Carsten Bormann"/>.</t>
<t>Interop tests were done by <contact fullname="Oliver Pfaff"/>,
<contact fullname="Thomas Werner"/>, <contact fullname="Oskar Camezind"/>,
<contact fullname="Bjorn Elmers"/>, and <contact fullname="Joel Hoglund"/
>.</t>
<t><contact fullname="Robert Moskowitz"/> provided code to create the exam
ples.</t>
</section>
<section anchor="contrib" numbered="false" toc="default">
<name>Contributors</name>
<t><contact fullname="Martin Furuhed"/> contributed to the EST-coaps
specification by providing feedback based on the Nexus EST-over-CoAPS
server implementation that started in 2015. <contact fullname="Sandeep
Kumar"/> kick-started this specification and was instrumental in drawing
attention to the importance of the subject. </t>
</section>
</back>
</rfc> </rfc>
 End of changes. 211 change blocks. 
1840 lines changed or deleted 1629 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/