idnits 2.17.1 draft-ietf-ace-coap-est-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2019) is 1907 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Empty' is mentioned on line 1759, but not defined == Unused Reference: 'I-D.ietf-lamps-rfc5751-bis' is defined on line 1277, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-core-multipart-ct-02 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5967 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-19 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-02 == Outdated reference: A later version (-10) exists of draft-moskowitz-ecdsa-pki-04 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE P. van der Stok 3 Internet-Draft Consultant 4 Intended status: Standards Track P. Kampanakis 5 Expires: August 10, 2019 Cisco Systems 6 M. Richardson 7 SSW 8 S. Raza 9 RISE SICS 10 February 6, 2019 12 EST over secure CoAP (EST-coaps) 13 draft-ietf-ace-coap-est-08 15 Abstract 17 Enrollment over Secure Transport (EST) is used as a certificate 18 provisioning protocol over HTTPS. Low-resource devices often use the 19 lightweight Constrained Application Protocol (CoAP) for message 20 exchanges. This document defines how to transport EST payloads over 21 secure CoAP (EST-coaps), which allows constrained devices to use 22 existing EST functionality for provisioning certificates. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 10, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Conformance to RFC7925 profiles . . . . . . . . . . . . . . . 6 62 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 8 64 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 10 65 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 10 66 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 12 67 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 13 68 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 13 69 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 14 70 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 16 71 6. DTLS Transport Protocol . . . . . . . . . . . . . . . . . . . 18 72 7. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19 73 8. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 9. Deployment limitations . . . . . . . . . . . . . . . . . . . 21 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 10.1. Content-Format Registry . . . . . . . . . . . . . . . . 22 77 10.2. Resource Type registry . . . . . . . . . . . . . . . . . 22 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 11.1. EST server considerations . . . . . . . . . . . . . . . 23 80 11.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25 81 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 85 14.2. Informative References . . . . . . . . . . . . . . . . . 28 86 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30 87 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 33 89 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 35 90 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 37 91 Appendix B. EST-coaps Block message examples . . . . . . . . . . 38 92 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 42 94 Appendix C. Message content breakdown . . . . . . . . . . . . . 43 95 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45 97 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 46 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 100 1. Change Log 102 EDNOTE: Remove this section before publication 104 -08 106 added application/pkix-cert Content-Format TBD287. 108 Stated that well-known/est is compulsory 110 Use of response codes clarified. 112 removed bugs: Max-Age and Content-Format Options in Request 114 Accept Option explained for est/skg and added in enroll example 116 Persistenc of DTLS connection clarified. 118 Minor text fixes. 120 -07: 122 redone examples from scratch with openssl 124 Updated authors. 126 Added CoAP RST as a MAY for an equivalent to an HTTP 204 message. 128 Added serialization example of the /skg CBOR response. 130 Added text regarding expired IDevIDs and persistent DTLS 131 connection that will start using the Explicit TA Database in the 132 new DTLS connection. 134 Nits and fixes 136 Removed CBOR envelop for binary data 138 Replaced TBD8 with 62. 140 Added RFC8174 reference and text. 142 Clarified MTI for server-side key generation and Content-Formats. 143 Defined the /skg MTI (PKCS#8) and the cases where CMS encryption 144 will be used. 146 Moved Fragmentation section up because it was referenced in 147 sections above it. 149 -06: 151 clarified discovery section, by specifying that no discovery may 152 be needed for /.well-known/est URI. 154 added resource type values for IANA 156 added list of compulsory to implement and optional functions. 158 Fixed issues pointed out by the idnits tool. 160 Updated CoAP response codes section with more mappings between EST 161 HTTP codes and EST-coaps CoAP codes. 163 Minor updates to the MTI EST Functions section. 165 Moved Change Log section higher. 167 -05: 169 repaired again 171 TBD8 = 62 removed from C-F registration, to be done in CT draft. 173 -04: 175 Updated Delayed response section to reflect short and long delay 176 options. 178 -03: 180 Removed observe and simplified long waits 182 Repaired Content-Format specification 184 -02: 186 Added parameter discussion in section 8 188 Concluded Content-Format specification using multipart-ct draft 190 examples updated 192 -01: 194 Editorials done. 196 Redefinition of proxy to Registrar in Section 7. Explained better 197 the role of https-coaps Registrar, instead of "proxy" 199 Provide "observe" Option examples 201 extended block message example. 203 inserted new server key generation text in Section 5.8 and 204 motivated server key generation. 206 Broke down details for DTLS 1.3 208 New Media-Type uses CBOR array for multiple Content-Format 209 payloads 211 provided new Content-Format tables 213 new media format for IANA 215 -00 217 copied from vanderstok-ace-coap-04 219 2. Introduction 221 "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used 222 for authenticated/authorized endpoint certificate enrollment (and 223 optionally key provisioning) through a Certificate Authority (CA) or 224 Registration Authority (RA). EST transports messages over HTTPS. 226 This document defines a new transport for EST based on the 227 Constrained Application Protocol (CoAP) since some Internet of Things 228 (IoT) devices use CoAP instead of HTTP. Therefore, this 229 specification utilizes DTLS [RFC6347], CoAP [RFC7252] and UDP instead 230 of TLS [RFC8446], HTTP [RFC7230] and TCP. 232 EST responses can be relatively large and for this reason this 233 specification also uses CoAP Block-Wise Transfer [RFC7959] to offer a 234 fragmentation mechanism of EST messages at the CoAP layer. 236 This document also profiles the use of EST to only support 237 certificate-based client authentication. HTTP Basic or Digest 238 authentication (as described in Section 3.2.3 of [RFC7030] are not 239 supported. 241 3. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 245 "OPTIONAL" in this document are to be interpreted as described in BCP 246 14 [RFC2119] [RFC8174] when, and only when, they appear in all 247 capitals, as shown here. 249 Many of the concepts in this document are taken from [RFC7030]. 250 Consequently, much text is directly traceable to [RFC7030]. 252 4. Conformance to RFC7925 profiles 254 This section describes how EST-coaps fits into the profiles of low- 255 resource devices described in [RFC7925]. EST-coaps can transport 256 certificates and private keys. Certificates are responses to 257 (re-)enrollment requests or requests for a trusted certificate list. 258 Private keys can be transported as responses to a server-side key 259 generation request as described in section 4.4 of [RFC7030] and 260 discussed in Section 5.8 of this document. 262 As per Sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite 263 for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 264 [RFC7251]. Curve secp256r1 MUST be supported [RFC8422]; this curve 265 is equivalent to the NIST P-256 curve. Crypto agility is important, 266 and the recommendations in [RFC7925] section 4.4 and any updates to 267 RFC7925 concerning Curve25519 and other CFRG curves also apply. 269 DTLS1.2 implementations MUST use the Supported Elliptic Curves and 270 Supported Point Formats Extensions [RFC8422]. Uncompressed point 271 format MUST also be supported. [RFC6090] is a summary of the ECC 272 algorithms. DTLS 1.3 [I-D.ietf-tls-dtls13] implementations differ 273 from DTLS 1.2 because they do not support point format negotiation in 274 favor of a single point format for each curve. Thus, support for 275 DTLS 1.3 does not mandate point formation extensions and negotiation. 277 The authentication of the EST-coaps server by the EST-coaps client is 278 based on certificate authentication in the DTLS handshake. The EST- 279 coaps client MUST be configured with at least an Implicit TA database 280 from its manufacturer which will enable the authentication of the 281 server the first time before updating its trust anchor (Explicit TA) 282 [RFC7030]. 284 The authentication of the EST-coaps client MUST be with a client 285 certificate in the DTLS handshake. This can either be 286 o a previously issued client certificate (e.g., an existing 287 certificate issued by the EST CA); this could be a common case for 288 simple re-enrollment of clients. 290 o a previously installed certificate (e.g., manufacturer IDevID 291 [ieee802.1ar] or a certificate issued by some other party); the 292 server is expected to trust that certificate. IDevID's are 293 expected to have a very long life, as long as the device, but 294 under some conditions could expire. In that case, the server MAY 295 want to authenticate a client certificate against its trust store 296 although the certificate is expired (Section 11). 298 5. Protocol Design 300 EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise 301 Transfer [RFC7959] to avoid (excessive) fragmentation of UDP 302 datagrams. The use of Blocks for the transfer of larger EST messages 303 is specified in Section 5.6. Figure 1 below shows the layered EST- 304 coaps architecture. 306 +------------------------------------------------+ 307 | EST request/response messages | 308 +------------------------------------------------+ 309 | CoAP for message transfer and signaling | 310 +------------------------------------------------+ 311 | DTLS for transport security | 312 +------------------------------------------------+ 313 | UDP for transport | 314 +------------------------------------------------+ 316 Figure 1: EST-coaps protocol layers 318 The EST-coaps protocol design follows closely the EST design. The 319 supported message types in EST-coaps are: 321 o CA certificate retrieval, needed to receive the complete set of CA 322 certificates. 324 o Simple enroll and reenroll, for a CA to sign public client- 325 identity key. 327 o Certificate Signing Request (CSR) Attributes messages that informs 328 the client of the fields to include in generated CSR. 330 o Server-side key generation messages to provide a private client- 331 identity key when the client choses so. 333 5.1. Discovery and URIs 335 EST-coaps is targeted for low-resource networks with small packets. 336 Saving header space is important and short EST-coaps URIs are 337 specified in this document. These URIs are shorter than the ones in 338 [RFC7030]. Two example EST-coaps resource path names are: 340 coaps://est-coaps.example.ietf.org:/.well-known/est/ 341 coaps://est-coaps.example.ietf.org:/.well-known/est/ 342 ArbitraryLabel/ 344 The short-est strings are defined in Table 1. The ArbitraryLabel 345 path-segment, if used, SHOULD be of the shortest length possible 346 (Sections 3.1 and 3.2.2 of [RFC7030]. Arbitrary Labels are usually 347 defined and used by EST CAs in order to route client requests to the 348 appropriate certificate profile. 350 The EST-coaps server URIs, obtained through discovery of the EST- 351 coaps root resource(s) as shown below, are of the form: 353 coaps://est-coaps.example.ietf.org:// 354 coaps://est-coaps.example.ietf.org:// 355 ArbitraryLabel/ 357 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 358 corresponding paths which are supported by EST. Table 1 provides the 359 mapping from the EST URI path to the shorter EST-coaps URI path. 361 +------------------+-----------+ 362 | EST | EST-coaps | 363 +------------------+-----------+ 364 | /cacerts | /crts | 365 | /simpleenroll | /sen | 366 | /simplereenroll | /sren | 367 | /csrattrs | /att | 368 | /serverkeygen | /skg | 369 +------------------+-----------+ 371 Table 1: Table 1: Short EST-coaps URI path 373 Clients and servers MUST support the short resource URIs. The 374 corresponding longer URIs from [RFC7030] MAY be supported. 376 In the context of CoAP, the presence and location of (path to) the 377 management data are discovered by sending a GET request to "/.well- 378 known/core" including a resource type (RT) parameter with the value 379 "ace.est" [RFC6690]. Upon success, the return payload will contain 380 the root resource of the EST resources. The example below shows the 381 discovery of the presence and location of EST-coaps resources. 382 Linefeeds are included only for readability. 384 REQ: GET /.well-known/core?rt=ace.est* 386 RES: 2.05 Content 387 ; rt="ace.est", 388 ;rt="ace.est.crts";ct="281 TBD287", 389 ;rt="ace.est.sen";ct="281 TBD287", 390 ;rt="ace.est.sren";ct="281 TBD287", 391 ;rt="ace.est.att";ct=285, 392 ;rt="ace.est.skg";ct="62 280 284 281 TBD287" 394 The first line of the discovery response above MUST be included. The 395 five consecutive lines after the first MAY be included. The return 396 of the content types allows the client to choose the most appropriate 397 one. 399 Port numbers, not returned in the example, are assumed to be the 400 default numbers 5683 and 5684 for CoAP and CoAPS respectively 401 (Sections 12.6 and 12.7 of [RFC7252]). Discoverable port numbers MAY 402 be returned in the of the payload 403 [I-D.ietf-core-resource-directory]. An example response payload for 404 non-default CoAPS server port 61617 follows below. Linefeeds were 405 included only for readability. 407 REQ: GET /.well-known/core?rt=ace.est* 409 RES: 2.05 Content 410 ;rt="ace.est"; 411 anchor="coap://[2001:db8:3::123]:61617", 412 ;rt="ace.est.crts"; 413 ct="281 TBD287";anchor="coap://[2001:db8:3::123]:61617", 414 ;rt="ace.est.sen"; 415 ct="281 TBD287";anchor="coap://[2001:db8:3::123]:61617", 416 ;rt="ace.est.sren"; 417 ct="281 TBD287";anchor="coap://[2001:db8:3::123]:61617", 418 ;rt="ace.est.att"; 419 ct="285";anchor="coap://[2001:db8:3::123]:61617", 420 ;rt="ace.est.skg"; 421 ct="62 280 284 281 TBD287";anchor="coap://[2001:db8:3::123]:61617" 423 The server MUST support the default /.well-known/est server root 424 resource and port 5684. Resource discovery is necessary when the IP 425 address of the server is unknown to the client. Resource discovery 426 SHOULD be employed when non-default URIs (like /est or /est/ 427 ArbitraryLabel) or ports are supported by the server, when the client 428 is unaware of what EST-coaps resources are available or if the client 429 considers sending two Uri-Path Options to convey the resource is 430 wasteful. 432 It is up to the implementation to choose its root resource; 433 throughout this document the example root resource /est is used. 435 5.2. Mandatory/optional EST Functions 437 This specification contains a set of required-to-implement functions, 438 optional functions, and not specified functions. The latter ones are 439 deemed too expensive for low-resource devices in payload and 440 calculation times. 442 Table 2 specifies the mandatory-to-implement or optional 443 implementation of the est-coaps functions. 445 +------------------+--------------------------+ 446 | EST Functions | EST-coaps implementation | 447 +------------------+--------------------------+ 448 | /cacerts | MUST | 449 | /simpleenroll | MUST | 450 | /simplereenroll | MUST | 451 | /fullcmc | Not specified | 452 | /serverkeygen | OPTIONAL | 453 | /csrattrs | OPTIONAL | 454 +------------------+--------------------------+ 456 Table 2: Table 2: List of EST-coaps functions 458 While [RFC7030] permits a number of these functions to be used 459 without authentication, this specification requires that the client 460 MUST be authenticated for all functions. 462 5.3. Payload formats 464 The Content-Format (HTTP Media-Type equivalent) of the CoAP message 465 determines which EST message is transported in the CoAP payload. The 466 Media-Types specified in the HTTP Content-Type header (section 3.2.2 467 of [RFC7030]) are in EST-coaps specified by the Content-Format Option 468 (12) of CoAP. The combination of URI-Path and Content-Format in EST- 469 coaps MUST map to an allowed combination of URI and Media-Type in 470 EST. The required Content-Formats for these requests and response 471 messages are defined in Section 10.1. The CoAP response codes are 472 defined in Section 5.5. 474 Content-Format TBD287 can be used in place of 281 to carry a single 475 certificate instead of a PKCS#7 container in a /crts, /sen, /sren or 476 /skg response. Content-Format 281 MUST be supported by EST-coaps 477 servers. Servers MAY also support Content-Format TBD287. It is up 478 to the client to support only Content-Format 281, TBD287 or both. 479 The client is expected to use an COAP Accept Option in the request to 480 express the preferred response Content-Format. If an Accept Option 481 is not included in the request, the client is not expressing any 482 preference and the server SHOULD choose format 281. If the preferred 483 Content-Format cannot be returned, the server MUST send a 4.06 (Not 484 Acceptable) response, unless another error code takes precedence for 485 the response [RFC7252]. 487 Content-Format 286 is used in /sen, /sren and /skg requests and 285 488 in /att responses. 490 EST-coaps is designed for low-resource devices and hence does not 491 need to send Base64-encoded data. Simple binary is more efficient 492 (30% smaller payload) and well supported by CoAP. Thus, the payload 493 for a given Media-Type follows the ASN.1 structure of the Media-Type 494 and is transported in binary format. 496 *application/multipart-core* 498 A representation with Content-Format identifier 62 contains a 499 collection of representations along with their respective Content- 500 Format. The Content-Format identifies the Media-Type application/ 501 multipart-core specified in [I-D.ietf-core-multipart-ct]. 503 The collection is encoded as a CBOR array [RFC7049] with an even 504 number of elements. The second, fourth, sixth, etc. element is a 505 binary string containing a representation. The first, third, fifth, 506 etc. element is an unsigned integer specifying the Content-Format 507 identifier of the consecutive representation. For example, a 508 collection containing two representations in response to a EST-coaps 509 server-side key generation request, could include a private key in 510 PKCS#8 [RFC5958] with Content-Format identifier 284 (0x011C) and a 511 single certificate in a PKCS#7 container with Content-Format 512 identifier 281 (0x0119). Such a collection would look like 513 [284,h'0123456789abcdef', 281,h'fedcba9876543210'] in diagnostic CBOR 514 notation. The serialization of such CBOR content would be 515 84 # array(4) 516 19 011C # unsigned(284) 517 48 # bytes(8) 518 0123456789ABCDEF # "\x01#Eg\x89\xAB\xCD\xEF" 519 19 0119 # unsigned(281) 520 48 # bytes(8) 521 FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10" 523 Multipart /skg response serialization 525 When the returned certificate is a single X.509 certificate (not a 526 PKCS#7 container) the Content-Format identifier is TBD287 (0x011F) 527 instead of 281. In cases where the private key is encrypted with CMS 528 (as explained in Section 5.8) the Content-Format identifier is 280 529 (0x0118) instead of 284. The key and certificate representations are 530 ASN.1 encoded in binary format. An example is shown in Appendix A.3. 532 5.4. Message Bindings 534 The general EST-coaps message characteristics are: 536 o All EST-coaps messages expect a response from the server, thus the 537 client MUST send the requests over confirmable CON CoAP messages. 539 o The Ver, TKL, Token, and Message ID values of the CoAP header are 540 not affected by EST. 542 o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- 543 Format, Accept and Location-Path. These CoAP Options are used to 544 communicate the HTTP fields specified in the EST REST messages. 545 The Uri-Host and Uri-Port Options are optional. They are usually 546 omitted as the DTLS destination and port are sufficient. Explicit 547 Uri-Host and Uri-Port Options are typically used when an endpoint 548 hosts multiple virtual servers and uses the Options to route the 549 requests accordingly. Alternatively, if a UDP port to a server is 550 blocked, someone could send the DTLS packets to a known open port 551 on the server and use the Uri-Port to convey the intended port he 552 is attempting to reach. 554 o EST URLs are HTTPS based (https://), in CoAP these are assumed to 555 be translated to CoAPS (coaps://) 557 Table 1 provides the mapping from the EST URI path to the EST-coaps 558 URI path. Appendix A includes some practical examples of EST 559 messages translated to CoAP. 561 5.5. CoAP response codes 563 Section 5.9 of [RFC7252] and Section 7 of [RFC8075] specify the 564 mapping of HTTP response codes to CoAP response codes. Every time 565 the HTTP response code 200 is specified in [RFC7030] in response to a 566 GET request (/cacerts, /csrattrs), in EST-coaps the equivalent CoAP 567 response code 2.05 or 2.03 MUST be used. Similarly, 2.01, 2.02 or 568 2.04 MUST be used in response to EST POST requests (/simpleenroll, 569 /simplereenroll, /serverkeygen). 571 Response code HTTP 202 Retry-After that existed in EST has no 572 equivalent in CoAP. Retry-After is used in EST for delayed server 573 responses. Section 5.7 specifies how EST-coaps handles delayed 574 messages. 576 EST makes use of HTTP 204 and 404 responses when a resource is not 577 available for the client. The equivalent CoAP codes to use in an 578 EST-coaps responses are 2.04 and 4.04. Additionally, EST's HTTP 401 579 error translates to 4.01 in EST-coaps. Other EST HTTP error messages 580 are 400, 423 and 503. Their equivalent CoAP errors are 4.00, 4.03 581 and 5.03 respectively. In case a CoAP Option is unrecognized and 582 critical, the server is expected to return a 4.02 (Bad Option). 583 Moreover, if the Content-Format requested in the client Accept 584 Option, is not supported the server MUST return a 4.06 (Not 585 Acceptable), unless another error code takes precedence for the 586 response. 588 5.6. Message fragmentation 590 DTLS defines fragmentation only for the handshake and not for secure 591 data exchange (DTLS records). [RFC6347] states that to avoid using 592 IP fragmentation, which involves error-prone datagram reconstitution, 593 invokers of the DTLS record layer SHOULD size DTLS records so that 594 they fit within any Path MTU estimates obtained from the record 595 layer. In addition, invokers residing on a 6LoWPAN over IEEE 596 802.15.4 [ieee802.15.4] network SHOULD attempt to size CoAP messages 597 such that each DTLS record will fit within one or two IEEE 802.15.4 598 frames. 600 That is not always possible in EST-coaps. Even though ECC 601 certificates are small in size, they can vary greatly based on 602 signature algorithms, key sizes, and Object Identifier (OID) fields 603 used. For 256-bit curves, common ECDSA cert sizes are 500-1000 bytes 604 which could fluctuate further based on the algorithms, OIDs, Subject 605 Alternative Names (SAN) and cert fields. For 384-bit curves, ECDSA 606 certificates increase in size and can sometimes reach 1.5KB. 607 Additionally, there are times when the EST cacerts response from the 608 server can include multiple certificates that amount to large 609 payloads. Section 4.6 of CoAP [RFC7252] describes the possible 610 payload sizes: "if nothing is known about the size of the headers, 611 good upper bounds are 1152 bytes for the message size and 1024 bytes 612 for the payload size". Section 4.6 of [RFC7252] also suggests that 613 IPv4 implementations may want to limit themselves to more 614 conservative IPv4 datagram sizes such as 576 bytes. Even with ECC, 615 EST-coaps messages can still exceed MTU sizes on the Internet or 616 6LoWPAN [RFC4919] (Section 2 of [RFC7959]). EST-coaps needs to be 617 able to fragment messages into multiple DTLS datagrams. 619 To perform fragmentation in CoAP, [RFC7959] specifies the Block1 620 Option for fragmentation of the request payload and the Block2 Option 621 for fragmentation of the return payload of a CoAP flow. As explained 622 in Section 1 of [RFC7959], block-wise transfers should be used in 623 Confirmable CoAP messages to avoid the exacerbation of lost blocks. 624 The EST-coaps client and server MUST support Block2. Block1 MUST be 625 supported for EST-coaps enrollment requests that exceed the Path MTU. 627 [RFC7959] also defines Size1 and Size2 Options to provide size 628 information about the resource representation in a request and 629 response. EST-client and server MAY support Size1 and Size2 Options. 631 Examples of fragmented EST-coaps messages are shown in Appendix B. 633 5.7. Delayed Responses 635 Server responses can sometimes be delayed. According to section 636 5.2.2 of [RFC7252], a slow server can acknowledge the request and 637 respond later with the requested resource representation. In 638 particular, a slow server can respond to an EST-coaps enrollment 639 request with an empty ACK with code 0.00, before sending the 640 certificate to the server after a short delay. If the certificate 641 response is large, the server will need more than one Block2 blocks 642 to transfer it. This situation is shown in Figure 2. The client 643 sends an enrollment request that uses N1+1 Block1 blocks. The server 644 uses an empty 0.00 ACK to announce the delayed response which is 645 provided later with 2.04 messages containing N2+1 Block2 Options. 646 The first 2.04 is a confirmable message that is acknowledged by the 647 client with an ACK. Onwards, having received the first 256 bytes in 648 the first Block2 block, the client asks for a block reduction to 128 649 bytes in a confirmable enrollment request Uri-Path and acknowledges 650 the Block2 blocks sent up to that point. 652 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> 653 <-- (ACK) (1:0/1/256) (2.31 Continue) 654 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> 655 <-- (ACK) (1:1/1/256) (2.31 Continue) 656 . 657 . 658 . 659 POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> 660 <-- (0.00 empty ACK) 661 | 662 ...... short delay before certificate is ready ...... 663 | 664 <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp} 665 (ACK) --> 666 POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> 667 <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp} 668 . 669 . 670 . 671 POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> 672 <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp} 674 Figure 2: EST-COAP enrollment with short wait 676 If the server is very slow (i.e. minutes) in providing the response 677 (i.e. when a manual intervention is needed), the server SHOULD 678 respond with an ACK containing response code 5.03 (Service 679 unavailable) and a Max-Age Option to indicate the time the client 680 SHOULD wait to request the content later. After a delay of Max-Age, 681 the client SHOULD resend the identical CSR to the server. As long as 682 the server responds with response code 5.03 (Service Unavailable) 683 with a Max-Age Option, the client SHOULD keep resending the 684 enrollment request until the server responds with the certificate or 685 the client abandons for other reasons. 687 To demonstrate this scenario, Figure 3 shows a client sending an 688 enrollment request that uses N1+1 Block1 blocks to send the CSR to 689 the server. The server needs N2+1 Block2 blocks to respond, but also 690 needs to take a long delay (minutes) to provide the response. 691 Consequently, the server uses a 5.03 ACK response with a Max-Age 692 Option. The client waits for a period of Max-Age as many times as he 693 receives the same 5.03 response and retransmits the enrollment 694 request until he receives a certificate in a fragmented 2.01 695 response. Note that the server asks for a decrease in the block size 696 when acknowledging the first Block2. 698 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> 699 <-- (ACK) (1:0/1/256) (2.31 Continue) 700 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> 701 <-- (ACK) (1:1/1/256) (2.31 Continue) 702 . 703 . 704 POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> 705 <-- (ACK) (1:N1/0/256) (2:0/0/128)(5.03 Service Unavailable) 706 (Max-Age) 707 | 708 | 709 Client tries one or more times after Max-Age with identical payload 710 | 711 | 712 POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> 713 <-- (ACK) (1:N1/0/256) (2:0/1/128) (2.01 Created){Cert resp} 714 POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> 715 <-- (ACK) (2:1/1/128) (2.01 Created) {Cert resp} 716 . 717 . 718 . 719 POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> 720 <-- (ACK) (2:N2/0/128) (2.01 Created) {Cert resp} 722 Figure 3: EST-COAP enrollment with long wait 724 5.8. Server-side Key Generation 726 Constrained devices sometimes do not have the necessary hardware to 727 generate statistically random numbers for private keys and DTLS 728 ephemeral keys. Past experience has also shown that low-resource 729 endpoints sometimes generate numbers which could allow someone to 730 decrypt the communication or guess the private key and impersonate as 731 the device [PsQs] [RSAorig]. Additionally, random number key 732 generation is costly, thus energy draining. Even though the random 733 numbers that constitute the identity/cert do not get generated often, 734 an endpoint may not want to spend time and energy generating 735 keypairs, and just ask for one from the server. 737 In these scenarios, server-side key generation can be used. The 738 client asks for the server or proxy to generate the private key and 739 the certificate which are transferred back to the client in the 740 server-side key generation response. In all respects, the server 741 SHOULD treat the CSR as it would treat any enroll or re-enroll CSR; 742 the only distinction here is that the server MUST ignore the public 743 key values and signature in the CSR. These are included in the 744 request only to allow re-use of existing codebases for generating and 745 parsing such requests. 747 The client /skg request needs to communicate to the server the 748 Content-Format of the application/multipart-core elements. The key 749 Content-Format requested by the client is depicted in the PKCS#10 750 request. If the request contains SMIMECapabilities the client is 751 expecting Content-Format 280. Otherwise he expects a PKCS#8 key in 752 Content-Format 284. The client expresses the preferred certificate 753 Content-Format in his /skg request by using an Accept Option. The 754 Accept Option is 281 when preferring a certificate in a PKCS#7 755 container or TBD287 when preferring a single X.509 certificate. 757 [RFC7030] provides two methods, symmetric and asymmetric, to 758 optionally encrypt the generated key. The methods are signaled by 759 the client by using the relevant attributes (SMIMECapabilities and 760 DecryptKeyIdentifier or AsymmetricDecryptKeyIdentifier) in the CSR 761 request. The symmetric key or the asymmetric keypair establishment 762 method is out of scope of the specification. 764 The EST-coaps server-side key generation response is returned with 765 Content-Format application/multipart-core 766 [I-D.ietf-core-multipart-ct] containing a CBOR array with four items 767 Section 5.3. The certificate part exactly matches the response from 768 an enrollment response. The private key can be in unprotected PKCS#8 769 [RFC5958] format (Content-Format 284) or protected inside of CMS 770 SignedData (Content-Format 280). The SignedData is signed by the 771 party that generated the private key, which may be the EST server or 772 the EST CA. The SignedData is further protected by placing it inside 773 of a CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030]. 774 In summary, the symmetrically encrypted key is included in the 775 encryptedKey attribute in a KEKRecipientInfo structure. In the case 776 where the asymmetric encryption key is suitable for transport key 777 operations the generated private key is encrypted with a symmetric 778 key which is encrypted by the client defined (in the CSR) asymmetric 779 public key and is carried in an encryptedKey attribute in a 780 KeyTransRecipientInfo structure. Finally, if the asymmetric 781 encryption key is suitable for key agreement, the generated private 782 key is encrypted with a symmetric key which is encrypted by the 783 client defined (in the CSR) asymmetric public key and is carried in 784 an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. 786 [RFC7030] recommends the use of additional encryption of the returned 787 private key. For the context of this specification, clients and 788 servers that choose to support server-side key generation MUST 789 support unprotected (PKCS#8) private keys (Content-Format 284). 790 Symmetric or asymmetric encryption of the private key (CMS 791 EnvelopedData, Content-Format 280) SHOULD be supported for 792 deployments where end-to-end encryption needs to be provided between 793 the client and a server. Such cases could include architectures 794 where an entity between the client and the CA terminates the DTLS 795 connection (Registrar in Figure 4). 797 6. DTLS Transport Protocol 799 EST-coaps depends on a secure transport mechanism over UDP that 800 secures the exchanged CoAP messages. DTLS is one such secure 801 protocol. EST depended in TLS. No other changes are necessary 802 regarding the secure transport of EST messages. 804 CoAP was designed to avoid fragmentation. DTLS is used to secure 805 CoAP messages. However, fragmentation is still possible at the DTLS 806 layer during the DTLS handshake when using ECC ciphersuites. If 807 fragmentation is necessary, "DTLS provides a mechanism for 808 fragmenting a handshake message over several records, each of which 809 can be transmitted separately, thus avoiding IP fragmentation" 810 [RFC6347]. 812 The DTLS handshake is authenticated by using certificates. EST-coaps 813 supports the certificate types and Trust Anchors (TA) that are 814 specified for EST in Section 3 of [RFC7030]. 816 CoAP and DTLS can provide proof-of-identity for EST-coaps clients and 817 servers with simple PKI messages as described in Section 3.1 of 818 [RFC5272]. Moreover, channel-binding information for linking proof- 819 of-identity with connection-based proof-of-possession is OPTIONAL for 820 EST-coaps. When proof-of-possession is desired, a set of actions are 821 required regarding the use of tls-unique, described in section 3.5 in 822 [RFC7030]. The tls-unique information consists of the contents of 823 the first "Finished" message in the (D)TLS handshake between server 824 and client [RFC5929]. The client adds the "Finished" message as a 825 ChallengePassword in the attributes section of the PKCS#10 Request 826 [RFC5967] to prove that the client is indeed in control of the 827 private key at the time of the (D)TLS session establishment. 829 In the case of EST-coaps, the same operations can be performed during 830 the DTLS handshake. For DTLS 1.2, in the event of handshake message 831 fragmentation, the Hash of the handshake messages used in the MAC 832 calculation of the Finished message MUST be computed as if each 833 handshake message had been sent as a single fragment (Section 4.2.6 834 of [RFC6347]). The Finished message is calculated as shown in 835 Section 7.4.9 of [RFC5246]. Similarly, for DTLS 1.3, the Finished 836 message MUST be computed as if each handshake message had been sent 837 as a single fragment (Section 5.8 of [I-D.ietf-tls-dtls13]) following 838 the algorithm described in 4.4.4 of [RFC8446]. 840 In a constrained CoAP environment, endpoints can't always afford to 841 establish a DTLS connection for every EST transaction. 842 Authenticating and negotiating DTLS keys requires resources on low- 843 end endpoints and consumes valuable bandwidth. To alleviate this 844 situation, an EST-coaps DTLS connection MAY remain open for 845 sequential EST transactions. For example, an EST csrattrs request 846 that is followed by a simpleenroll request can use the same 847 authenticated DTLS connection. However, when a cacerts request is 848 included in the set of sequential EST transactions, some additional 849 security considerations apply regarding the use of the Implicit and 850 Explicit TA database as explained in Section 11.1. 852 Given that after a successful enrollment, it is more likely that a 853 new EST transaction will take place after a significant amount of 854 time, the DTLS connections SHOULD only be kept alive for EST messages 855 that are relatively close to each other. In some cases, like NAT 856 rebinding, keeping the state of a connection is not possible when 857 devices sleep for extended periods of time. In such occasions, 858 [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can 859 eliminate the need for new handshake and its additional cost. 861 7. HTTPS-CoAPS Registrar 863 In real-world deployments, the EST server will not always reside 864 within the CoAP boundary. The EST server can exist outside the 865 constrained network in which case it will support TLS/HTTP instead of 866 CoAPS. In such environments EST-coaps is used by the client within 867 the CoAP boundary and TLS is used to transport the EST messages 868 outside the CoAP boundary. A Registrar at the edge is required to 869 operate between the CoAP environment and the external HTTP network as 870 shown in Figure 4. 872 Constrained Network 873 .------. .----------------------------. 874 | CA | |.--------------------------.| 875 '------' || || 876 | || || 877 .------. HTTP .-----------------. CoAPS .-----------. || 878 | EST |<------->|EST-coaps-to-HTTPS|<------->| EST Client| || 879 |Server|over TLS | Registrar | '-----------' || 880 '------' '-----------------' || 881 || || 882 |'--------------------------'| 883 '----------------------------' 885 Figure 4: EST-coaps-to-HTTPS Registrar at the CoAP boundary. 887 The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream 888 and initiate EST connections over TLS upstream. The Registrar MUST 889 authenticate and OPTIONALLY authorize the clients and it MUST be 890 authenticated by the EST server or CA. The trust relationship 891 between the Registrar and the EST server SHOULD be pre-established 892 for the Registrar to proxy these connections on behalf of various 893 clients. 895 When enforcing Proof-of-Possession (POP) linking, the DTLS tls-unique 896 value of the (D)TLS session is used to prove that the private key 897 corresponding to the public key is in the possession of and was used 898 to establish the connection by the client as explained in Section 6). 899 The POP linking information is lost between the EST-coaps client and 900 the EST server when a Registrar is present. The EST server becomes 901 aware of the presence of a Registrar from its TLS client certificate 902 that includes id-kp-cmcRA [RFC6402] extended key usage extension 903 (EKU). As explained in Section 3.7 of [RFC7030], the EST server 904 SHOULD apply an authorization policy consistent with a Registrar 905 client. For example, it could be configured to accept POP linking 906 information that does not match the current TLS session because the 907 authenticated EST client Registrar has verified this information when 908 acting as an EST server. 910 For some use cases, clients that leverage server-side key generation 911 might prefer for the enrolled keys to be generated by the Registrar 912 if the CA does not support server-side key generation. In these 913 cases, the Registrar MUST support random number generation using 914 proper entropy. Such Registrar is responsible for generating a new 915 CSR signed by a new key which will be returned to the client along 916 with the certificate from the CA. 918 Table 1 contains the URI mappings between EST-coaps and EST that the 919 Registrar MUST adhere to. Section 5.5 of this specification and 920 Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP 921 response codes, that determine how the Registrar MUST translate CoAP 922 response codes from/to HTTP status codes. The mapping from CoAP 923 Content-Format to HTTP Media-Type is defined in Section 10.1. 924 Additionally, a conversion from CBOR major type 2 to Base64 encoding 925 MUST take place at the Registrar when server-side key generation is 926 supported. If CMS end-to-end encryption is employed for the private 927 key, the encrypted CMS EnvelopedData blob MUST be converted to binary 928 in CBOR type 2 downstream to the client. 930 Due to fragmentation of large messages into blocks, an EST-coaps-to- 931 HTTP Registrar MUST reassemble the BLOCKs before translating the 932 binary content to Base64, and consecutively relay the message 933 upstream. 935 For the discovery of the EST server by the EST client in the CoAP 936 environment, the EST-coaps-to-HTTP Registrar MUST announce itself 937 according to the rules in Section 5.1. The available actions of the 938 Registrars MUST be announced with as many resource paths necessary. 940 8. Parameters 942 This section addresses transmission parameters described in sections 943 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on 944 the CoAP parameters in [RFC7252], but the EST parameter values need 945 to be tuned to the CoAP parameter values. 947 It is RECOMMENDED, based on experiments, to follow the default CoAP 948 configuration parameters ([RFC7252]). However, depending on the 949 implementation scenario, retransmissions and timeouts can also occur 950 on other networking layers, governed by other configuration 951 parameters. A change in a server parameter MUST ensure the adjusted 952 value is also available to all the endpoints with which these 953 adjusted values are to be used to communicate. 955 Some further comments about some specific parameters, mainly from 956 Table 2 in [RFC7252]: 958 o NSTART: Limit the number of simultaneous outstanding interactions 959 that a client maintains to a given server. EST-coaps clients 960 SHOULD use 1, which is the default. A EST-coaps client is not 961 expected to interact with more than one servers at the same time. 963 o DEFAULT_LEISURE: This setting is only relevant in multicast 964 scenarios, outside the scope of EST-coaps. 966 o PROBING_RATE: A parameter which specifies the rate of re-sending 967 non-confirmable messages. The EST messages are defined to be sent 968 as CoAP confirmable messages, hence this setting is not 969 applicable. 971 Finally, the Table 3 parameters in [RFC7252] are mainly derived from 972 Table 2. Directly changing parameters on one table would affect 973 parameters on the other. 975 9. Deployment limitations 977 Although EST-coaps paves the way for the utilization of EST by 978 constrained devices in constrained networks, some classes of devices 979 [RFC7228] will not have enough resources to handle the large payloads 980 that come with EST-coaps. The specification of EST-coaps is intended 981 to ensure that EST works for networks of constrained devices that 982 choose to limit their communications stack to UDP/DTLS/CoAP. It is 983 up to the network designer to decide which devices execute the EST 984 protocol and which do not. 986 10. IANA Considerations 988 10.1. Content-Format Registry 990 Additions to the sub-registry "CoAP Content-Formats", within the 991 "CoRE Parameters" registry [COREparams] are specified in Table 3. 992 These have been registered provisionally in the Expert Review range 993 (0-255). 995 +------------------------------+-------+----------------------------+ 996 | HTTP Media-Type | ID | Reference | 997 +------------------------------+-------+----------------------------+ 998 | application/pkcs7-mime; | 280 | [RFC7030] [I-D.ietf-lamps- | 999 | smime-type=server-generated- | | rfc5751-bis] | 1000 | key | | | 1001 | application/pkcs7-mime; | 281 | [I-D.ietf-lamps-rfc5751-bi | 1002 | smime-type=certs-only | | s] | 1003 | application/pkcs7-mime; | 282 | [RFC5273] [I-D.ietf-lamps- | 1004 | smime-type=CMC-request | | rfc5751-bis] | 1005 | application/pkcs7-mime; | 283 | [RFC5273] [I-D.ietf-lamps- | 1006 | smime-type=CMC-response | | rfc5751-bis] | 1007 | application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- | 1008 | | | rfc5751-bis] | 1009 | application/csrattrs | 285 | [RFC7030] [RFC7231] | 1010 | application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- | 1011 | | | rfc5751-bis] | 1012 | application/pkix-cert | TBD28 | [RFC2585] | 1013 | | 7 | | 1014 +------------------------------+-------+----------------------------+ 1016 Table 3: Table 3: New CoAP Content-Formats 1018 The Content-Formats 281 to 286 have been the subject of an earlier 1019 temporary allocation. It is suggested that 287 is allocated to 1020 TBD287. 1022 10.2. Resource Type registry 1024 This memo registers a new Resource Type (rt=) Link Target Attributes 1025 in the "Resource Type (rt=) Link Target Attribute Values" subregistry 1026 under the "Constrained RESTful Environments (CoRE) Parameters" 1027 registry. 1029 o rt="ace.est". This EST resource is used to query and return the 1030 supported EST resources of a CoAP server. 1032 o rt="ace.est.crts". This resource depicts the support of EST get 1033 cacerts. 1035 o rt="ace.est.sen". This resource depicts the support of EST simple 1036 enroll. 1038 o rt="ace.est.sren". This resource depicts the support of EST 1039 simple reenroll. 1041 o rt="ace.est.att". This resource depicts the support of EST CSR 1042 attributes. 1044 o rt="ace.est.skg". This resource depicts the support of EST 1045 server-side key generation. 1047 11. Security Considerations 1049 11.1. EST server considerations 1051 The security considerations of Section 6 of [RFC7030] are only 1052 partially valid for the purposes of this document. As HTTP Basic 1053 Authentication is not supported, the considerations expressed for 1054 using passwords do not apply. 1056 Given that the client has only limited resources and may not be able 1057 to generate sufficiently random keys to encrypt its identity, it is 1058 possible that the client uses server generated private/public keys. 1059 The transport of these keys is inherently risky. Analysis SHOULD be 1060 done to establish whether server-side key generation enhances or 1061 decreases the probability of identity stealing. 1063 It is also RECOMMENDED that the Implicit Trust Anchor database used 1064 for EST server authentication is carefully managed to reduce the 1065 chance of a third-party CA with poor certification practices 1066 jeopardizing authentication. Disabling the Implicit Trust Anchor 1067 database after successfully receiving the Distribution of CA 1068 certificates response (Section 4.1.3 of [RFC7030]) limits any risk to 1069 the first DTLS exchange. Alternatively, in a case where a /sen 1070 request immediately follows a /crt, a client MAY choose to keep the 1071 connection authenticated by the Implicit TA open for efficiency 1072 reasons (Section 6). A client that pipelines EST-coaps /crt request 1073 with other requests in the same DTLS connection SHOULD revalidate the 1074 server certificate chain against the updated Explicit TA from the 1075 /crt response before proceeding with the subsequent requests. If the 1076 server certificate chain does not authenticate against the database, 1077 the client SHOULD close the connection without completing the rest of 1078 the requests. The updated Explicit TA MUST continue to be used in 1079 new DTLS connections. 1081 In cases where the IDevID used to authenticate the client is expired 1082 the server MAY still authenticate the client because IDevIDs are 1083 expected to live as long as the device itself (Section 4). In such 1084 occasions, checking the certificate revocation status or authorizing 1085 the client using another method is important for the server to ensure 1086 that the client is to be trusted. 1088 In accordance with [RFC7030], TLS cipher suites that include 1089 "_EXPORT_" and "_DES_" in their names MUST NOT be used. More 1090 information about recommendations of TLS and DTLS are included in 1091 [RFC7525]. 1093 As described in CMC, Section 6.7 of [RFC5272], "For keys that can be 1094 used as signature keys, signing the certification request with the 1095 private key serves as a POP on that key pair". The inclusion of tls- 1096 unique in the certificate request links the proof-of-possession to 1097 the TLS proof-of-identity. This implies but does not prove that only 1098 the authenticated client currently has access to the private key. 1100 What's more, POP linking uses tls-unique as it is defined in 1101 [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing 1102 a man-in-the-middle to leverage session resumption and renegotiation 1103 to inject himself between a client and server even when channel 1104 binding is in use. The attack was possible because of certain (D)TLS 1105 implementation imperfections. In the context of this specification, 1106 an attacker could invalidate the purpose of the POP linking 1107 ChallengePassword in the client request by resuming an EST-coaps 1108 connection. Even though the practical risk of such an attack to EST- 1109 coaps is not devastating, we would rather use a more secure channel 1110 binding mechanism. Such a mechanism could include an updated tls- 1111 unique value generation like the tls-unique-prf defined in 1112 [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS 1113 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such 1114 mechanism has not been standardized yet. Adopting in this document a 1115 channel binding value generated from an exporter would break 1116 backwards compatibility. Thus, in this specification we still depend 1117 in the tls-unique mechanism defined in [RFC5929], especially since 1118 the practicality of such an attack would not expose any messages 1119 exchanged with EST-coaps. 1121 Regarding the Certificate Signing Request (CSR), a CA is expected to 1122 be able to enforce policies to recover from improper CSR requests. 1124 Interpreters of ASN.1 structures should be aware of the use of 1125 invalid ASN.1 length fields and should take appropriate measures to 1126 guard against buffer overflows, stack overruns in particular, and 1127 malicious content in general. 1129 11.2. HTTPS-CoAPS Registrar considerations 1131 The Registrar proposed in Section 7 must be deployed with care, and 1132 only when the recommended connections are impossible. When POP 1133 linking is used the Registrar terminating the TLS connection 1134 establishes a new one with the upstream CA. Thus, it is impossible 1135 for POP linking to be enforced end-to-end for the EST transaction. 1136 The EST server could be configured to accept POP linking information 1137 that does not match the current TLS session because the authenticated 1138 EST Registrar client has verified this information when acting as an 1139 EST server. 1141 The introduction of an EST-coaps-to-HTTP Registrar assumes the client 1142 can trust the registrar using its implicit or explicit TA database. 1143 It also assumes the Registrar has a trust relationship with the 1144 upstream EST server in order to act on behalf of the clients. When a 1145 client uses the Implicit TA database for certificate validation, he 1146 SHOULD confirm if the server is acting as an RA by the presence of 1147 the id-kp-cmcRA [RFC6402] EKU in the server certificate. If the 1148 server certificate does not include the EKU, it is RECOMMENDED that 1149 the client includes "Linking Identity and POP Information" 1150 (Section 6) in requests. 1152 In a server-side key generation case, if no end-to-end encryption is 1153 used, the Registrar may be able see the private key as it acts as a 1154 man-in-the-middle. Thus, the client puts its trust on the Registrar 1155 not exposing the private key. 1157 Clients that leverage server-side key generation without end-to-end 1158 encryption of the private key (Section 5.8) have no knowledge if the 1159 Registrar will be generating the private key and enrolling the 1160 certificates with the CA or if the CA will be responsible for 1161 generating the key. In such cases, the existence of a Registrar 1162 requires the client to put its trust on the registrar doing the right 1163 thing if it is generating the private key. 1165 12. Contributors 1167 Martin Furuhed contributed to the EST-coaps specification by 1168 providing feedback based on the Nexus EST over CoAPS server 1169 implementation that started in 2015. Sandeep Kumar kick-started this 1170 specification and was instrumental in drawing attention to the 1171 importance of the subject. 1173 13. Acknowledgements 1175 The authors are very grateful to Klaus Hartke for his detailed 1176 explanations on the use of Block with DTLS and his support for the 1177 Content-Format specification. The authors would like to thank Esko 1178 Dijk and Michael Verschoor for the valuable discussions that helped 1179 in shaping the solution. They would also like to thank Peter 1180 Panburana for his feedback on technical details of the solution. 1181 Constructive comments were received from Benjamin Kaduk, Eliot Lear, 1182 Jim Schaad, Hannes Tschofenig, Julien Vermillard, John Manuel, Oliver 1183 Pfaff and Pete Beal. 1185 Interop tests were done by Oliver Pfaff, Thomas Werner, Oskar 1186 Camezind, Bjorn Elmers and Joel Hoglund. 1188 Robert Moskowitz provided code to create the examples. 1190 14. References 1192 14.1. Normative References 1194 [I-D.ietf-core-multipart-ct] 1195 Fossati, T., Hartke, K., and C. Bormann, "Multipart 1196 Content-Format for CoAP", draft-ietf-core-multipart-ct-02 1197 (work in progress), August 2018. 1199 [I-D.ietf-tls-dtls13] 1200 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1201 Datagram Transport Layer Security (DTLS) Protocol Version 1202 1.3", draft-ietf-tls-dtls13-30 (work in progress), 1203 November 2018. 1205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1206 Requirement Levels", BCP 14, RFC 2119, 1207 DOI 10.17487/RFC2119, March 1997, 1208 . 1210 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1211 Infrastructure Operational Protocols: FTP and HTTP", 1212 RFC 2585, DOI 10.17487/RFC2585, May 1999, 1213 . 1215 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1216 (TLS) Protocol Version 1.2", RFC 5246, 1217 DOI 10.17487/RFC5246, August 2008, 1218 . 1220 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1221 DOI 10.17487/RFC5967, August 2010, 1222 . 1224 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1225 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1226 January 2012, . 1228 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1229 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1230 . 1232 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1233 "Enrollment over Secure Transport", RFC 7030, 1234 DOI 10.17487/RFC7030, October 2013, 1235 . 1237 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1238 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1239 October 2013, . 1241 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1242 Application Protocol (CoAP)", RFC 7252, 1243 DOI 10.17487/RFC7252, June 2014, 1244 . 1246 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1247 the Constrained Application Protocol (CoAP)", RFC 7959, 1248 DOI 10.17487/RFC7959, August 2016, 1249 . 1251 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1252 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1253 the Constrained Application Protocol (CoAP)", RFC 8075, 1254 DOI 10.17487/RFC8075, February 2017, 1255 . 1257 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1258 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1259 May 2017, . 1261 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1262 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1263 . 1265 14.2. Informative References 1267 [COREparams] 1268 IANA, "Constrained RESTful Environments (CoRE) 1269 Parameters", . 1272 [I-D.ietf-core-resource-directory] 1273 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1274 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1275 resource-directory-19 (work in progress), January 2019. 1277 [I-D.ietf-lamps-rfc5751-bis] 1278 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1279 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1280 Message Specification", draft-ietf-lamps-rfc5751-bis-12 1281 (work in progress), September 2018. 1283 [I-D.ietf-tls-dtls-connection-id] 1284 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1285 "Connection Identifiers for DTLS 1.2", draft-ietf-tls- 1286 dtls-connection-id-02 (work in progress), October 2018. 1288 [I-D.josefsson-sasl-tls-cb] 1289 Josefsson, S., "Channel Bindings for TLS based on the 1290 PRF", draft-josefsson-sasl-tls-cb-03 (work in progress), 1291 March 2015. 1293 [I-D.moskowitz-ecdsa-pki] 1294 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 1295 "Guide for building an ECC pki", draft-moskowitz-ecdsa- 1296 pki-04 (work in progress), September 2018. 1298 [ieee802.15.4] 1299 Institute of Electrical and Electronics Engineers, "IEEE 1300 Standard 802.15.4-2006", 2006. 1302 [ieee802.1ar] 1303 Institute of Electrical and Electronics Engineers, "IEEE 1304 802.1AR Secure Device Identifier", December 2009. 1306 [PsQs] Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex 1307 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1308 Weak Keys in Network Devices", USENIX Security Symposium 1309 2012 ISBN 978-931971-95-9, August 2012. 1311 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1312 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1313 Overview, Assumptions, Problem Statement, and Goals", 1314 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1315 . 1317 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1318 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1319 . 1321 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 1322 (CMC): Transport Protocols", RFC 5273, 1323 DOI 10.17487/RFC5273, June 2008, 1324 . 1326 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1327 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1328 March 2010, . 1330 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1331 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 1332 . 1334 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1335 DOI 10.17487/RFC5958, August 2010, 1336 . 1338 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1339 Curve Cryptography Algorithms", RFC 6090, 1340 DOI 10.17487/RFC6090, February 2011, 1341 . 1343 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1344 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1345 . 1347 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1348 Constrained-Node Networks", RFC 7228, 1349 DOI 10.17487/RFC7228, May 2014, 1350 . 1352 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1353 Protocol (HTTP/1.1): Message Syntax and Routing", 1354 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1355 . 1357 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1358 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1359 DOI 10.17487/RFC7231, June 2014, 1360 . 1362 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1363 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1364 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 1365 . 1367 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1368 "Recommendations for Secure Use of Transport Layer 1369 Security (TLS) and Datagram Transport Layer Security 1370 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1371 2015, . 1373 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1374 Security (TLS) / Datagram Transport Layer Security (DTLS) 1375 Profiles for the Internet of Things", RFC 7925, 1376 DOI 10.17487/RFC7925, July 2016, 1377 . 1379 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1380 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1381 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1382 DOI 10.17487/RFC8422, August 2018, 1383 . 1385 [RSAorig] Petr Svenda, Matus Nemec, Peter Sekan, Rudolf Kvasnovsky, 1386 David Formanek, David Komarek, Vashek Matyas, "The 1387 Million-Key Question - Investigating the Origins of RSA 1388 Public Keys", USENIX Security Symposium 2016 ISBN 1389 978-1-931971-32-4, August 2016. 1391 [tripleshake] 1392 Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cedric 1393 Fournet, Alfredo Pironti, Pierre-Yves Strub, "Triple 1394 Handshakes and Cookie Cutters: Breaking and Fixing 1395 Authentication over TLS", IEEE Security and Privacy ISBN 1396 978-1-4799-4686-0, May 2014. 1398 Appendix A. EST messages to EST-coaps 1400 This section shows similar examples to the ones presented in 1401 Appendix A of [RFC7030]. The payloads in the examples are the hex 1402 encoded binary, generated with 'xxd -p', of the PKI certificates 1403 created following [I-D.moskowitz-ecdsa-pki]. The payloads are shown 1404 unencrypted. In practice the message content would be binary 1405 formatted and transferred over an encrypted DTLS tunnel. The 1406 hexadecimal representations in the examples below would NOT be 1407 transported in hex, but in binary. Hex is used for visualization 1408 purposes because a binary representation cannot be rendered well in 1409 text. 1411 The certificate responses included in the examples contain Content- 1412 Format 281 (application/pkcs7). If the client had requested Content- 1413 Format TBD287 (application/pkix-cert) with an Accept Option, the 1414 server would respond a single DER binary certificate. 1416 These examples assume that the resource discovery, returned a short 1417 base path of "/est". 1419 The corresponding CoAP headers are only shown in Appendix A.1. 1420 Creating CoAP headers is assumed to be generally understood. 1422 The message content breakdown is presented in Appendix C. 1424 A.1. cacerts 1426 In EST-coaps, a cacerts message can be: 1428 GET coaps://est-coaps.example.ietf.org:9085/est/crts 1429 (Accept: 281) 1431 The corresponding CoAP header fields are shown below. The use of 1432 block and DTLS are worked out in Appendix B. 1434 Ver = 1 1435 T = 0 (CON) 1436 Code = 0x01 (0.01 is GET) 1437 Token = 0x9a (client generated) 1438 Options 1439 Option (Uri-Host) [optional] 1440 Option Delta = 0x3 (option# 3) 1441 Option Length = 0x9 1442 Option Value = est-coaps.example.ietf.org 1443 Option (Uri-Port) [optional] 1444 Option Delta = 0x4 (option# 3+4=7) 1445 Option Length = 0x4 1446 Option Value = 9085 1447 Option (Uri-Path) 1448 Option Delta = 0x4 (option# 7+4=11) 1449 Option Length = 0x5 1450 Option Value = "est" 1451 Option (Uri-Path) 1452 Option Delta = 0x0 (option# 11+0=11) 1453 Option Length = 0x6 1454 Option Value = "crts" 1455 Option (Accept) 1456 Option Delta = 0x6 (option# 11+6=17) 1457 Option Length = 0x2 1458 Option Value = 281 1459 Payload = [Empty] 1461 The Uri-Host and Uri-Port Options are optional. They are usually 1462 omitted as the DTLS destination and port are sufficient. Explicit 1463 Uri-Host and Uri-Port Options are typically used when an endpoint 1464 hosts multiple virtual servers and uses the Options to route the 1465 requests accordingly. Alternatively, if a UDP port to a server is 1466 blocked, someone could send the DTLS packets to a known open port on 1467 the server and use the Uri-Port to convey the intended port he is 1468 attempting to reach. 1470 A 2.05 Content response with a cert in EST-coaps will then be 1472 2.05 Content (Content-Format: 281) 1473 {payload with certificate in binary format} 1475 with CoAP fields 1476 Ver = 1 1477 T = 2 (ACK) 1478 Code = 0x45 (2.05 Content) 1479 Token = 0x9a (copied from request by server) 1480 Options 1481 Option (Content-Format) 1482 Option Delta = 0xC (option# 12) 1483 Option Length = 0x2 1484 Option Value = 281 1486 [ The hexadecimal representation below would NOT be transported 1487 in hex, but in binary. Hex is used because a binary representation 1488 cannot be rendered well in text. ] 1490 Payload = 1491 3082027b06092a864886f70d010702a082026c308202680201013100300b 1492 06092a864886f70d010701a082024e3082024a308201f0a0030201020209 1493 009189bcdf9c99244b300a06082a8648ce3d0403023067310b3009060355 1494 040613025553310b300906035504080c024341310b300906035504070c02 1495 4c4131143012060355040a0c0b4578616d706c6520496e63311630140603 1496 55040b0c0d63657274696669636174696f6e3110300e06035504030c0752 1497 6f6f74204341301e170d3139303130373130343034315a170d3339303130 1498 323130343034315a3067310b3009060355040613025553310b3009060355 1499 04080c024341310b300906035504070c024c4131143012060355040a0c0b 1500 4578616d706c6520496e6331163014060355040b0c0d6365727469666963 1501 6174696f6e3110300e06035504030c07526f6f742043413059301306072a 1502 8648ce3d020106082a8648ce3d03010703420004814994082b6e8185f3df 1503 53f5e0bee698973335200023ddf78cd17a443ffd8ddd40908769c55652ac 1504 2ccb75c4a50a7c7ddb7c22dae6c85cca538209fdbbf104c9a38184308181 1505 301d0603551d0e041604142495e816ef6ffcaaf356ce4adffe33cf492abb 1506 a8301f0603551d230418301680142495e816ef6ffcaaf356ce4adffe33cf 1507 492abba8300f0603551d130101ff040530030101ff300e0603551d0f0101 1508 ff040403020106301e0603551d1104173015811363657274696679406578 1509 616d706c652e636f6d300a06082a8648ce3d0403020348003045022100da 1510 e37c96f154c32ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f135327 1511 2f022047a28ae5c7306163b3c3834bab3c103f743070594c089aaa0ac870 1512 cd13b902caa1003100 1514 The breakdown of the payload is shown in Appendix C.1. 1516 A.2. enroll / reenroll 1518 During the (re-)enroll exchange the EST-coaps client uses a CSR 1519 (Content-Format 286) request in the POST request payload. The Accept 1520 option tells the server that the client is expecting Content-Format 1521 281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR 1522 contains a ChallengePassword which is used for POP linking 1523 (Section 6). 1525 POST [2001:db8::2:1]:61616/est/sen 1526 (Token: 0x45) 1527 (Accept: 281) 1528 (Content-Format: 286) 1530 [ The hexadecimal representation below would NOT be transported 1531 in hex, but in binary. Hex is used because a binary representation 1532 cannot be rendered well in text. ] 1534 3082018b30820131020100305c310b3009060355040613025553310b3009 1535 06035504080c024341310b300906035504070c024c413114301206035504 1536 0a0c0b6578616d706c6520496e63310c300a060355040b0c03496f54310f 1537 300d060355040513065774313233343059301306072a8648ce3d02010608 1538 2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f 1539 028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75 1540 f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109 1541 0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e 1542 7634332323403d204e787e60303b06092a864886f70d01090e312e302c30 1543 2a0603551d1104233021a01f06082b06010505070804a013301106092b06 1544 010401b43b0a01040401020304300a06082a8648ce3d0403020348003045 1545 02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab 1546 ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc 1547 1135a1e84eed754377 1549 After verification of the CSR by the server, a 2.01 Content response 1550 with the issued certificate will be returned to the client. 1552 2.01 Created 1553 (Token: 0x45) 1554 (Content-Format: 281) 1556 [ The hexadecimal representation below would NOT be transported 1557 in hex, but in binary. Hex is used because a binary representation 1558 cannot be rendered well in text. ] 1560 3082026e06092a864886f70d010702a082025f3082025b0201013100300b 1561 06092a864886f70d010701a08202413082023d308201e2a0030201020208 1562 7e7661d7b54e4632300a06082a8648ce3d040302305d310b300906035504 1563 0613025553310b300906035504080c02434131143012060355040a0c0b45 1564 78616d706c6520496e6331163014060355040b0c0d636572746966696361 1565 74696f6e3113301106035504030c0a3830322e3141522043413020170d31 1566 39303133313131323931365a180f39393939313233313233353935395a30 1567 5c310b3009060355040613025553310b300906035504080c024341310b30 1568 0906035504070c024c4131143012060355040a0c0b6578616d706c652049 1569 6e63310c300a060355040b0c03496f54310f300d06035504051306577431 1570 3233343059301306072a8648ce3d020106082a8648ce3d03010703420004 1571 c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50c 1572 ff958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b56 1573 38e59fd9a3818a30818730090603551d1304023000301d0603551d0e0416 1574 041496600d8716bf7fd0e752d0ac760777ad665d02a0301f0603551d2304 1575 183016801468d16551f951bfc82a431d0d9f08bc2d205b1160300e060355 1576 1d0f0101ff0404030205a0302a0603551d1104233021a01f06082b060105 1577 05070804a013301106092b06010401b43b0a01040401020304300a06082a 1578 8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94 1579 91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d 1580 832a4d336a08ad67df20f1506421188a0ade6d349236a1003100 1582 The breakdown of the request and response is shown in Appendix C.2. 1584 As described in Section 5.7, if the server is not able to provide a 1585 response immediately, it sends an empty ACK with response code 5.03 1586 (Service Unavailable) and the Max-Age Option. See Figure 3 for an 1587 example exchange. 1589 A.3. serverkeygen 1591 In a serverkeygen exchange the CoAP POST request looks like 1592 POST coaps://192.0.2.1:8085/est/skg 1593 (Token: 0xa5) 1594 (Accept: 281) 1595 (Content-Format: 286) 1597 [ The hexadecimal representation below would NOT be transported 1598 in hex, but in binary. Hex is used because a binary representation 1599 cannot be rendered well in text. ] 1601 3081cf3078020100301631143012060355040a0c0b736b67206578616d70 1602 6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b 1603 b8c1117896f98e4506c03d70efbe820d8e38ea97e9d65d52c8460c5852c5 1604 1dd89a61370a2843760fc859799d78cd33f3c1846e304f1717f8123f1a28 1605 4cc99fa000300a06082a8648ce3d04030203470030440220387cd4e9cf62 1606 8d4af77f92ebed4890d9d141dca86cd2757dd14cbd59cdf6961802202f24 1607 5e828c77754378b66660a4977f113cacdaa0cc7bad7d1474a7fd155d090d 1609 The response would follow [I-D.ietf-core-multipart-ct] and could look 1610 like 1611 2.01 Content 1612 (Token: 0xa5) 1613 (Content-Format: 62) 1615 [ The hexadecimal representations below would NOT be transported 1616 in hex, but in binary. Hex is used because a binary representation 1617 cannot be rendered well in text. ] 1619 84 # array(4) 1620 19 011C # unsigned(284) 1621 58 8A # bytes(138) 1622 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 1623 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 1624 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 1625 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 1626 cd33f3c1846e304f1717f8123f1a284cc99f 1627 19 0119 # unsigned(281) 1628 59 01D3 # bytes(467) 1629 308201cf06092a864886f70d010702a08201c0308201bc0201013100300b 1630 06092a864886f70d010701a08201a23082019e30820143a0030201020208 1631 126de8571518524b300a06082a8648ce3d04030230163114301206035504 1632 0a0c0b736b67206578616d706c65301e170d313930313039303835373038 1633 5a170d3339303130343038353730385a301631143012060355040a0c0b73 1634 6b67206578616d706c653059301306072a8648ce3d020106082a8648ce3d 1635 030107034200041bb8c1117896f98e4506c03d70efbe820d8e38ea97e9d6 1636 5d52c8460c5852c51dd89a61370a2843760fc859799d78cd33f3c1846e30 1637 4f1717f8123f1a284cc99fa37b307930090603551d1304023000302c0609 1638 6086480186f842010d041f161d4f70656e53534c2047656e657261746564 1639 204365727469666963617465301d0603551d0e04160414494be598dc8dbc 1640 0dbc071c486b777460e5cce621301f0603551d23041830168014494be598 1641 dc8dbc0dbc071c486b777460e5cce621300a06082a8648ce3d0403020349 1642 003046022100a4b167d0f9add9202810e6bf6a290b8cfdfc9b9c9fea2cc1 1643 c8fc3a464f79f2c202210081d31ba142751a7b4a34fd1a01fcfb08716b9e 1644 b53bdaadc9ae60b08f52429c0fa1003100 1646 The private key in the response above is without CMS EnvelopedData 1647 and has no additional encryption beyond DTLS (Section 5.8). 1649 The breakdown of the request and response is shown in Appendix C.3 1651 A.4. csrattrs 1653 Below is a csrattrs exchange 1654 REQ: 1655 GET coaps://[2001:db8::2:1]:61616/est/att 1657 RES: 1658 2.05 Content 1659 (Content-Format: 285) 1661 [ The hexadecimal representation below would NOT be transported 1662 in hex, but in binary. Hex is used because a binary representation 1663 cannot be rendered well in text. ] 1665 307c06072b06010101011630220603883701311b131950617273652053455 1666 420617320322e3939392e31206461746106092a864886f70d010907302c06 1667 0388370231250603883703060388370413195061727365205345542061732 1668 0322e3939392e32206461746106092b240303020801010b06096086480165 1669 03040202 1671 A 2.05 Content response should contain attributes which are relevant 1672 for the authenticated client. This example is copied from section 1673 A.2 in [RFC7030], where the base64 representation is replaced with a 1674 hexadecimal representation of the equivalent binary format. The EST- 1675 coaps server returns attributes that the client can ignore if they 1676 are unknown to him. 1678 Appendix B. EST-coaps Block message examples 1680 Two examples are presented in this section: 1682 1. a cacerts exchange shows the use of Block2 and the block headers 1684 2. an enroll exchange shows the Block1 and Block2 size negotiation 1685 for request and response payloads. 1687 The payloads are shown unencrypted. In practice the message contents 1688 would be binary formatted and transferred over an encrypted DTLS 1689 tunnel. The corresponding CoAP headers are only shown in 1690 Appendix B.1. Creating CoAP headers are assumed to be generally 1691 known. 1693 B.1. cacerts 1695 This section provides a detailed example of the messages using DTLS 1696 and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is 1697 the example value assumed for the DTLS datagram size. The example 1698 block length is taken as 64 which gives an SZX value of 2. 1700 The following is an example of a cacerts exchange over DTLS. The 1701 content length of the cacerts response in appendix A.1 of [RFC7030] 1702 contains 639 bytes in binary. The CoAP message adds around 10 bytes, 1703 the DTLS record 29 bytes. To avoid IP fragmentation, the CoAP Block 1704 Option is used and an MTU of 127 is assumed to stay within one IEEE 1705 802.15.4 packet. To stay below the MTU of 127, the payload is split 1706 in 9 packets with a payload of 64 bytes each, followed by a last 1707 tenth packet of 63 bytes. The client sends an IPv6 packet containing 1708 the UDP datagram with the DTLS record that encapsulates the CoAP 1709 request 10 times. The server returns an IPv6 packet containing the 1710 UDP datagram with the DTLS record that encapsulates the CoAP 1711 response. The CoAP request-response exchange with block option is 1712 shown below. Block Option is shown in a decomposed way (block- 1713 option:NUM/M/size) indicating the kind of Block Option (2 in this 1714 case) followed by a colon, and then the block number (NUM), the more 1715 bit (M = 0 in Block2 response means it is last block), and block size 1716 with exponent (2**(SZX+4)) separated by slashes. The Length 64 is 1717 used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent 1718 confirmable (CON) and the Content-Format of the response, even though 1719 not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). 1720 The transfer of the 10 blocks with partially filled block NUM=9 is 1721 shown below 1723 GET coaps://est-coaps.example.ietf.org:9085/est/crts (2:0/0/64) --> 1724 <-- (2:0/1/64) 2.05 Content 1725 GET coaps://est-coaps.example.ietf.org:9085/est/crts (2:1/0/64) --> 1726 <-- (2:1/1/64) 2.05 Content 1727 | 1728 | 1729 | 1730 GET coaps://est-coaps.example.ietf.org:9085/est/crts (2:9/0/64) --> 1731 <-- (2:9/0/64) 2.05 Content 1733 The header of the GET request looks like 1734 Ver = 1 1735 T = 0 (CON) 1736 Code = 0x01 (0.1 GET) 1737 Token = 0x9a (client generated) 1738 Options 1739 Option (Uri-Host) [optional] 1740 Option Delta = 0x3 (option# 3) 1741 Option Length = 0x9 1742 Option Value = est-coaps.example.ietf.org 1743 Option (Uri-Port) [optional] 1744 Option Delta = 0x4 (option# 3+4=7) 1745 Option Length = 0x4 1746 Option Value = 9085 1747 Option (Uri-Path) 1748 Option Delta = 0x4 (option# 7+4=11) 1749 Option Length = 0x5 1750 Option Value = "est" 1751 Option (Uri-Path)Uri-Path) 1752 Option Delta = 0x0 (option# 11+0=11) 1753 Option Length = 0x6 1754 Option Value = "crts" 1755 Option (Accept) 1756 Option Delta = 0x6 (option# 11+6=17) 1757 Option Length = 0x2 1758 Option Value = 281 1759 Payload = [Empty] 1761 The Uri-Host and Uri-Port Options are optional. They are usually 1762 omitted as the DTLS destination and port are sufficient. Explicit 1763 Uri-Host and Uri-Port Options are typically used when an endpoint 1764 hosts multiple virtual servers and uses the Options to route the 1765 requests accordingly. Alternatively, if a UDP port to a server is 1766 blocked, someone could send the DTLS packets to a known open port on 1767 the server and use the Uri-Port to convey the intended port he is 1768 attempting to reach. 1770 For further detailing the CoAP headers, the first two and the last 1771 blocks are written out below. The header of the first Block2 1772 response looks like 1773 Ver = 1 1774 T = 2 (ACK) 1775 Code = 0x45 (2.05 Content) 1776 Token = 0x9a (copied from request by server) 1777 Options 1778 Option 1779 Option Delta = 0xC (option# 12 Content-Format) 1780 Option Length = 0x2 1781 Option Value = 281 1782 Option 1783 Option Delta = 0xB (option# 12+11=23 Block2) 1784 Option Length = 0x1 1785 Option Value = 0x0A (block#=0, M=1, SZX=2) 1787 [ The hexadecimal representation below would NOT be transported 1788 in hex, but in binary. Hex is used because a binary representation 1789 cannot be rendered well in text. ] 1791 Payload = 1792 3082027b06092a864886f70d010702a082026c308202680201013100300b 1793 06092a864886f70d010701a082024e3082024a308201f0a0030201020209 1794 009189bc 1796 The second Block2: 1798 Ver = 1 1799 T = 2 (means ACK) 1800 Code = 0x45 (2.05 Content) 1801 Token = 0x9a (copied from request by server) 1802 Options 1803 Option 1804 Option Delta = 0xC (option# 12 Content-Format) 1805 Option Length = 0x2 1806 Option Value = 281 1807 Option 1808 Option Delta = 0xB (option 12+11=23 Block2) 1809 Option Length = 0x1 1810 Option Value = 0x1A (block#=1, M=1, SZX=2) 1812 [ The hexadecimal representation below would NOT be transported 1813 in hex, but in binary. Hex is used because a binary representation 1814 cannot be rendered well in text. ] 1816 Payload = 1817 df9c99244b300a06082a8648ce3d0403023067310b300906035504061302 1818 5553310b300906035504080c024341310b300906035504070c024c413114 1819 30120603 1820 The 10th and final Block2: 1822 Ver = 1 1823 T = 2 (means ACK) 1824 Code = 0x45 (2.05 Content) 1825 Token = 0x9a (copied from request by server) 1826 Options 1827 Option 1828 Option Delta = 0xC (option# 12 Content-Format) 1829 Option Length = 0x2 1830 Option Value = 281 1831 Option 1832 Option Delta = 0xB (option# 12+11=23 Block2 ) 1833 Option Length = 0x2 1834 Option Value = 0x92 (block#=9, M=0, SZX=2) 1836 [ The hexadecimal representation below would NOT be transported 1837 in hex, but in binary. Hex is used because a binary representation 1838 cannot be rendered well in text. ] 1840 Payload = 1841 2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a 1842 e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1 1843 003100 1845 B.2. enroll / reenroll 1847 In this example the requested Block2 size of 256 bytes, required by 1848 the client, is transferred to the server in the very first request 1849 message. The block size 256=(2**(SZX+4)) which gives SZX=4. The 1850 notation for block numbering is the same as in Appendix B.1. It is 1851 assumed that CSR takes N1+1 blocks and the cert response takes N2+1 1852 blocks. The header fields and the payload are omitted for brevity. 1854 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> 1855 <-- (ACK) (1:0/1/256) (2.31 Continue) 1856 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> 1857 <-- (ACK) (1:1/1/256) (2.31 Continue) 1858 . 1859 . 1860 . 1861 POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> 1862 <-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp} 1863 POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> 1864 <-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp} 1865 . 1866 . 1867 . 1868 POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> 1869 <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp} 1871 Figure 5: EST-COAP enrollment with multiple blocks 1873 N1+1 blocks have been transferred from client to the server and N2+1 1874 blocks have been transferred from server to client. 1876 Appendix C. Message content breakdown 1878 This appendix presents the breakdown of the hexadecimal dumps of the 1879 binary payloads shown in Appendix A. 1881 C.1. cacerts 1883 Breakdown of cacerts response containing one root CA certificate. 1885 Certificate: 1886 Data: 1887 Version: 3 (0x2) 1888 Serial Number: 1889 91:89:bc:df:9c:99:24:4b 1890 Signature Algorithm: ecdsa-with-SHA256 1891 Issuer: C=US, ST=CA, L=LA, O=Example Inc, 1892 OU=certification, CN=Root CA 1893 Validity 1894 Not Before: Jan 7 10:40:41 2019 GMT 1895 Not After : Jan 2 10:40:41 2039 GMT 1896 Subject: C=US, ST=CA, L=LA, O=Example Inc, 1897 OU=certification, CN=Root CA 1898 Subject Public Key Info: 1899 Public Key Algorithm: id-ecPublicKey 1900 Public-Key: (256 bit) 1901 pub: 1902 04:81:49:94:08:2b:6e:81:85:f3:df:53:f5:e0:be: 1903 e6:98:97:33:35:20:00:23:dd:f7:8c:d1:7a:44:3f: 1904 fd:8d:dd:40:90:87:69:c5:56:52:ac:2c:cb:75:c4: 1905 a5:0a:7c:7d:db:7c:22:da:e6:c8:5c:ca:53:82:09: 1906 fd:bb:f1:04:c9 1907 ASN1 OID: prime256v1 1908 NIST CURVE: P-256 1909 X509v3 extensions: 1910 X509v3 Subject Key Identifier: 1911 24:95:E8:16:EF:6F:FC:AA:F3:56:CE:4A:DF:FE:33:CF:49:2A:BB:A8 1912 X509v3 Authority Key Identifier: 1913 keyid: 1914 24:95:E8:16:EF:6F:FC:AA:F3:56:CE:4A:DF:FE:33:CF:49:2A:BB:A8 1916 X509v3 Basic Constraints: critical 1917 CA:TRUE 1918 X509v3 Key Usage: critical 1919 Certificate Sign, CRL Sign 1920 X509v3 Subject Alternative Name: 1921 email:certify@example.com 1922 Signature Algorithm: ecdsa-with-SHA256 1923 30:45:02:21:00:da:e3:7c:96:f1:54:c3:2e:c0:b4:af:52:d4: 1924 6f:3b:7e:cc:96:87:dd:f2:67:bc:ec:36:8f:7b:7f:13:53:27: 1925 2f:02:20:47:a2:8a:e5:c7:30:61:63:b3:c3:83:4b:ab:3c:10: 1926 3f:74:30:70:59:4c:08:9a:aa:0a:c8:70:cd:13:b9:02:ca 1928 C.2. enroll / reenroll 1930 The breakdown of the request is 1932 Certificate Request: 1933 Data: 1934 Version: 0 (0x0) 1935 Subject: C=US, ST=CA, L=LA, O=example Inc, 1936 OU=IoT/serialNumber=Wt1234 1937 Subject Public Key Info: 1938 Public Key Algorithm: id-ecPublicKey 1939 Public-Key: (256 bit) 1940 pub: 1941 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 1942 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 1943 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 1944 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 1945 56:38:e5:9f:d9 1946 ASN1 OID: prime256v1 1947 NIST CURVE: P-256 1948 Attributes: 1949 challengePassword : <256-bit POP linking value> 1950 Requested Extensions: 1951 X509v3 Subject Alternative Name: 1952 othername: 1953 Signature Algorithm: ecdsa-with-SHA256 1954 30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd: 1955 1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38: 1956 92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b: 1957 c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77 1959 The CSR contained a ChallengePassword which is used for POP linking 1960 (Section 6). 1962 The breakdown of the issued certificate response is 1963 Certificate: 1964 Data: 1965 Version: 3 (0x2) 1966 Serial Number: 9112578475118446130 (0x7e7661d7b54e4632) 1967 Signature Algorithm: ecdsa-with-SHA256 1968 Issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1969 CN=802.1AR CA 1970 Validity 1971 Not Before: Jan 31 11:29:16 2019 GMT 1972 Not After : Dec 31 23:59:59 9999 GMT 1973 Subject: C=US, ST=CA, L=LA, O=example Inc, 1974 OU=IoT/serialNumber=Wt1234 1975 Subject Public Key Info: 1976 Public Key Algorithm: id-ecPublicKey 1977 Public-Key: (256 bit) 1978 pub: 1979 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 1980 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 1981 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 1982 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 1983 56:38:e5:9f:d9 1984 ASN1 OID: prime256v1 1985 NIST CURVE: P-256 1986 X509v3 extensions: 1987 X509v3 Basic Constraints: 1988 CA:FALSE 1989 X509v3 Subject Key Identifier: 1990 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 1992 X509v3 Authority Key Identifier: 1993 keyid: 1994 68:D1:65:51:F9:51:BF:C8:2A:43:1D:0D:9F:08:BC:2D:20:5B:11:60 1996 X509v3 Key Usage: critical 1997 Digital Signature, Key Encipherment 1998 X509v3 Subject Alternative Name: 1999 othername: 2000 Signature Algorithm: ecdsa-with-SHA256 2001 30:46:02:21:00:c0:d8:19:96:d2:50:7d:69:3f:3c:48:ea:a5: 2002 ee:94:91:bd:a6:db:21:40:99:d9:81:17:c6:3b:36:13:74:cd: 2003 86:02:21:00:a7:74:98:9f:4c:32:1a:5c:f2:5d:83:2a:4d:33: 2004 6a:08:ad:67:df:20:f1:50:64:21:18:8a:0a:de:6d:34:92:36 2006 C.3. serverkeygen 2008 The following is the breakdown of the request example used. 2010 Certificate Request: 2011 Data: 2012 Version: 0 (0x0) 2013 Subject: O=skg example 2014 Subject Public Key Info: 2015 Public Key Algorithm: id-ecPublicKey 2016 Public-Key: (256 bit) 2017 pub: 2018 04:1b:b8:c1:11:78:96:f9:8e:45:06:c0:3d:70:ef: 2019 be:82:0d:8e:38:ea:97:e9:d6:5d:52:c8:46:0c:58: 2020 52:c5:1d:d8:9a:61:37:0a:28:43:76:0f:c8:59:79: 2021 9d:78:cd:33:f3:c1:84:6e:30:4f:17:17:f8:12:3f: 2022 1a:28:4c:c9:9f 2023 ASN1 OID: prime256v1 2024 NIST CURVE: P-256 2025 Attributes: 2026 a0:00 2027 Signature Algorithm: ecdsa-with-SHA256 2028 30:44:02:20:38:7c:d4:e9:cf:62:8d:4a:f7:7f:92:eb:ed:48: 2029 90:d9:d1:41:dc:a8:6c:d2:75:7d:d1:4c:bd:59:cd:f6:96:18: 2030 02:20:2f:24:5e:82:8c:77:75:43:78:b6:66:60:a4:97:7f:11: 2031 3c:ac:da:a0:cc:7b:ad:7d:14:74:a7:fd:15:5d:09:0d 2033 The following is the breakdown of the private key content of the 2034 server-side key generation response payload. 2036 Private-Key: (256 bit) 2037 priv: 2038 0b:9a:67:78:5b:65:e0:73:60:b6:d2:8c:fc:1d:3f: 2039 39:25:c0:75:57:99:de:ec:a7:45:37:2b:01:69:7b: 2040 d8:a6 2041 pub: 2042 04:1b:b8:c1:11:78:96:f9:8e:45:06:c0:3d:70:ef: 2043 be:82:0d:8e:38:ea:97:e9:d6:5d:52:c8:46:0c:58: 2044 52:c5:1d:d8:9a:61:37:0a:28:43:76:0f:c8:59:79: 2045 9d:78:cd:33:f3:c1:84:6e:30:4f:17:17:f8:12:3f: 2046 1a:28:4c:c9:9f 2047 ASN1 OID: prime256v1 2048 NIST CURVE: P-256 2050 The following is the breakdown of the certificate of the second part 2051 of the server-side key generation response payload. 2053 Certificate: 2054 Data: 2055 Version: 3 (0x2) 2056 Serial Number: 1327972925857878603 (0x126de8571518524b) 2057 Signature Algorithm: ecdsa-with-SHA256 2058 Issuer: O=skg example 2059 Validity 2060 Not Before: Jan 9 08:57:08 2019 GMT 2061 Not After : Jan 4 08:57:08 2039 GMT 2062 Subject: O=skg example 2063 Subject Public Key Info: 2064 Public Key Algorithm: id-ecPublicKey 2065 Public-Key: (256 bit) 2066 pub: 2067 04:1b:b8:c1:11:78:96:f9:8e:45:06:c0:3d:70:ef: 2068 be:82:0d:8e:38:ea:97:e9:d6:5d:52:c8:46:0c:58: 2069 52:c5:1d:d8:9a:61:37:0a:28:43:76:0f:c8:59:79: 2070 9d:78:cd:33:f3:c1:84:6e:30:4f:17:17:f8:12:3f: 2071 1a:28:4c:c9:9f 2072 ASN1 OID: prime256v1 2073 NIST CURVE: P-256 2074 X509v3 extensions: 2075 X509v3 Basic Constraints: 2076 CA:FALSE 2077 Netscape Comment: 2078 OpenSSL Generated Certificate 2079 X509v3 Subject Key Identifier: 2080 49:4B:E5:98:DC:8D:BC:0D:BC:07:1C:48:6B:77:74:60:E5:CC:E6:21 2081 X509v3 Authority Key Identifier: 2082 keyid: 2083 49:4B:E5:98:DC:8D:BC:0D:BC:07:1C:48:6B:77:74:60:E5:CC:E6:21 2085 Signature Algorithm: ecdsa-with-SHA256 2086 30:46:02:21:00:a4:b1:67:d0:f9:ad:d9:20:28:10:e6:bf:6a: 2087 29:0b:8c:fd:fc:9b:9c:9f:ea:2c:c1:c8:fc:3a:46:4f:79:f2: 2088 c2:02:21:00:81:d3:1b:a1:42:75:1a:7b:4a:34:fd:1a:01:fc: 2089 fb:08:71:6b:9e:b5:3b:da:ad:c9:ae:60:b0:8f:52:42:9c:0f 2091 Authors' Addresses 2093 Peter van der Stok 2094 Consultant 2096 Email: consultancy@vanderstok.org 2097 Panos Kampanakis 2098 Cisco Systems 2100 Email: pkampana@cisco.com 2102 Michael C. Richardson 2103 Sandelman Software Works 2105 Email: mcr+ietf@sandelman.ca 2106 URI: http://www.sandelman.ca/ 2108 Shahid Raza 2109 RISE SICS 2110 Isafjordsgatan 22 2111 Kista, Stockholm 16440 2112 SE 2114 Email: shahid@sics.se