--- 1/draft-ietf-ace-coap-est-09.txt 2019-03-08 06:14:07.102285593 -0800 +++ 2/draft-ietf-ace-coap-est-10.txt 2019-03-08 06:14:07.306290554 -0800 @@ -1,23 +1,23 @@ ACE P. van der Stok Internet-Draft Consultant Intended status: Standards Track P. Kampanakis -Expires: August 31, 2019 Cisco Systems +Expires: September 9, 2019 Cisco Systems M. Richardson SSW S. Raza RISE SICS - February 27, 2019 + March 8, 2019 EST over secure CoAP (EST-coaps) - draft-ietf-ace-coap-est-09 + draft-ietf-ace-coap-est-10 Abstract Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 31, 2019. + This Internet-Draft will expire on September 9, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,63 +51,76 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 6 + 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9 - 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 11 + 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14 - 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 14 - 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 15 - 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 17 + 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15 + 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16 + 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19 - 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 21 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 21 - 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22 + 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22 + 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10.1. EST server considerations . . . . . . . . . . . . . . . 23 - 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 24 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 + 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 - 13.2. Informative References . . . . . . . . . . . . . . . . . 27 + 13.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30 - A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 30 + A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. EST-coaps Block message examples . . . . . . . . . . 37 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41 Appendix C. Message content breakdown . . . . . . . . . . . . . 42 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Change Log EDNOTE: Remove this section before publication + -10 + + Addressed WGLC comments + + More consistent request format in the examples. + + Explained root resource difference when there is resource + discovery + + Clarified when the client is supposed to do discovery + + Fixed nits and minor Option length inaccurracies in the examples. + -09 WGLC comments taken into account consensus about discovery of content-format added additional path for content-format selection merged DTLS sections @@ -406,35 +417,34 @@ o Server-side key generation messages to provide a private client identity key when the client choses so. 5.1. Discovery and URIs EST-coaps is targeted for low-resource networks with small packets. Saving header space is important and short EST-coaps URIs are specified in this document. These URIs are shorter than the ones in [RFC7030]. Two example EST-coaps resource path names are: - coaps://est-coaps.example.org:/.well-known/est/ - coaps://est-coaps.example.org:/.well-known/est/ + coaps://example.com:/.well-known/est/ + coaps://example.com:/.well-known/est/ ArbitraryLabel/ - The short-est strings are defined in Table 1. The ArbitraryLabel - path-segment, if used, SHOULD be of the shortest length possible - (Sections 3.1 and 3.2.2 of [RFC7030]. Arbitrary Labels are usually - defined and used by EST CAs in order to route client requests to the - appropriate certificate profile. + The short-est strings are defined in Table 1. Arbitrary Labels are + usually defined and used by EST CAs in order to route client requests + to the appropriate certificate profile. Implementers should consider + using short labels to minimize transmission overhead. The EST-coaps server URIs, obtained through discovery of the EST- - coaps root resource(s) as shown below, are of the form: + coaps resource(s) as shown below, are of the form: - coaps://est-coaps.example.org:// - coaps://est-coaps.example.org:// + coaps://example.com:// + coaps://example.com:// ArbitraryLabel/ Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and corresponding paths which are supported by EST. Table 1 provides the mapping from the EST URI path to the shorter EST-coaps URI path. +------------------+-------------------------------+ | EST | EST-coaps | +------------------+-------------------------------+ | /cacerts | /crts | @@ -445,21 +455,21 @@ | /serverkeygen | /skc (application/pkix-cert) | +------------------+-------------------------------+ Table 1: Short EST-coaps URI path The /skg message is the EST /serverkeygen equivalent where the client requests for a certificate in PKCS#7 format and a private key. If the client prefers a single application/pkix-cert certificate instead of PKCS#7, he will make an /skc request. - Clients and servers MUST support the short resource URIs. + Clients and servers MUST support the short resource EST-coaps URIs. In the context of CoAP, the presence and location of (path to) the management data are discovered by sending a GET request to "/.well- known/core" including a resource type (RT) parameter with the value "ace.est*" [RFC6690]. Upon success, the return payload will contain the root resource of the EST resources. The example below shows the discovery of the presence and location of EST-coaps resources. Linefeeds are included only for readability. REQ: GET /.well-known/core?rt=ace.est* @@ -469,21 +479,22 @@ ;rt="ace.est.sen";ct="281 TBD287", ;rt="ace.est.sren";ct="281 TBD287", ;rt="ace.est.att";ct=285, ;rt="ace.est.skg";ct=62, ;rt="ace.est.skc";ct=62 The first three lines of the discovery response above MUST be returned if the server supports resource discovery. The last three lines are only included if the corresponding EST functions are implemented. The Content-Formats in the response allow the client to - request one that is supported by the server. + request one that is supported by the server. These are the values + that would be sent in the client request with an Accept option. Discoverable port numbers can be returned in the response payload. An example response payload for non-default CoAPS server port 61617 follows below. Linefeeds were included only for readability. REQ: GET /.well-known/core?rt=ace.est* RES: 2.05 Content ;rt="ace.est.crts"; ct="281 TBD287", @@ -494,24 +505,24 @@ ;rt="ace.est.att"; ct=285, ;rt="ace.est.skg"; ct=62, ;rt="ace.est.skc"; ct=62 The server MUST support the default /.well-known/est root resource. The server SHOULD support resource discovery when he supports non- default URIs (like /est or /est/ArbitraryLabel) or ports. The client - SHOULD use resource discovery when /.well-known/est fails or when the - client is unaware of the available EST-coaps resources. + SHOULD use resource discovery when he is unaware of the available + EST-coaps resources. - It is up to the implementation to choose its root resource; + It is up to the implementation to choose its resource paths; throughout this document the example root resource /est is used. 5.2. Mandatory/optional EST Functions This specification contains a set of required-to-implement functions, optional functions, and not specified functions. The latter ones are deemed too expensive for low-resource devices in payload and calculation times. Table 2 specifies the mandatory-to-implement or optional @@ -593,28 +604,30 @@ container) with Content-Format identifier TBD287 (0x011F) instead of 281. In cases where the private key is encrypted with CMS (as explained in Section 5.8) the Content-Format identifier is 280 (0x0118) instead of 284. The key and certificate representations are ASN.1 encoded in binary format. An example is shown in Appendix A.3. 5.4. Message Bindings The general EST-coaps message characteristics are: - o All EST-coaps request messages expect an acknowledgement (with a - response payload); EST-coaps requests are confirmable CON CoAP - messages. + o EST-coaps servers sometimes need to provide delayed responses + which are conveyed with an empty ACK or an ACK containing response + code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED + for implementers to send EST-coaps requests in confirmable CON + CoAP messages. o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- Format, Block, Accept and Location-Path. 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 + 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 [RFC7252]. o EST URLs are HTTPS based (https://), in CoAP these are assumed to be translated to CoAPS (coaps://) @@ -932,21 +945,21 @@ If necessary, the EST-coaps-to-HTTP Registrar will support resouce discovery according to the rules in Section 5.1. 7. Parameters This section addresses transmission parameters described in sections 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on the CoAP parameters in [RFC7252], but the EST parameter values need to be tuned to the CoAP parameter values. - It is RECOMMENDED, based on experiments, to follow the default CoAP + It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). However, depending on the implementation scenario, retransmissions and timeouts can also occur on other networking layers, governed by other configuration parameters. A change in a server parameter MUST ensure the adjusted value is also available to all the endpoints with which these adjusted values are to be used to communicate. Some further comments about some specific parameters, mainly from Table 2 in [RFC7252]: @@ -1244,23 +1257,23 @@ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 13.2. Informative References [COREparams] - IANA, "Constrained RESTful Environments (CoRE) - Parameters", . + "Constrained RESTful Environments (CoRE) Parameters", + . [I-D.ietf-lamps-rfc5751-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", draft-ietf-lamps-rfc5751-bis-12 (work in progress), September 2018. [I-D.ietf-tls-dtls-connection-id] Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, "Connection Identifiers for DTLS 1.2", draft-ietf-tls- @@ -1270,31 +1283,28 @@ Josefsson, S., "Channel Bindings for TLS based on the PRF", draft-josefsson-sasl-tls-cb-03 (work in progress), March 2015. [I-D.moskowitz-ecdsa-pki] Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, "Guide for building an ECC pki", draft-moskowitz-ecdsa- pki-04 (work in progress), September 2018. [ieee802.15.4] - Institute of Electrical and Electronics Engineers, "IEEE - Standard 802.15.4-2006", 2006. + "IEEE Standard 802.15.4-2006", 2006. [ieee802.1ar] - Institute of Electrical and Electronics Engineers, "IEEE - 802.1AR Secure Device Identifier", December 2009. + "IEEE 802.1AR Secure Device Identifier", December 2009. - [PsQs] Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex - Halderman, "Mining Your Ps and Qs: Detection of Widespread - Weak Keys in Network Devices", USENIX Security Symposium - 2012 ISBN 978-931971-95-9, August 2012. + [PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys + in Network Devices", USENIX Security Symposium 2012 ISBN + 978-931971-95-9, August 2012. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . @@ -1346,76 +1356,76 @@ Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . - [RSAorig] Petr Svenda, Matus Nemec, Peter Sekan, Rudolf Kvasnovsky, - David Formanek, David Komarek, Vashek Matyas, "The - Million-Key Question - Investigating the Origins of RSA - Public Keys", USENIX Security Symposium 2016 ISBN + [RSAorig] "The Million-Key Question - Investigating the Origins of + RSA Public Keys", USENIX Security Symposium 2016 ISBN 978-1-931971-32-4, August 2016. [tripleshake] - Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cedric - Fournet, Alfredo Pironti, Pierre-Yves Strub, "Triple - Handshakes and Cookie Cutters: Breaking and Fixing + "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Security and Privacy ISBN 978-1-4799-4686-0, May 2014. Appendix A. EST messages to EST-coaps This section shows similar examples to the ones presented in Appendix A of [RFC7030]. The payloads in the examples are the hex encoded binary, generated with 'xxd -p', of the PKI certificates created following [I-D.moskowitz-ecdsa-pki]. 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 tunnel. The certificate responses included in the examples contain Content- Format 281 (application/pkcs7). If the client had requested Content- Format TBD287 (application/pkix-cert) by querying /est/skc, the server would respond with a single DER binary certificate. - These examples assume a short root resource path of "/est". + 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 Section 5.1. The corresponding CoAP headers are only shown in Appendix A.1. Creating CoAP headers is assumed to be generally understood. The message content breakdown is presented in Appendix C. A.1. cacerts In EST-coaps, a cacerts message can be: - GET coaps://est-coaps.example.org:9085/est/crts + GET example.com:9085/est/crts (Accept: 281) The corresponding CoAP header fields are shown below. The use of block and DTLS are worked out in Appendix B. Ver = 1 T = 0 (CON) Code = 0x01 (0.01 is GET) Token = 0x9a (client generated) Options Option (Uri-Host) Option Delta = 0x3 (option# 3) - Option Length = 0x9 - Option Value = est-coaps.example.org + Option Length = 0xD + Option Value = "example.com" Option (Uri-Port) Option Delta = 0x4 (option# 3+4=7) Option Length = 0x4 Option Value = 9085 Option (Uri-Path) Option Delta = 0x4 (option# 7+4=11) Option Length = 0x5 Option Value = "est" Option (Uri-Path) Option Delta = 0x0 (option# 11+0=11) @@ -1481,21 +1492,21 @@ A.2. enroll / reenroll 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 Appendix C.2, the CSR contains a ChallengePassword which is used for POP linking (Section 4). - POST [2001:db8::2:1]:61616/est/sen + POST [2001:db8::2:321]:61616/est/sen (Token: 0x45) (Accept: 281) (Content-Format: 286) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 3082018b30820131020100305c310b3009060355040613025553310b3009 06035504080c024341310b300906035504070c024c413114301206035504 @@ -1543,21 +1554,21 @@ 05070804a013301106092b06010401b43b0a01040401020304300a06082a 8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94 91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d 832a4d336a08ad67df20f1506421188a0ade6d349236a1003100 The breakdown of the request and response is shown in Appendix C.2. A.3. serverkeygen In a serverkeygen exchange the CoAP POST request looks like - POST coaps://192.0.2.1:8085/est/skg + POST 192.0.2.1:8085/est/skg (Token: 0xa5) (Accept: 62) (Content-Format: 286) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 3081cf3078020100301631143012060355040a0c0b736b67206578616d70 6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b @@ -1606,21 +1617,21 @@ The private key in the response above is without CMS EnvelopedData and has no additional encryption beyond DTLS (Section 5.8). The breakdown of the request and response is shown in Appendix C.3 A.4. csrattrs Below is a csrattrs exchange REQ: - GET coaps://[2001:db8::2:1]:61616/est/att + GET example.com:61616/est/att RES: 2.05 Content (Content-Format: 285) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 307c06072b06010101011630220603883701311b131950617273652053455 @@ -1674,40 +1685,40 @@ option:NUM/M/size) indicating the kind of Block Option (2 in this case) followed by a colon, and then the block number (NUM), the more bit (M = 0 in Block2 response means it is last block), and block size with exponent (2**(SZX+4)) separated by slashes. The Length 64 is used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent confirmable (CON) and the Content-Format of the response, even though not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). The transfer of the 10 blocks with partially filled block NUM=9 is shown below - GET coaps://est-coaps.example.org:9085/est/crts (2:0/0/64) --> + GET example.com:9085/est/crts (2:0/0/64) --> <-- (2:0/1/64) 2.05 Content - GET coaps://est-coaps.example.org:9085/est/crts (2:1/0/64) --> + GET example.com:9085/est/crts (2:1/0/64) --> <-- (2:1/1/64) 2.05 Content | | | - GET coaps://est-coaps.example.org:9085/est/crts (2:9/0/64) --> + GET example.com:9085/est/crts (2:9/0/64) --> <-- (2:9/0/64) 2.05 Content The header of the GET request looks like Ver = 1 T = 0 (CON) Code = 0x01 (0.1 GET) Token = 0x9a (client generated) Options Option (Uri-Host) Option Delta = 0x3 (option# 3) - Option Length = 0x9 - Option Value = est-coaps.example.org + Option Length = 0xD + Option Value = "example.com" Option (Uri-Port) Option Delta = 0x4 (option# 3+4=7) Option Length = 0x4 Option Value = 9085 Option (Uri-Path) Option Delta = 0x4 (option# 7+4=11) Option Length = 0x5 Option Value = "est" Option (Uri-Path)Uri-Path) Option Delta = 0x0 (option# 11+0=11) @@ -1781,55 +1792,55 @@ T = 2 (means ACK) Code = 0x45 (2.05 Content) Token = 0x9a (copied from request by server) Options Option Option Delta = 0xC (option# 12 Content-Format) Option Length = 0x2 Option Value = 281 Option Option Delta = 0xB (option# 12+11=23 Block2 ) - Option Length = 0x2 + Option Length = 0x1 Option Value = 0x92 (block#=9, M=0, SZX=2) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] Payload = 2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1 003100 B.2. enroll / reenroll In this example, the requested Block2 size of 256 bytes, required by the client, is transferred to the server in the very first request message. The block size 256=(2**(SZX+4)) which gives SZX=4. The notation for block numbering is the same as in Appendix B.1. The header fields and the payload are omitted for brevity. - POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> + POST [2001:db8::2:321]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> <-- (ACK) (1:0/1/256) (2.31 Continue) - POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> + POST [2001:db8::2:321]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . - POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> + POST [2001:db8::2:321]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> <-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp} - POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> + POST [2001:db8::2:321]:61616/est/sen (CON)(2:1/0/256) --> <-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp} . . . - POST [2001:db8::2:1]: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} Figure 5: EST-COAP enrollment with multiple blocks N1+1 blocks have been transferred from client to the server and N2+1 blocks have been transferred from server to client. Appendix C. Message content breakdown This appendix presents the breakdown of the hexadecimal dumps of the