idnits 2.17.00 (12 Aug 2021) /tmp/idnits40185/draft-ietf-ace-coap-est-18.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 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == 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 (January 6, 2020) is 859 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: 'ThisRFC' is mentioned on line 1117, but not defined == Missing Reference: 'Empty' is mentioned on line 1869, but not defined == Unused Reference: 'I-D.ietf-lamps-rfc5751-bis' is defined on line 1332, but no explicit reference was found in the text == Outdated reference: draft-ietf-core-multipart-ct has been published as RFC 8710 == Outdated reference: draft-ietf-lamps-rfc5751-bis has been published as RFC 8551 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 ** 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) == Outdated reference: draft-ietf-tls-dtls-connection-id has been published as RFC 9146 == Outdated reference: A later version (-10) exists of draft-moskowitz-ecdsa-pki-07 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). 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: July 9, 2020 Cisco Systems 6 M. Richardson 7 SSW 8 S. Raza 9 RISE SICS 10 January 6, 2020 12 EST over secure CoAP (EST-coaps) 13 draft-ietf-ace-coap-est-18 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 July 9, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7 62 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10 64 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 13 65 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 66 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 15 67 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 68 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16 69 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17 70 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19 71 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21 72 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 23 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 75 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 24 76 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 24 77 9.3. Well-Known URIs Registry . . . . . . . . . . . . . . . . 25 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 10.1. EST server considerations . . . . . . . . . . . . . . . 25 80 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27 81 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 85 13.2. Informative References . . . . . . . . . . . . . . . . . 30 86 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 32 87 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 33 88 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 35 89 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 37 90 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 39 91 Appendix B. EST-coaps Block message examples . . . . . . . . . . 40 92 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 40 93 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 94 Appendix C. Message content breakdown . . . . . . . . . . . . . 45 95 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 45 96 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 46 97 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 48 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 100 1. Change Log 102 EDNOTE: Remove this section before publication 104 -18 106 IESG Reviews fixes. 108 Removed spurious lines introduced in v-17 due to xml2rfc v3. 110 -17 112 v16 remnants by Ben K. 114 Typos. 116 -16 118 Updates to address Yaron S.'s Secdir review. 120 Updates to address David S.'s Gen-ART review. 122 -15 124 Updates to addressed Ben's AD follow up feedback. 126 -14 128 Updates to complete Ben's AD review feedback and discussions. 130 -13 132 Updates based on AD's review and discussions 134 Examples redone without password 136 -12 138 Updated section 5 based on Esko's comments and nits identified. 140 Nits and some clarifications for Esko's new review from 5/21/2019. 142 Nits and some clarifications for Esko's new review from 5/28/2019. 144 -11 145 Updated Server-side keygen to simplify motivation and added 146 paragraphs in Security considerations to point out that random 147 numbers are still needed (feedback from Hannes). 149 -10 151 Addressed WGLC comments 153 More consistent request format in the examples. 155 Explained root resource difference when there is resource 156 discovery 158 Clarified when the client is supposed to do discovery 160 Fixed nits and minor Option length inaccurracies in the examples. 162 -09 164 WGLC comments taken into account 166 consensus about discovery of content-format 168 added additional path for content-format selection 170 merged DTLS sections 172 -08 174 added application/pkix-cert Content-Format TBD287. 176 discovery text clarified 178 Removed text on ct negotiation in connection to multipart-core 180 removed text that duplicates or contradicts RFC7252 (thanks Klaus) 182 Stated that well-known/est is compulsory 184 Use of response codes clarified. 186 removed bugs: Max-Age and Content-Format Options in Request 188 Accept Option explained for est/skg and added in enroll example 190 Added second URI /skc for server-side key gen and a simple cert 191 (not PKCS#7) 192 Persistence of DTLS connection clarified. 194 Minor text fixes. 196 -07: 198 redone examples from scratch with openssl 200 Updated authors. 202 Added CoAP RST as a MAY for an equivalent to an HTTP 204 message. 204 Added serialization example of the /skg CBOR response. 206 Added text regarding expired IDevIDs and persistent DTLS 207 connection that will start using the Explicit TA Database in the 208 new DTLS connection. 210 Nits and fixes 212 Removed CBOR envelop for binary data 214 Replaced TBD8 with 62. 216 Added RFC8174 reference and text. 218 Clarified MTI for server-side key generation and Content-Formats. 219 Defined the /skg MTI (PKCS#8) and the cases where CMS encryption 220 will be used. 222 Moved Fragmentation section up because it was referenced in 223 sections above it. 225 -06: 227 clarified discovery section, by specifying that no discovery may 228 be needed for /.well-known/est URI. 230 added resource type values for IANA 232 added list of compulsory to implement and optional functions. 234 Fixed issues pointed out by the idnits tool. 236 Updated CoAP response codes section with more mappings between EST 237 HTTP codes and EST-coaps CoAP codes. 239 Minor updates to the MTI EST Functions section. 241 Moved Change Log section higher. 243 -05: 245 repaired again 247 TBD8 = 62 removed from C-F registration, to be done in CT draft. 249 -04: 251 Updated Delayed response section to reflect short and long delay 252 options. 254 -03: 256 Removed observe and simplified long waits 258 Repaired Content-Format specification 260 -02: 262 Added parameter discussion in section 8 264 Concluded Content-Format specification using multipart-ct draft 266 examples updated 268 -01: 270 Editorials done. 272 Redefinition of proxy to Registrar in Section 6. Explained better 273 the role of https-coaps Registrar, instead of "proxy" 275 Provide "observe" Option examples 277 extended block message example. 279 inserted new server key generation text in Section 5.8 and 280 motivated server key generation. 282 Broke down details for DTLS 1.3 284 New Media-Type uses CBOR array for multiple Content-Format 285 payloads 287 provided new Content-Format tables 288 new media format for IANA 290 -00 292 copied from vanderstok-ace-coap-04 294 2. Introduction 296 "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used 297 for authenticated/authorized endpoint certificate enrollment (and 298 optionally key provisioning) through a Certificate Authority (CA) or 299 Registration Authority (RA). EST transports messages over HTTPS. 301 This document defines a new transport for EST based on the 302 Constrained Application Protocol (CoAP) since some Internet of Things 303 (IoT) devices use CoAP instead of HTTP. Therefore, this 304 specification utilizes DTLS [RFC6347] and CoAP [RFC7252] instead of 305 TLS [RFC8446] and HTTP [RFC7230]. 307 EST responses can be relatively large and for this reason this 308 specification also uses CoAP Block-Wise Transfer [RFC7959] to offer a 309 fragmentation mechanism of EST messages at the CoAP layer. 311 This document also profiles the use of EST to only support 312 certificate-based client authentication. HTTP Basic or Digest 313 authentication (as described in Section 3.2.3 of [RFC7030]) are not 314 supported. 316 3. Terminology 318 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 319 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 320 "OPTIONAL" in this document are to be interpreted as described in BCP 321 14 [RFC2119] [RFC8174] when, and only when, they appear in all 322 capitals, as shown here. 324 Many of the concepts in this document are taken from [RFC7030]. 325 Consequently, much text is directly traceable to [RFC7030]. 327 4. DTLS and conformance to RFC7925 profiles 329 This section describes how EST-coaps conforms to the profiles of low- 330 resource devices described in [RFC7925]. EST-coaps can transport 331 certificates and private keys. Certificates are responses to 332 (re-)enrollment requests or requests for a trusted certificate list. 333 Private keys can be transported as responses to a server-side key 334 generation request as described in Section 4.4 of [RFC7030] (and 335 subsections) and discussed in Section 5.8 of this document. 337 EST-coaps depends on a secure transport mechanism that secures the 338 exchanged CoAP messages. DTLS is one such secure protocol. No other 339 changes are necessary regarding the secure transport of EST messages. 341 +------------------------------------------------+ 342 | EST request/response messages | 343 +------------------------------------------------+ 344 | CoAP for message transfer and signaling | 345 +------------------------------------------------+ 346 | Secure Transport | 347 +------------------------------------------------+ 349 Figure 1: EST-coaps protocol layers 351 In accordance with sections 3.3 and 4.4 of [RFC7925], the mandatory 352 cipher suite for DTLS in EST-coaps is 353 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. Curve secp256r1 MUST 354 be supported [RFC8422]; this curve is equivalent to the NIST P-256 355 curve. After the publication of [RFC7748], support for Curve25519 356 will likely be required in the future by (D)TLS Profiles for the 357 Internet of Things [RFC7925]. 359 DTLS 1.2 implementations must use the Supported Elliptic Curves and 360 Supported Point Formats Extensions in [RFC8422]. Uncompressed point 361 format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13] 362 implementations differ from DTLS 1.2 because they do not support 363 point format negotiation in favor of a single point format for each 364 curve. Thus, support for DTLS 1.3 does not mandate point format 365 extensions and negotiation. In addition, in DTLS 1.3 the Supported 366 Elliptic Curves extension has been renamed to Supported Groups. 368 CoAP was designed to avoid IP fragmentation. DTLS is used to secure 369 CoAP messages. However, fragmentation is still possible at the DTLS 370 layer during the DTLS handshake when using ECC ciphersuites. If 371 fragmentation is necessary, "DTLS provides a mechanism for 372 fragmenting a handshake message over several records, each of which 373 can be transmitted separately, thus avoiding IP fragmentation" 374 [RFC6347]. 376 The authentication of the EST-coaps server by the EST-coaps client is 377 based on certificate authentication in the DTLS handshake. The EST- 378 coaps client MUST be configured with at least an Implicit TA database 379 which will enable the authentication of the server the first time 380 before updating its trust anchor (Explicit TA) [RFC7030]. 382 The authentication of the EST-coaps client MUST be with a client 383 certificate in the DTLS handshake. This can either be 384 o a previously issued client certificate (e.g., an existing 385 certificate issued by the EST CA); this could be a common case for 386 simple re-enrollment of clients. 388 o a previously installed certificate (e.g., manufacturer IDevID 389 [ieee802.1ar] or a certificate issued by some other party). 390 IDevID's are expected to have a very long life, as long as the 391 device, but under some conditions could expire. In that case, the 392 server MAY authenticate a client certificate against its trust 393 store although the certificate is expired (Section 10). 395 EST-coaps supports the certificate types and Trust Anchors (TA) that 396 are specified for EST in Section 3 of [RFC7030]. 398 As described in Section 2.1 of [RFC5272] proof-of-identity refers to 399 a value that can be used to prove that an end-entity or client is in 400 the possession of and can use the private key corresponding to the 401 certified public key. Additionally, channel-binding information can 402 link proof-of-identity with an established connection. Connection- 403 based proof-of-possession is OPTIONAL for EST-coaps clients and 404 servers. When proof-of-possession is desired, a set of actions are 405 required regarding the use of tls-unique, described in Section 3.5 in 406 [RFC7030]. The tls-unique information consists of the contents of 407 the first "Finished" message in the (D)TLS handshake between server 408 and client [RFC5929]. The client adds the "Finished" message as a 409 ChallengePassword in the attributes section of the PKCS#10 Request 410 [RFC5967] to prove that the client is indeed in control of the 411 private key at the time of the (D)TLS session establishment. 413 In the case of handshake message fragmentation, if proof-of- 414 possession is desired, the Finished message added as the 415 ChallengePassword in the CSR is calculated as specified by the DTLS 416 standards. We summarize it here for convenience. For DTLS 1.2, in 417 the event of handshake message fragmentation, the Hash of the 418 handshake messages used in the MAC calculation of the Finished 419 message must be computed on each reassembled message, as if each 420 message had not been fragmented (Section 4.2.6 of [RFC6347]). The 421 Finished message is calculated as shown in Section 7.4.9 of 422 [RFC5246]. Similarly, for DTLS 1.3, the Finished message must be 423 computed as if each handshake message had been sent as a single 424 fragment (Section 5.8 of [I-D.ietf-tls-dtls13]) following the 425 algorithm described in 4.4.4 of [RFC8446]. 427 In a constrained CoAP environment, endpoints can't always afford to 428 establish a DTLS connection for every EST transaction. An EST-coaps 429 DTLS connection MAY remain open for sequential EST transactions, 430 which was not the case with [RFC7030]. For example, if a /crts 431 request is followed by a /sen request, both can use the same 432 authenticated DTLS connection. However, when a /crts request is 433 included in the set of sequential EST transactions, some additional 434 security considerations apply regarding the use of the Implicit and 435 Explicit TA database as explained in Section 10.1. 437 Given that after a successful enrollment, it is more likely that a 438 new EST transaction will not take place for a significant amount of 439 time, the DTLS connections SHOULD only be kept alive for EST messages 440 that are relatively close to each other. These could include a /sen 441 immediatelly following a /crts when a device is getting bootstrapped. 442 In some cases, like NAT rebinding, keeping the state of a connection 443 is not possible when devices sleep for extended periods of time. In 444 such occasions, [I-D.ietf-tls-dtls-connection-id] negotiates a 445 connection ID that can eliminate the need for new handshake and its 446 additional cost; or DTLS session resumption provides a less costly 447 alternative than re-doing a full DTLS handshake. 449 5. Protocol Design 451 EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise 452 Transfer [RFC7959] to avoid IP fragmentation. The use of Blocks for 453 the transfer of larger EST messages is specified in Section 5.6. 454 Figure 1 shows the layered EST-coaps architecture. 456 The EST-coaps protocol design follows closely the EST design. The 457 supported message types in EST-coaps are: 459 o CA certificate retrieval needed to receive the complete set of CA 460 certificates. 462 o Simple enroll and re-enroll for a CA to sign client identity 463 public key. 465 o Certificate Signing Request (CSR) attribute messages that informs 466 the client of the fields to include in a CSR. 468 o Server-side key generation messages to provide a client identity 469 private key when the client chooses so. 471 While [RFC7030] permits a number of the EST functions to be used 472 without authentication, this specification requires that the client 473 MUST be authenticated for all functions. 475 5.1. Discovery and URIs 477 EST-coaps is targeted for low-resource networks with small packets. 478 Two types of installations are possible: (1) rigid ones, where the 479 address and the supported functions of the EST server(s) are known, 480 and (2) a flexible one, where the EST server and its supported 481 functions need to be discovered. 483 For both types of installations, saving header space is important and 484 short EST-coaps URIs are specified in this document. These URIs are 485 shorter than the ones in [RFC7030]. Two example EST-coaps resource 486 path names are: 488 coaps://example.com:/.well-known/est/ 489 coaps://example.com:/.well-known/est/ArbitraryLabel/ 491 The short-est strings are defined in Table 1. Arbitrary Labels are 492 usually defined and used by EST CAs in order to route client requests 493 to the appropriate certificate profile. Implementers should consider 494 using short labels to minimize transmission overhead. 496 The EST-coaps server URIs, obtained through discovery of the EST- 497 coaps resource(s) as shown below, are of the form: 499 coaps://example.com:// 500 coaps://example.com://ArbitraryLabel/ 502 Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and 503 corresponding paths which are supported by EST. Table 1 provides the 504 mapping from the EST URI path to the shorter EST-coaps URI path. 506 +-------------------+-------------------------------+ 507 | EST | EST-coaps | 508 +-------------------+-------------------------------+ 509 | /cacerts | /crts | 510 | /simpleenroll | /sen | 511 | /simplereenroll | /sren | 512 | /serverkeygen | /skg (PKCS#7) | 513 | /serverkeygen | /skc (application/pkix-cert) | 514 | /csrattrs | /att | 515 +-------------------+-------------------------------+ 517 Table 1: Short EST-coaps URI path 519 The /skg message is the EST /serverkeygen equivalent where the client 520 requests a certificate in PKCS#7 format and a private key. If the 521 client prefers a single application/pkix-cert certificate instead of 522 PKCS#7, it will make an /skc request. In both cases (i.e., /skg, 523 /skc) a private key MUST be returned. 525 Clients and servers MUST support the short resource EST-coaps URIs. 527 In the context of CoAP, the presence and location of (path to) the 528 EST resources are discovered by sending a GET request to "/.well- 529 known/core" including a resource type (RT) parameter with the value 530 "ace.est*" [RFC6690]. The example below shows the discovery over 531 CoAPS of the presence and location of EST-coaps resources. Linefeeds 532 are included only for readability. 534 REQ: GET /.well-known/core?rt=ace.est* 536 RES: 2.05 Content 537 ;rt="ace.est.crts";ct="281 TBD287", 538 ;rt="ace.est.sen";ct="281 TBD287", 539 ;rt="ace.est.sren";ct="281 TBD287", 540 ;rt="ace.est.att";ct=285, 541 ;rt="ace.est.skg";ct=62, 542 ;rt="ace.est.skc";ct=62 544 The first three lines, describing ace.est.crts, ace.est.sen, and 545 ace.est.sren, of the discovery response above MUST be returned if the 546 server supports resource discovery. The last three lines are only 547 included if the corresponding EST functions are implemented (see 548 Table 2). The Content-Formats in the response allow the client to 549 request one that is supported by the server. These are the values 550 that would be sent in the client request with an Accept option. 552 Discoverable port numbers can be returned in the response payload. 553 An example response payload for non-default CoAPS server port 61617 554 follows below. Linefeeds are included only for readability. 556 REQ: GET /.well-known/core?rt=ace.est* 558 RES: 2.05 Content 559 ;rt="ace.est.crts"; 560 ct="281 TBD287", 561 ;rt="ace.est.sen"; 562 ct="281 TBD287", 563 ;rt="ace.est.sren"; 564 ct="281 TBD287", 565 ;rt="ace.est.att"; 566 ct=285, 567 ;rt="ace.est.skg"; 568 ct=62, 569 ;rt="ace.est.skc"; 570 ct=62 572 The server MUST support the default /.well-known/est root resource. 573 The server SHOULD support resource discovery when it supports non- 574 default URIs (like /est or /est/ArbitraryLabel) or ports. The client 575 SHOULD use resource discovery when it is unaware of the available 576 EST-coaps resources. 578 Throughout this document the example root resource of /est is used. 580 5.2. Mandatory/optional EST Functions 582 This specification contains a set of required-to-implement functions, 583 optional functions, and not specified functions. The unspecified 584 functions are deemed too expensive for low-resource devices in 585 payload and calculation times. 587 Table 2 specifies the mandatory-to-implement or optional 588 implementation of the EST-coaps functions. Discovery of the 589 existence of optional functions is described in Section 5.1. 591 +-------------------+--------------------------+ 592 | EST Functions | EST-coaps implementation | 593 +-------------------+--------------------------+ 594 | /cacerts | MUST | 595 | /simpleenroll | MUST | 596 | /simplereenroll | MUST | 597 | /fullcmc | Not specified | 598 | /serverkeygen | OPTIONAL | 599 | /csrattrs | OPTIONAL | 600 +-------------------+--------------------------+ 602 Table 2: List of EST-coaps functions 604 5.3. Payload formats 606 EST-coaps is designed for low-resource devices and hence does not 607 need to send Base64-encoded data. Simple binary is more efficient 608 (30% smaller payload for DER-encoded ASN.1) and well supported by 609 CoAP. Thus, the payload for a given Media-Type follows the ASN.1 610 structure of the Media-Type and is transported in binary format. 612 The Content-Format (HTTP Content-Type equivalent) of the CoAP message 613 determines which EST message is transported in the CoAP payload. The 614 Media-Types specified in the HTTP Content-Type header field 615 (Section 3.2.2 of [RFC7030]) are specified by the Content-Format 616 Option (12) of CoAP. The combination of URI-Path and Content-Format 617 in EST-coaps MUST map to an allowed combination of URI and Media-Type 618 in EST. The required Content-Formats for these requests and response 619 messages are defined in Section 9.1. The CoAP response codes are 620 defined in Section 5.5. 622 Content-Format TBD287 can be used in place of 281 to carry a single 623 certificate instead of a PKCS#7 container in a /crts, /sen, /sren or 624 /skg response. Content-Format 281 MUST be supported by EST-coaps 625 servers. Servers MAY also support Content-Format TBD287. It is up 626 to the client to support only Content-Format 281, TBD287 or both. 627 The client will use a COAP Accept Option in the request to express 628 the preferred response Content-Format. If an Accept Option is not 629 included in the request, the client is not expressing any preference 630 and the server SHOULD choose format 281. 632 Content-Format 286 is used in /sen, /sren and /skg requests and 285 633 in /att responses. 635 A representation with Content-Format identifier 62 contains a 636 collection of representations along with their respective Content- 637 Format. The Content-Format identifies the Media-Type application/ 638 multipart-core specified in [I-D.ietf-core-multipart-ct]. For 639 example, a collection, containing two representations in response to 640 a EST-coaps server-side key generation /skg request, could include a 641 private key in PKCS#8 [RFC5958] with Content-Format identifier 284 642 (0x011C) and a single certificate in a PKCS#7 container with Content- 643 Format identifier 281 (0x0119). Such a collection would look like 644 [284,h'0123456789abcdef', 281,h'fedcba9876543210'] in diagnostic CBOR 645 notation. The serialization of such CBOR content would be 647 84 # array(4) 648 19 011C # unsigned(284) 649 48 # bytes(8) 650 0123456789ABCDEF # "\x01#Eg\x89\xAB\xCD\xEF" 651 19 0119 # unsigned(281) 652 48 # bytes(8) 653 FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10" 655 Multipart /skg response serialization 657 When the client makes an /skc request the certificate returned with 658 the private key is a single X.509 certificate (not a PKCS#7 659 container) with Content-Format identifier TBD287 (0x011F) instead of 660 281. In cases where the private key is encrypted with CMS (as 661 explained in Section 5.8) the Content-Format identifier is 280 662 (0x0118) instead of 284. The content format used in the response is 663 summarized in Table 3. 665 +----------+-----------------+-----------------+ 666 | Function | Response part 1 | Response part 2 | 667 +----------+-----------------+-----------------+ 668 | /skg | 284 | 281 | 669 | /skc | 280 | TBD287 | 670 +----------+-----------------+-----------------+ 672 Table 3: response content formats for skg and skc 674 The key and certificate representations are DER-encoded ASN.1, in its 675 native binary form. An example is shown in Appendix A.3. 677 5.4. Message Bindings 679 The general EST-coaps message characteristics are: 681 o EST-coaps servers sometimes need to provide delayed responses 682 which are preceded by an immediately returned empty ACK or an ACK 683 containing response code 5.03 as explained in Section 5.7. Thus, 684 it is RECOMMENDED for implementers to send EST-coaps requests in 685 confirmable CON CoAP messages. 687 o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- 688 Format, Block1, Block2, and Accept. These CoAP Options are used 689 to communicate the HTTP fields specified in the EST REST messages. 690 The Uri-host and Uri-Port Options can be omitted from the COAP 691 message sent on the wire. When omitted, they are logically 692 assumed to be the transport protocol destination address and port 693 respectively. Explicit Uri-Host and Uri-Port Options are 694 typically used when an endpoint hosts multiple virtual servers and 695 uses the Options to route the requests accordingly. Other COAP 696 Options should be handled in accordance with [RFC7252]. 698 o EST URLs are HTTPS based (https://), in CoAP these are assumed to 699 be translated to CoAPS (coaps://) 701 Table 1 provides the mapping from the EST URI path to the EST-coaps 702 URI path. Appendix A includes some practical examples of EST 703 messages translated to CoAP. 705 5.5. CoAP response codes 707 Section 5.9 of [RFC7252] and Section 7 of [RFC8075] specify the 708 mapping of HTTP response codes to CoAP response codes. The success 709 code in response to an EST-coaps GET request (/crts, /att), is 2.05. 710 Similarly, 2.04 is used in successful response to EST-coaps POST 711 requests (/sen, /sren, /skg, /skc). 713 EST makes use of HTTP 204 or 404 responses when a resource is not 714 available for the client. In EST-coaps 2.04 is used in response to a 715 POST (/sen, /sren, /skg, /skc). 4.04 is used when the resource is not 716 available for the client. 718 HTTP response code 202 with a Retry-After header field in [RFC7030] 719 has no equivalent in CoAP. HTTP 202 with Retry-After is used in EST 720 for delayed server responses. Section 5.7 specifies how EST-coaps 721 handles delayed messages with 5.03 responses with a Max-Age Option. 723 Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes have 724 their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes 725 in EST-coaps. Table 4 summarizes the EST-coaps response codes. 727 +-----------------+-----------------+-------------------------------+ 728 | operation | EST-coaps | Description | 729 | | response code | | 730 +-----------------+-----------------+-------------------------------+ 731 | /crts, /att | 2.05 | Success. Certs included in | 732 | | | the response payload. | 733 | | 4.xx / 5.xx | Failure. | 734 | /sen, /skg, | 2.04 | Success. Cert included in the | 735 | /sren, /skc | | response payload. | 736 | | 5.03 | Retry in Max-Age Option time. | 737 | | 4.xx / 5.xx | Failure. | 738 +-----------------+-----------------+-------------------------------+ 740 Table 4: EST-coaps response codes 742 5.6. Message fragmentation 744 DTLS defines fragmentation only for the handshake and not for secure 745 data exchange (DTLS records). [RFC6347] states that to avoid using 746 IP fragmentation, which involves error-prone datagram reconstitution, 747 invokers of the DTLS record layer should size DTLS records so that 748 they fit within any Path MTU estimates obtained from the record 749 layer. In addition, invokers residing on a 6LoWPAN over IEEE 750 802.15.4 [ieee802.15.4] network are recommended to size CoAP messages 751 such that each DTLS record will fit within one or two IEEE 802.15.4 752 frames. 754 That is not always possible in EST-coaps. Even though ECC 755 certificates are small in size, they can vary greatly based on 756 signature algorithms, key sizes, and Object Identifier (OID) fields 757 used. For 256-bit curves, common ECDSA cert sizes are 500-1000 bytes 758 which could fluctuate further based on the algorithms, OIDs, Subject 759 Alternative Names (SAN) and cert fields. For 384-bit curves, ECDSA 760 certificates increase in size and can sometimes reach 1.5KB. 762 Additionally, there are times when the EST cacerts response from the 763 server can include multiple certificates that amount to large 764 payloads. Section 4.6 of CoAP [RFC7252] describes the possible 765 payload sizes: "if nothing is known about the size of the headers, 766 good upper bounds are 1152 bytes for the message size and 1024 bytes 767 for the payload size". Section 4.6 of [RFC7252] also suggests that 768 IPv4 implementations may want to limit themselves to more 769 conservative IPv4 datagram sizes such as 576 bytes. Even with ECC, 770 EST-coaps messages can still exceed MTU sizes on the Internet or 771 6LoWPAN [RFC4919] (Section 2 of [RFC7959]). EST-coaps needs to be 772 able to fragment messages into multiple DTLS datagrams. 774 To perform fragmentation in CoAP, [RFC7959] specifies the Block1 775 Option for fragmentation of the request payload and the Block2 Option 776 for fragmentation of the return payload of a CoAP flow. As explained 777 in Section 1 of [RFC7959], block-wise transfers should be used in 778 Confirmable CoAP messages to avoid the exacerbation of lost blocks. 779 EST-coaps servers MUST implement Block1 and Block2. EST-coaps 780 clients MUST implement Block2. EST-coaps clients MUST implement 781 Block1 only if they are expecting to send EST-coaps requests with a 782 packet size that exceeds the Path MTU. 784 [RFC7959] also defines Size1 and Size2 Options to provide size 785 information about the resource representation in a request and 786 response. EST-client and server MAY support Size1 and Size2 Options. 788 Examples of fragmented EST-coaps messages are shown in Appendix B. 790 5.7. Delayed Responses 792 Server responses can sometimes be delayed. According to 793 Section 5.2.2 of [RFC7252], a slow server can acknowledge the request 794 and respond later with the requested resource representation. In 795 particular, a slow server can respond to an EST-coaps enrollment 796 request with an empty ACK with code 0.00, before sending the 797 certificate to the client after a short delay. If the certificate 798 response is large, the server will need more than one Block2 block to 799 transfer it. 801 This situation is shown in Figure 2. The client sends an enrollment 802 request that uses N1+1 Block1 blocks. The server uses an empty 0.00 803 ACK to announce the delayed response which is provided later with 804 2.04 messages containing N2+1 Block2 Options. The first 2.04 is a 805 confirmable message that is acknowledged by the client. Onwards, the 806 client acknowledges all subsequent Block2 blocks. The notation of 807 Figure 2 is explained in Appendix B.1. 809 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> 810 <-- (ACK) (1:0/1/256) (2.31 Continue) 811 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> 812 <-- (ACK) (1:1/1/256) (2.31 Continue) 813 . 814 . 815 . 816 POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> 817 <-- (0.00 empty ACK) 818 | 819 ... Short delay before the certificate is ready ... 820 | 821 <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)} 822 (ACK) --> 823 POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> 824 <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)} 825 . 826 . 827 . 828 POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> 829 <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} 831 Figure 2: EST-COAP enrollment with short wait 833 If the server is very slow (for example, manual intervention is 834 required which would take minutes), it SHOULD respond with an ACK 835 containing response code 5.03 (Service unavailable) and a Max-Age 836 Option to indicate the time the client SHOULD wait before sending 837 another request to obtain the content. After a delay of Max-Age, the 838 client SHOULD resend the identical CSR to the server. As long as the 839 server continues to respond with response code 5.03 (Service 840 Unavailable) with a Max-Age Option, the client will continue to delay 841 for Max-Age and then resend the enrollment request until the server 842 responds with the certificate or the client abandons the request for 843 policy or other reasons. 845 To demonstrate this scenario, Figure 3 shows a client sending an 846 enrollment request that uses N1+1 Block1 blocks to send the CSR to 847 the server. The server needs N2+1 Block2 blocks to respond, but also 848 needs to take a long delay (minutes) to provide the response. 849 Consequently, the server uses a 5.03 ACK response with a Max-Age 850 Option. The client waits for a period of Max-Age as many times as it 851 receives the same 5.03 response and retransmits the enrollment 852 request until it receives a certificate in a fragmented 2.04 853 response. 855 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> 856 <-- (ACK) (1:0/1/256) (2.31 Continue) 857 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> 858 <-- (ACK) (1:1/1/256) (2.31 Continue) 859 . 860 . 861 . 862 POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> 863 <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) 864 | 865 | 866 ... Client tries again after Max-Age with identical payload ... 867 | 868 | 869 POST [2001:db8::2:1]:61616/est/sen(CON)(1:0/1/256){CSR (frag# 1)}--> 870 <-- (ACK) (1:0/1/256) (2.31 Continue) 871 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> 872 <-- (ACK) (1:1/1/256) (2.31 Continue) 873 . 874 . 875 . 876 POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> 877 | 878 ... Immediate response when certificate is ready ... 879 | 880 <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)} 881 POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> 882 <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)} 883 . 884 . 885 . 886 POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> 887 <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} 889 Figure 3: EST-COAP enrollment with long wait 891 5.8. Server-side Key Generation 893 Private keys can be generated on the server to support scenarios 894 where serer-side key generation is needed. Such scenarios include 895 those where it is considered more secure to generate the long-lived, 896 random private key that identifies the client at the server, or where 897 the resources spent to generate a random private key at the client 898 are considered scarce, or where the security policy requires that the 899 certificate public and corresponding private keys are centrally 900 generated and controlled. As always, it is necessary to use proper 901 random numbers in various protocols such as (D)TLS (Section 10.1). 903 When requesting server-side key generation, the client asks for the 904 server or proxy to generate the private key and the certificate, 905 which are transferred back to the client in the server-side key 906 generation response. In all respects, the server treats the CSR as 907 it would treat any enroll or re-enroll CSR; the only distinction here 908 is that the server MUST ignore the public key values and signature in 909 the CSR. These are included in the request only to allow re-use of 910 existing codebases for generating and parsing such requests. 912 The client /skg request is for a certificate in a PKCS#7 container 913 and private key in two application/multipart-core elements. 914 Respectively, an /skc request is for a single application/pkix-cert 915 certificate and a private key. The private key Content-Format 916 requested by the client is indicated in the PKCS#10 CSR request. If 917 the request contains SMIMECapabilities and DecryptKeyIdentifier or 918 AsymmetricDecryptKeyIdentifier the client is expecting Content-Format 919 280 for the private key. Then this private key is encrypted 920 symmetrically or asymmetrically as per [RFC7030]. The symmetric key 921 or the asymmetric keypair establishment method is out of scope of 922 this specification. A /skg or /skc request with a CSR without 923 SMIMECapabilities expects an application/multipart-core with an 924 unencrypted PKCS#8 private key with Content-Format 284. 926 The EST-coaps server-side key generation response is returned with 927 Content-Format application/multipart-core 928 [I-D.ietf-core-multipart-ct] containing a CBOR array with four items 929 (Section 5.3). The two representations (each consisting of two CBOR 930 array items) do not have to be in a particular order since each 931 representation is preceded by its Content-Format ID. Depending on 932 the request, the private key can be in unprotected PKCS#8 [RFC5958] 933 format (Content-Format 284) or protected inside of CMS SignedData 934 (Content-Format 280). The SignedData, placed in the outermost 935 container, is signed by the party that generated the private key, 936 which may be the EST server or the EST CA. SignedData placed within 937 the Enveloped Data does not need additional signing as explained in 938 Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted 939 key is included in the encryptedKey attribute in a KEKRecipientInfo 940 structure. In the case where the asymmetric encryption key is 941 suitable for transport key operations the generated private key is 942 encrypted with a symmetric key. The symmetric key itself is 943 encrypted by the client-defined (in the CSR) asymmetric public key 944 and is carried in an encryptedKey attribute in a 945 KeyTransRecipientInfo structure. Finally, if the asymmetric 946 encryption key is suitable for key agreement, the generated private 947 key is encrypted with a symmetric key. The symmetric key itself is 948 encrypted by the client defined (in the CSR) asymmetric public key 949 and is carried in an recipientEncryptedKeys attribute in a 950 KeyAgreeRecipientInfo. 952 [RFC7030] recommends the use of additional encryption of the returned 953 private key. For the context of this specification, clients and 954 servers that choose to support server-side key generation MUST 955 support unprotected (PKCS#8) private keys (Content-Format 284). 956 Symmetric or asymmetric encryption of the private key (CMS 957 EnvelopedData, Content-Format 280) SHOULD be supported for 958 deployments where end-to-end encryption is needed between the client 959 and a server. Such cases could include architectures where an entity 960 between the client and the CA terminates the DTLS connection 961 (Registrar in Figure 4). Although [RFC7030] strongly recommends that 962 clients request the use of CMS encryption on top of the TLS channel's 963 protection, this document does not make such a recommendation; CMS 964 encryption can still be used when mandated by the use-case. 966 6. HTTPS-CoAPS Registrar 968 In real-world deployments, the EST server will not always reside 969 within the CoAP boundary. The EST server can exist outside the 970 constrained network in which case it will support TLS/HTTP instead of 971 CoAPS. In such environments EST-coaps is used by the client within 972 the CoAP boundary and TLS is used to transport the EST messages 973 outside the CoAP boundary. A Registrar at the edge is required to 974 operate between the CoAP environment and the external HTTP network as 975 shown in Figure 4. 977 Constrained Network 978 .------. .----------------------------. 979 | CA | |.--------------------------.| 980 '------' || || 981 | || || 982 .------. HTTP .-----------------. CoAPS .-----------. || 983 | EST |<------->|EST-coaps-to-HTTPS|<------->| EST Client| || 984 |Server|over TLS | Registrar | '-----------' || 985 '------' '-----------------' || 986 || || 987 |'--------------------------'| 988 '----------------------------' 990 Figure 4: EST-coaps-to-HTTPS Registrar at the CoAP boundary. 992 The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream 993 and initiate EST connections over TLS upstream. The Registrar MUST 994 authenticate and optionally authorize the client requests while it 995 MUST be authenticated by the EST server or CA. The trust 996 relationship between the Registrar and the EST server SHOULD be pre- 997 established for the Registrar to proxy these connections on behalf of 998 various clients. 1000 When enforcing Proof-of-Possession (PoP) linking, the DTLS tls-unique 1001 value of the (D)TLS session is used to prove that the private key 1002 corresponding to the public key is in the possession of the client 1003 and was used to establish the connection as explained in Section 4. 1004 The PoP linking information is lost between the EST-coaps client and 1005 the EST server when a Registrar is present. The EST server becomes 1006 aware of the presence of a Registrar from its TLS client certificate 1007 that includes id-kp-cmcRA [RFC6402] extended key usage extension 1008 (EKU). As explained in Section 3.7 of [RFC7030], the "EST server 1009 SHOULD apply an authorization policy consistent with a Registrar 1010 client. For example, it could be configured to accept PoP linking 1011 information that does not match the current TLS session because the 1012 authenticated EST client Registrar has verified this information when 1013 acting as an EST server". 1015 Table 1 contains the URI mappings between EST-coaps and EST that the 1016 Registrar MUST adhere to. Section 5.5 of this specification and 1017 Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP 1018 response codes, that determine how the Registrar MUST translate CoAP 1019 response codes from/to HTTP status codes. The mapping from CoAP 1020 Content-Format to HTTP Content-Type is defined in Section 9.1. 1021 Additionally, a conversion from CBOR major type 2 to Base64 encoding 1022 MUST take place at the Registrar. If CMS end-to-end encryption is 1023 employed for the private key, the encrypted CMS EnvelopedData blob 1024 MUST be converted at the Registrar to binary CBOR type 2 downstream 1025 to the client. This is a format conversion that does not require 1026 decryption of the CMS EnvelopedData. 1028 A deviation from the mappings in Table 1 could take place if clients 1029 that leverage server-side key generation preferred for the enrolled 1030 keys to be generated by the Registrar in the case the CA does not 1031 support server-side key generation. Such a Registrar is responsible 1032 for generating a new CSR signed by a new key which will be returned 1033 to the client along with the certificate from the CA. In these 1034 cases, the Registrar MUST use random number generation with proper 1035 entropy. 1037 Due to fragmentation of large messages into blocks, an EST-coaps-to- 1038 HTTP Registrar MUST reassemble the BLOCKs before translating the 1039 binary content to Base64, and consecutively relay the message 1040 upstream. 1042 The EST-coaps-to-HTTP Registrar MUST support resource discovery 1043 according to the rules in Section 5.1. 1045 7. Parameters 1047 This section addresses transmission parameters described in sections 1048 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on 1049 the CoAP parameters in [RFC7252], but the setting of the CoAP 1050 parameter values may have consequence for the setting of the EST 1051 parameter values. 1053 Implementations should follow the default CoAP configuration 1054 parameters [RFC7252]. However, depending on the implementation 1055 scenario, retransmissions and timeouts can also occur on other 1056 networking layers, governed by other configuration parameters. When 1057 a change in a server parameter has taken place, the parameter values 1058 in the communicating endpoints MUST be adjusted as necessary. 1059 Examples of how parameters could be adjusted include higher layer 1060 congestion protocols, provisioning agents and configurations included 1061 in firmware updates. 1063 Some further comments about some specific parameters, mainly from 1064 Table 2 in [RFC7252]: 1066 o NSTART: A parameter that controls the number of simultaneous 1067 outstanding interactions that a client maintains to a given 1068 server. An EST-coaps client is expected to control at most one 1069 interaction with a given server, which is the default NSTART value 1070 defined in [RFC7252]. 1072 o DEFAULT_LEISURE: This setting is only relevant in multicast 1073 scenarios, outside the scope of EST-coaps. 1075 o PROBING_RATE: A parameter which specifies the rate of re-sending 1076 non-confirmable messages. In the rare situations that non- 1077 confirmable messages are used, the default PROBING_RATE value 1078 defined in [RFC7252] applies. 1080 Finally, the Table 3 parameters in [RFC7252] are mainly derived from 1081 Table 2. Directly changing parameters on one table would affect 1082 parameters on the other. 1084 8. Deployment limitations 1086 Although EST-coaps paves the way for the utilization of EST by 1087 constrained devices in constrained networks, some classes of devices 1088 [RFC7228] will not have enough resources to handle the payloads that 1089 come with EST-coaps. The specification of EST-coaps is intended to 1090 ensure that EST works for networks of constrained devices that choose 1091 to limit their communications stack to DTLS/CoAP. It is up to the 1092 network designer to decide which devices execute the EST protocol and 1093 which do not. 1095 9. IANA Considerations 1097 9.1. Content-Format Registry 1099 Additions to the sub-registry "CoAP Content-Formats", within the 1100 "CoRE Parameters" registry [COREparams] are specified in Table 5. 1101 These have been registered provisionally in the IETF Review or IESG 1102 Approval range (256-9999). 1104 +------------------------------+-------+----------------------------+ 1105 | HTTP Content-Type | ID | Reference | 1106 +------------------------------+-------+----------------------------+ 1107 | application/pkcs7-mime; | 280 | [RFC7030] [I-D.ietf-lamps- | 1108 | smime-type=server-generated- | | rfc5751-bis] [ThisRFC] | 1109 | key | | | 1110 | application/pkcs7-mime; | 281 | [I-D.ietf-lamps-rfc5751-bi | 1111 | smime-type=certs-only | | s] [ThisRFC] | 1112 | application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- | 1113 | | | rfc5751-bis] [ThisRFC] | 1114 | application/csrattrs | 285 | [RFC7030] | 1115 | application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- | 1116 | | | rfc5751-bis] [ThisRFC] | 1117 | application/pkix-cert | TBD28 | [RFC2585] [ThisRFC] | 1118 | | 7 | | 1119 +------------------------------+-------+----------------------------+ 1121 Table 5: New CoAP Content-Formats 1123 It is suggested that 287 is allocated to TBD287. 1125 9.2. Resource Type registry 1127 This memo registers new Resource Type (rt=) Link Target Attributes in 1128 the "Resource Type (rt=) Link Target Attribute Values" subregistry 1129 under the "Constrained RESTful Environments (CoRE) Parameters" 1130 registry. 1132 o rt="ace.est.crts". This resource depicts the support of EST get 1133 cacerts. 1135 o rt="ace.est.sen". This resource depicts the support of EST simple 1136 enroll. 1138 o rt="ace.est.sren". This resource depicts the support of EST 1139 simple reenroll. 1141 o rt="ace.est.att". This resource depicts the support of EST get 1142 CSR attributes. 1144 o rt="ace.est.skg". This resource depicts the support of EST 1145 server-side key generation with the returned certificate in a 1146 PKCS#7 container. 1148 o rt="ace.est.skc". This resource depicts the support of EST 1149 server-side key generation with the returned certificate in 1150 application/pkix-cert format. 1152 9.3. Well-Known URIs Registry 1154 A new additional reference is requested for the est URI in the Well- 1155 Known URIs registry: 1157 +------+--------+---------+---------+----------+---------+----------+ 1158 | URI | Change | Referen | Status | Related | Date Re | Date | 1159 | Suff | Contro | ces | | Informat | gistere | Modified | 1160 | ix | ller | | | ion | d | | 1161 +------+--------+---------+---------+----------+---------+----------+ 1162 | est | IETF | [RFC703 | permane | | 2013-08 | [THIS | 1163 | | | 0] | nt | | -16 | RFC's pu | 1164 | | | [THIS | | | | blicatio | 1165 | | | RFC] | | | | n date] | 1166 +------+--------+---------+---------+----------+---------+----------+ 1168 10. Security Considerations 1170 10.1. EST server considerations 1172 The security considerations of Section 6 of [RFC7030] are only 1173 partially valid for the purposes of this document. As HTTP Basic 1174 Authentication is not supported, the considerations expressed for 1175 using passwords do not apply. The other portions of the security 1176 considerations of [RFC7030] continue to apply. 1178 Modern security protocols require random numbers to be available 1179 during the protocol run, for example for nonces and ephemeral (EC) 1180 Diffie-Hellman key generation. This capability to generate random 1181 numbers is also needed when the constrained device generates the 1182 private key (that corresponds to the public key enrolled in the CSR). 1183 When server-side key generation is used, the constrained device 1184 depends on the server to generate the private key randomly, but it 1185 still needs locally generated random numbers for use in security 1186 protocols, as explained in Section 12 of [RFC7925]. Additionally, 1187 the transport of keys generated at the server is inherently risky. 1188 For those deploying server-side key generation, analysis SHOULD be 1189 done to establish whether server-side key generation increases or 1190 decreases the probability of digital identity theft. 1192 It is important to note that, as pointed out in [PsQs], sources 1193 contributing to the randomness pool used to generate random numbers 1194 on laptops or desktop PCs, such as mouse movement, timing of 1195 keystrokes, or air turbulence on the movement of hard drive heads, 1196 are not available on many constrained devices. Other sources have to 1197 be used or dedicated hardware has to be added. Selecting hardware 1198 for an IoT device that is capable of producing high-quality random 1199 numbers is therefore important [RSAfact]. 1201 As discussed in Section 6 of [RFC7030], it is "RECOMMENDED that the 1202 Implicit Trust Anchor database used for EST server authentication is 1203 carefully managed to reduce the chance of a third-party CA with poor 1204 certification practices jeopardizing authentication. Disabling the 1205 Implicit Trust Anchor database after successfuly receiving the 1206 Distribution of CA certificates response (Section 4.1.3) limits any 1207 risk to the first TLS exchange". Alternatively, in a case where a 1208 /sen request immediately follows a /crts, a client MAY choose to keep 1209 the connection authenticated by the Implicit TA open for efficiency 1210 reasons (Section 4). A client that interleaves EST-coaps /crts 1211 request with other requests in the same DTLS connection SHOULD 1212 revalidate the server certificate chain against the updated Explicit 1213 TA from the /crts response before proceeding with the subsequent 1214 requests. If the server certificate chain does not authenticate 1215 against the database, the client SHOULD close the connection without 1216 completing the rest of the requests. The updated Explicit TA MUST 1217 continue to be used in new DTLS connections. 1219 In cases where the IDevID used to authenticate the client is expired 1220 the server MAY still authenticate the client because IDevIDs are 1221 expected to live as long as the device itself (Section 4). In such 1222 occasions, checking the certificate revocation status or authorizing 1223 the client using another method is important for the server to raise 1224 its confidence that the client can be trusted. 1226 In accordance with [RFC7030], TLS cipher suites that include 1227 "_EXPORT_" and "_DES_" in their names MUST NOT be used. More 1228 recommendations for secure use of TLS and DTLS are included in 1229 [BCP195]. 1231 As described in CMC, Section 6.7 of [RFC5272], "For keys that can be 1232 used as signature keys, signing the certification request with the 1233 private key serves as a PoP on that key pair". The inclusion of tls- 1234 unique in the certificate request links the proof-of-possession to 1235 the TLS proof-of-identity. This implies but does not prove that only 1236 the authenticated client currently has access to the private key. 1238 What's more, CMC PoP linking uses tls-unique as it is defined in 1239 [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing 1240 a man-in-the-middle to leverage session resumption and renegotiation 1241 to inject himself between a client and server even when channel 1242 binding is in use. Implementers should use the Extended Master 1243 Secret Extension in DTLS [RFC7627] to prevent such attacks. In the 1244 context of this specification, an attacker could invalidate the 1245 purpose of the PoP linking ChallengePassword in the client request by 1246 resuming an EST-coaps connection. Even though the practical risk of 1247 such an attack to EST-coaps is not devastating, we would rather use a 1248 more secure channel binding mechanism. Such a mechanism could 1249 include an updated tls-unique value generation like the tls-unique- 1250 prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter 1251 [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of 1252 [RFC8446]) value in place of the tls-unique value in the CSR. Such 1253 mechanism has not been standardized yet. Adopting a channel binding 1254 value generated from an exporter would break backwards compatibility 1255 for an RA that proxies through to a classic EST server. Thus, in 1256 this specification we still depend on the tls-unique mechanism 1257 defined in [RFC5929], especially since a 3SHAKE attack does not 1258 expose messages exchanged with EST-coaps. 1260 Interpreters of ASN.1 structures should be aware of the use of 1261 invalid ASN.1 length fields and should take appropriate measures to 1262 guard against buffer overflows, stack overruns in particular, and 1263 malicious content in general. 1265 10.2. HTTPS-CoAPS Registrar considerations 1267 The Registrar proposed in Section 6 must be deployed with care, and 1268 only when direct client-server connections are not possible. When 1269 PoP linking is used the Registrar terminating the DTLS connection 1270 establishes a new TLS connection with the upstream CA. Thus, it is 1271 impossible for PoP linking to be enforced end-to-end for the EST 1272 transaction. The EST server could be configured to accept PoP 1273 linking information that does not match the current TLS session 1274 because the authenticated EST Registrar is assumed to have verified 1275 PoP linking downstream to the client. 1277 The introduction of an EST-coaps-to-HTTP Registrar assumes the client 1278 can authenticate the Registrar using its implicit or explicit TA 1279 database. It also assumes the Registrar has a trust relationship 1280 with the upstream EST server in order to act on behalf of the 1281 clients. When a client uses the Implicit TA database for certificate 1282 validation, it SHOULD confirm if the server is acting as an RA by the 1283 presence of the id-kp-cmcRA EKU [RFC6402] in the server certificate. 1285 In a server-side key generation case, if no end-to-end encryption is 1286 used, the Registrar may be able see the private key as it acts as a 1287 man-in-the-middle. Thus, the client puts its trust on the Registrar 1288 not exposing the private key. 1290 Clients that leverage server-side key generation without end-to-end 1291 encryption of the private key (Section 5.8) have no knowledge if the 1292 Registrar will be generating the private key and enrolling the 1293 certificates with the CA or if the CA will be responsible for 1294 generating the key. In such cases, the existence of a Registrar 1295 requires the client to put its trust on the registrar when it is 1296 generating the private key. 1298 11. Contributors 1300 Martin Furuhed contributed to the EST-coaps specification by 1301 providing feedback based on the Nexus EST over CoAPS server 1302 implementation that started in 2015. Sandeep Kumar kick-started this 1303 specification and was instrumental in drawing attention to the 1304 importance of the subject. 1306 12. Acknowledgements 1308 The authors are very grateful to Klaus Hartke for his detailed 1309 explanations on the use of Block with DTLS and his support for the 1310 Content-Format specification. The authors would like to thank Esko 1311 Dijk and Michael Verschoor for the valuable discussions that helped 1312 in shaping the solution. They would also like to thank Peter 1313 Panburana for his feedback on technical details of the solution. 1314 Constructive comments were received from Benjamin Kaduk, Eliot Lear, 1315 Jim Schaad, Hannes Tschofenig, Julien Vermillard, John Manuel, Oliver 1316 Pfaff, Pete Beal and Carsten Bormann. 1318 Interop tests were done by Oliver Pfaff, Thomas Werner, Oskar 1319 Camezind, Bjorn Elmers and Joel Hoglund. 1321 Robert Moskowitz provided code to create the examples. 1323 13. References 1325 13.1. Normative References 1327 [I-D.ietf-core-multipart-ct] 1328 Fossati, T., Hartke, K., and C. Bormann, "Multipart 1329 Content-Format for CoAP", draft-ietf-core-multipart-ct-04 1330 (work in progress), August 2019. 1332 [I-D.ietf-lamps-rfc5751-bis] 1333 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1334 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1335 Message Specification", draft-ietf-lamps-rfc5751-bis-12 1336 (work in progress), September 2018. 1338 [I-D.ietf-tls-dtls13] 1339 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1340 Datagram Transport Layer Security (DTLS) Protocol Version 1341 1.3", draft-ietf-tls-dtls13-34 (work in progress), 1342 November 2019. 1344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1345 Requirement Levels", BCP 14, RFC 2119, 1346 DOI 10.17487/RFC2119, March 1997, 1347 . 1349 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1350 Infrastructure Operational Protocols: FTP and HTTP", 1351 RFC 2585, DOI 10.17487/RFC2585, May 1999, 1352 . 1354 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1355 (TLS) Protocol Version 1.2", RFC 5246, 1356 DOI 10.17487/RFC5246, August 2008, 1357 . 1359 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1360 DOI 10.17487/RFC5958, August 2010, 1361 . 1363 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1364 DOI 10.17487/RFC5967, August 2010, 1365 . 1367 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1368 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1369 January 2012, . 1371 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1372 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1373 . 1375 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1376 "Enrollment over Secure Transport", RFC 7030, 1377 DOI 10.17487/RFC7030, October 2013, 1378 . 1380 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1381 Application Protocol (CoAP)", RFC 7252, 1382 DOI 10.17487/RFC7252, June 2014, 1383 . 1385 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1386 Security (TLS) / Datagram Transport Layer Security (DTLS) 1387 Profiles for the Internet of Things", RFC 7925, 1388 DOI 10.17487/RFC7925, July 2016, 1389 . 1391 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1392 the Constrained Application Protocol (CoAP)", RFC 7959, 1393 DOI 10.17487/RFC7959, August 2016, 1394 . 1396 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1397 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1398 the Constrained Application Protocol (CoAP)", RFC 8075, 1399 DOI 10.17487/RFC8075, February 2017, 1400 . 1402 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1403 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1404 May 2017, . 1406 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1407 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1408 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1409 DOI 10.17487/RFC8422, August 2018, 1410 . 1412 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1413 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1414 . 1416 13.2. Informative References 1418 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 1419 "Recommendations for Secure Use of Transport Layer 1420 Security (TLS) and Datagram Transport Layer Security 1421 (DTLS)", BCP 195, RFC 7525, May 2015, 1422 . 1424 [COREparams] 1425 "Constrained RESTful Environments (CoRE) Parameters", 1426 . 1429 [I-D.ietf-tls-dtls-connection-id] 1430 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1431 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1432 id-07 (work in progress), October 2019. 1434 [I-D.josefsson-sasl-tls-cb] 1435 Josefsson, S., "Channel Bindings for TLS based on the 1436 PRF", draft-josefsson-sasl-tls-cb-03 (work in progress), 1437 March 2015. 1439 [I-D.moskowitz-ecdsa-pki] 1440 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 1441 "Guide for building an ECC pki", draft-moskowitz-ecdsa- 1442 pki-07 (work in progress), August 2019. 1444 [ieee802.15.4] 1445 "IEEE Standard 802.15.4-2006", 2006. 1447 [ieee802.1ar] 1448 "IEEE 802.1AR Secure Device Identifier", December 2009. 1450 [PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys 1451 in Network Devices", USENIX Security Symposium 2012 ISBN 1452 978-931971-95-9, August 2012. 1454 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1455 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1456 Overview, Assumptions, Problem Statement, and Goals", 1457 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1458 . 1460 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1461 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1462 . 1464 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1465 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1466 March 2010, . 1468 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1469 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 1470 . 1472 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1473 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1474 . 1476 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1477 Constrained-Node Networks", RFC 7228, 1478 DOI 10.17487/RFC7228, May 2014, 1479 . 1481 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1482 Protocol (HTTP/1.1): Message Syntax and Routing", 1483 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1484 . 1486 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1487 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1488 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 1489 . 1491 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1492 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1493 . 1495 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1496 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1497 Session Hash and Extended Master Secret Extension", 1498 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1499 . 1501 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1502 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1503 2016, . 1505 [RSAfact] "Factoring RSA keys from certified smart cards: 1506 Coppersmith in the wild", Advances in Cryptology 1507 - ASIACRYPT 2013, August 2013. 1509 [tripleshake] 1510 "Triple Handshakes and Cookie Cutters: Breaking and Fixing 1511 Authentication over TLS", IEEE Security and Privacy ISBN 1512 978-1-4799-4686-0, May 2014. 1514 Appendix A. EST messages to EST-coaps 1516 This section shows similar examples to the ones presented in 1517 Appendix A of [RFC7030]. The payloads in the examples are the hex 1518 encoded binary, generated with 'xxd -p', of the PKI certificates 1519 created following [I-D.moskowitz-ecdsa-pki]. Hex is used for 1520 visualization purposes because a binary representation cannot be 1521 rendered well in text. The hexadecimal representations would not be 1522 transported in hex, but in binary. The payloads are shown 1523 unencrypted. In practice the message content would be transferred 1524 over an encrypted DTLS channel. 1526 The certificate responses included in the examples contain Content- 1527 Format 281 (application/pkcs7). If the client had requested Content- 1528 Format TBD287 (application/pkix-cert) by querying /est/skc, the 1529 server would respond with a single DER binary certificate in the 1530 multipart-core container. 1532 These examples assume a short resource path of "/est". Even though 1533 omitted from the examples for brevity, before making the EST-coaps 1534 requests, a client would learn about the server supported EST-coaps 1535 resources with a GET request for /.well-known/core?rt=ace.est* as 1536 explained in Section 5.1. 1538 The corresponding CoAP headers are only shown in Appendix A.1. 1539 Creating CoAP headers is assumed to be generally understood. 1541 The message content breakdown is presented in Appendix C. 1543 A.1. cacerts 1545 In EST-coaps, a cacerts message can be: 1547 GET example.com:9085/est/crts 1548 (Accept: 281) 1550 The corresponding CoAP header fields are shown below. The use of 1551 block and DTLS are worked out in Appendix B. 1553 Ver = 1 1554 T = 0 (CON) 1555 Code = 0x01 (0.01 is GET) 1556 Token = 0x9a (client generated) 1557 Options 1558 Option (Uri-Host) 1559 Option Delta = 0x3 (option# 3) 1560 Option Length = 0xB 1561 Option Value = "example.com" 1562 Option (Uri-Port) 1563 Option Delta = 0x4 (option# 3+4=7) 1564 Option Length = 0x2 1565 Option Value = 9085 1566 Option (Uri-Path) 1567 Option Delta = 0x4 (option# 7+4=11) 1568 Option Length = 0x3 1569 Option Value = "est" 1570 Option (Uri-Path) 1571 Option Delta = 0x0 (option# 11+0=11) 1572 Option Length = 0x4 1573 Option Value = "crts" 1574 Option (Accept) 1575 Option Delta = 0x6 (option# 11+6=17) 1576 Option Length = 0x2 1577 Option Value = 281 1578 Payload = [Empty] 1580 As specified in Section 5.10.1 of [RFC7252], the Uri-Host and Uri- 1581 Port Options can be omitted if they coincide with the transport 1582 protocol destination address and port respectively. 1584 A 2.05 Content response with a cert in EST-coaps will then be 1586 2.05 Content (Content-Format: 281) 1587 {payload with certificate in binary format} 1589 with CoAP fields 1590 Ver = 1 1591 T = 2 (ACK) 1592 Code = 0x45 (2.05 Content) 1593 Token = 0x9a (copied from request by server) 1594 Options 1595 Option (Content-Format) 1596 Option Delta = 0xC (option# 12) 1597 Option Length = 0x2 1598 Option Value = 281 1600 [ The hexadecimal representation below would NOT be transported 1601 in hex, but in binary. Hex is used because a binary representation 1602 cannot be rendered well in text. ] 1604 Payload = 1605 3082027a06092a864886f70d010702a082026b308202670201013100300b 1606 06092a864886f70d010701a082024d30820249308201efa0030201020208 1607 0b8bb0fe604f6a1e300a06082a8648ce3d0403023067310b300906035504 1608 0613025553310b300906035504080c024341310b300906035504070c024c 1609 4131143012060355040a0c0b4578616d706c6520496e6331163014060355 1610 040b0c0d63657274696669636174696f6e3110300e06035504030c07526f 1611 6f74204341301e170d3139303133313131323730335a170d333930313236 1612 3131323730335a3067310b3009060355040613025553310b300906035504 1613 080c024341310b300906035504070c024c4131143012060355040a0c0b45 1614 78616d706c6520496e6331163014060355040b0c0d636572746966696361 1615 74696f6e3110300e06035504030c07526f6f742043413059301306072a86 1616 48ce3d020106082a8648ce3d030107034200040c1b1e82ba8cc72680973f 1617 97edb8a0c72ab0d405f05d4fe29b997a14ccce89008313d09666b6ce375c 1618 595fcc8e37f8e4354497011be90e56794bd91ad951ab45a3818430818130 1619 1d0603551d0e041604141df1208944d77b5f1d9dcb51ee244a523f3ef5de 1620 301f0603551d230418301680141df1208944d77b5f1d9dcb51ee244a523f 1621 3ef5de300f0603551d130101ff040530030101ff300e0603551d0f0101ff 1622 040403020106301e0603551d110417301581136365727469667940657861 1623 6d706c652e636f6d300a06082a8648ce3d040302034800304502202b891d 1624 d411d07a6d6f621947635ba4c43165296b3f633726f02e51ecf464bd4002 1625 2100b4be8a80d08675f041fbc719acf3b39dedc85dc92b3035868cb2daa8 1626 f05db196a1003100 1628 The breakdown of the payload is shown in Appendix C.1. 1630 A.2. enroll / reenroll 1632 During the (re-)enroll exchange the EST-coaps client uses a CSR 1633 (Content-Format 286) request in the POST request payload. The Accept 1634 option tells the server that the client is expecting Content-Format 1635 281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR 1636 contains a ChallengePassword which is used for PoP linking 1637 (Section 4). 1639 POST [2001:db8::2:321]:61616/est/sen 1640 (Token: 0x45) 1641 (Accept: 281) 1642 (Content-Format: 286) 1644 [ The hexadecimal representation below would NOT be transported 1645 in hex, but in binary. Hex is used because a binary representation 1646 cannot be rendered well in text. ] 1648 3082018b30820131020100305c310b3009060355040613025553310b3009 1649 06035504080c024341310b300906035504070c024c413114301206035504 1650 0a0c0b6578616d706c6520496e63310c300a060355040b0c03496f54310f 1651 300d060355040513065774313233343059301306072a8648ce3d02010608 1652 2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f 1653 028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75 1654 f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109 1655 0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e 1656 7634332323403d204e787e60303b06092a864886f70d01090e312e302c30 1657 2a0603551d1104233021a01f06082b06010505070804a013301106092b06 1658 010401b43b0a01040401020304300a06082a8648ce3d0403020348003045 1659 02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab 1660 ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc 1661 1135a1e84eed754377 1663 After verification of the CSR by the server, a 2.04 Changed response 1664 with the issued certificate will be returned to the client. 1666 2.04 Changed 1667 (Token: 0x45) 1668 (Content-Format: 281) 1670 [ The hexadecimal representation below would NOT be transported 1671 in hex, but in binary. Hex is used because a binary representation 1672 cannot be rendered well in text. ] 1674 3082026e06092a864886f70d010702a082025f3082025b0201013100300b 1675 06092a864886f70d010701a08202413082023d308201e2a0030201020208 1676 7e7661d7b54e4632300a06082a8648ce3d040302305d310b300906035504 1677 0613025553310b300906035504080c02434131143012060355040a0c0b45 1678 78616d706c6520496e6331163014060355040b0c0d636572746966696361 1679 74696f6e3113301106035504030c0a3830322e3141522043413020170d31 1680 39303133313131323931365a180f39393939313233313233353935395a30 1681 5c310b3009060355040613025553310b300906035504080c024341310b30 1682 0906035504070c024c4131143012060355040a0c0b6578616d706c652049 1683 6e63310c300a060355040b0c03496f54310f300d06035504051306577431 1684 3233343059301306072a8648ce3d020106082a8648ce3d03010703420004 1685 c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50c 1686 ff958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b56 1687 38e59fd9a3818a30818730090603551d1304023000301d0603551d0e0416 1688 041496600d8716bf7fd0e752d0ac760777ad665d02a0301f0603551d2304 1689 183016801468d16551f951bfc82a431d0d9f08bc2d205b1160300e060355 1690 1d0f0101ff0404030205a0302a0603551d1104233021a01f06082b060105 1691 05070804a013301106092b06010401b43b0a01040401020304300a06082a 1692 8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94 1693 91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d 1694 832a4d336a08ad67df20f1506421188a0ade6d349236a1003100 1696 The breakdown of the request and response is shown in Appendix C.2. 1698 A.3. serverkeygen 1700 In a serverkeygen exchange the CoAP POST request looks like 1701 POST 192.0.2.1:8085/est/skg 1702 (Token: 0xa5) 1703 (Accept: 62) 1704 (Content-Format: 286) 1706 [ The hexadecimal representation below would NOT be transported 1707 in hex, but in binary. Hex is used because a binary representation 1708 cannot be rendered well in text. ] 1710 3081d03078020100301631143012060355040a0c0b736b67206578616d70 1711 6c653059301306072a8648ce3d020106082a8648ce3d03010703420004c8 1712 b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50cff 1713 958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b5638 1714 e59fd9a000300a06082a8648ce3d040302034800304502207c553981b1fe 1715 349249d8a3f50a0346336b7dfaa099cf74e1ec7a37a0a760485902210084 1716 79295398774b2ff8e7e82abb0c17eaef344a5088fa69fd63ee611850c34b 1717 0a 1719 The response would follow [I-D.ietf-core-multipart-ct] and could look 1720 like 1721 2.04 Changed 1722 (Token: 0xa5) 1723 (Content-Format: 62) 1725 [ The hexadecimal representations below would NOT be transported 1726 in hex, but in binary. Hex is used because a binary representation 1727 cannot be rendered well in text. ] 1729 84 # array(4) 1730 19 011C # unsigned(284) 1731 58 8A # bytes(138) 1732 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 1733 6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7 1734 679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc 1735 494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95 1736 cf75f602f9152618f816a2b23b5638e59fd9 1737 19 0119 # unsigned(281) 1738 59 01D3 # bytes(467) 1739 308201cf06092a864886f70d010702a08201c0308201bc0201013100300b 1740 06092a864886f70d010701a08201a23082019e30820144a0030201020209 1741 00b3313e8f3fc9538e300a06082a8648ce3d040302301631143012060355 1742 040a0c0b736b67206578616d706c65301e170d3139303930343037343430 1743 335a170d3339303833303037343430335a301631143012060355040a0c0b 1744 736b67206578616d706c653059301306072a8648ce3d020106082a8648ce 1745 3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351 1746 cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75f602f915 1747 2618f816a2b23b5638e59fd9a37b307930090603551d1304023000302c06 1748 096086480186f842010d041f161d4f70656e53534c2047656e6572617465 1749 64204365727469666963617465301d0603551d0e0416041496600d8716bf 1750 7fd0e752d0ac760777ad665d02a0301f0603551d2304183016801496600d 1751 8716bf7fd0e752d0ac760777ad665d02a0300a06082a8648ce3d04030203 1752 48003045022100e95bfa25a08976652246f2d96143da39fce0dc4c9b26b9 1753 cce1f24164cc2b12b602201351fd8eea65764e3459d324e4345ff5b2a915 1754 38c04976111796b3698bf6379ca1003100 1756 The private key in the response above is without CMS EnvelopedData 1757 and has no additional encryption beyond DTLS (Section 5.8). 1759 The breakdown of the request and response is shown in Appendix C.3 1761 A.4. csrattrs 1763 Below is a csrattrs exchange 1764 REQ: 1765 GET example.com:61616/est/att 1767 RES: 1768 2.05 Content 1769 (Content-Format: 285) 1771 [ The hexadecimal representation below would NOT be transported 1772 in hex, but in binary. Hex is used because a binary representation 1773 cannot be rendered well in text. ] 1775 307c06072b06010101011630220603883701311b131950617273652053455 1776 420617320322e3939392e31206461746106092a864886f70d010907302c06 1777 0388370231250603883703060388370413195061727365205345542061732 1778 0322e3939392e32206461746106092b240303020801010b06096086480165 1779 03040202 1781 A 2.05 Content response should contain attributes which are relevant 1782 for the authenticated client. This example is copied from 1783 Section A.2 in [RFC7030], where the base64 representation is replaced 1784 with a hexadecimal representation of the equivalent binary format. 1785 The EST-coaps server returns attributes that the client can ignore if 1786 they are unknown to him. 1788 Appendix B. EST-coaps Block message examples 1790 Two examples are presented in this section: 1792 1. a cacerts exchange shows the use of Block2 and the block headers 1794 2. an enroll exchange shows the Block1 and Block2 size negotiation 1795 for request and response payloads. 1797 The payloads are shown unencrypted. In practice the message contents 1798 would be binary formatted and transferred over an encrypted DTLS 1799 tunnel. The corresponding CoAP headers are only shown in 1800 Appendix B.1. Creating CoAP headers is assumed to be generally 1801 known. 1803 B.1. cacerts 1805 This section provides a detailed example of the messages using DTLS 1806 and BLOCK option Block2. The example block length is taken as 64 1807 which gives an SZX value of 2. 1809 The following is an example of a cacerts exchange over DTLS. The 1810 content length of the cacerts response in appendix A.1 of [RFC7030] 1811 contains 639 bytes in binary in this example. The CoAP message adds 1812 around 10 bytes in this exmple, the DTLS record around 29 bytes. To 1813 avoid IP fragmentation, the CoAP Block Option is used and an MTU of 1814 127 is assumed to stay within one IEEE 802.15.4 packet. To stay 1815 below the MTU of 127, the payload is split in 9 packets with a 1816 payload of 64 bytes each, followed by a last tenth packet of 63 1817 bytes. The client sends an IPv6 packet containing a UDP datagram 1818 with DTLS record protection that encapsulates a CoAP request 10 times 1819 (one fragment of the request per block). The server returns an IPv6 1820 packet containing a UDP datagram with the DTLS record that 1821 encapsulates the CoAP response. The CoAP request-response exchange 1822 with block option is shown below. Block Option is shown in a 1823 decomposed way (block-option:NUM/M/size) indicating the kind of Block 1824 Option (2 in this case) followed by a colon, and then the block 1825 number (NUM), the more bit (M = 0 in Block2 response means it is last 1826 block), and block size with exponent (2**(SZX+4)) separated by 1827 slashes. The Length 64 is used with SZX=2. The CoAP Request is sent 1828 confirmable (CON) and the Content-Format of the response, even though 1829 not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). 1830 The transfer of the 10 blocks with partially filled block NUM=9 is 1831 shown below 1833 GET example.com:9085/est/crts (2:0/0/64) --> 1834 <-- (2:0/1/64) 2.05 Content 1835 GET example.com:9085/est/crts (2:1/0/64) --> 1836 <-- (2:1/1/64) 2.05 Content 1837 | 1838 | 1839 | 1840 GET example.com:9085/est/crts (2:9/0/64) --> 1841 <-- (2:9/0/64) 2.05 Content 1843 The header of the GET request looks like 1844 Ver = 1 1845 T = 0 (CON) 1846 Code = 0x01 (0.1 GET) 1847 Token = 0x9a (client generated) 1848 Options 1849 Option (Uri-Host) 1850 Option Delta = 0x3 (option# 3) 1851 Option Length = 0xB 1852 Option Value = "example.com" 1853 Option (Uri-Port) 1854 Option Delta = 0x4 (option# 3+4=7) 1855 Option Length = 0x2 1856 Option Value = 9085 1857 Option (Uri-Path) 1858 Option Delta = 0x4 (option# 7+4=11) 1859 Option Length = 0x3 1860 Option Value = "est" 1861 Option (Uri-Path)Uri-Path) 1862 Option Delta = 0x0 (option# 11+0=11) 1863 Option Length = 0x4 1864 Option Value = "crts" 1865 Option (Accept) 1866 Option Delta = 0x6 (option# 11+6=17) 1867 Option Length = 0x2 1868 Option Value = 281 1869 Payload = [Empty] 1871 The Uri-Host and Uri-Port Options can be omitted if they coincide 1872 with the transport protocol destination address and port 1873 respectively. Explicit Uri-Host and Uri-Port Options are typically 1874 used when an endpoint hosts multiple virtual servers and uses the 1875 Options to route the requests accordingly. 1877 For further detailing the CoAP headers, the first two and the last 1878 blocks are written out below. The header of the first Block2 1879 response looks like 1880 Ver = 1 1881 T = 2 (ACK) 1882 Code = 0x45 (2.05 Content) 1883 Token = 0x9a (copied from request by server) 1884 Options 1885 Option 1886 Option Delta = 0xC (option# 12 Content-Format) 1887 Option Length = 0x2 1888 Option Value = 281 1889 Option 1890 Option Delta = 0xB (option# 12+11=23 Block2) 1891 Option Length = 0x1 1892 Option Value = 0x0A (block#=0, M=1, SZX=2) 1894 [ The hexadecimal representation below would NOT be transported 1895 in hex, but in binary. Hex is used because a binary representation 1896 cannot be rendered well in text. ] 1898 Payload = 1899 3082027b06092a864886f70d010702a082026c308202680201013100300b 1900 06092a864886f70d010701a082024e3082024a308201f0a0030201020209 1901 009189bc 1903 The second Block2: 1905 Ver = 1 1906 T = 2 (means ACK) 1907 Code = 0x45 (2.05 Content) 1908 Token = 0x9a (copied from request by server) 1909 Options 1910 Option 1911 Option Delta = 0xC (option# 12 Content-Format) 1912 Option Length = 0x2 1913 Option Value = 281 1914 Option 1915 Option Delta = 0xB (option 12+11=23 Block2) 1916 Option Length = 0x1 1917 Option Value = 0x1A (block#=1, M=1, SZX=2) 1919 [ The hexadecimal representation below would NOT be transported 1920 in hex, but in binary. Hex is used because a binary representation 1921 cannot be rendered well in text. ] 1923 Payload = 1924 df9c99244b300a06082a8648ce3d0403023067310b300906035504061302 1925 5553310b300906035504080c024341310b300906035504070c024c413114 1926 30120603 1927 The 10th and final Block2: 1929 Ver = 1 1930 T = 2 (means ACK) 1931 Code = 0x45 (2.05 Content) 1932 Token = 0x9a (copied from request by server) 1933 Options 1934 Option 1935 Option Delta = 0xC (option# 12 Content-Format) 1936 Option Length = 0x2 1937 Option Value = 281 1938 Option 1939 Option Delta = 0xB (option# 12+11=23 Block2 ) 1940 Option Length = 0x1 1941 Option Value = 0x92 (block#=9, M=0, SZX=2) 1943 [ The hexadecimal representation below would NOT be transported 1944 in hex, but in binary. Hex is used because a binary representation 1945 cannot be rendered well in text. ] 1947 Payload = 1948 2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a 1949 e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1 1950 003100 1952 B.2. enroll / reenroll 1954 In this example, the requested Block2 size of 256 bytes, required by 1955 the client, is transferred to the server in the very first request 1956 message. The block size 256=(2**(SZX+4)) which gives SZX=4. The 1957 notation for block numbering is the same as in Appendix B.1. The 1958 header fields and the payload are omitted for brevity. 1960 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> 1962 <-- (ACK) (1:0/1/256) (2.31 Continue) 1963 POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> 1964 <-- (ACK) (1:1/1/256) (2.31 Continue) 1965 . 1966 . 1967 . 1968 POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR(frag# N1+1)}--> 1969 | 1970 ...........Immediate response ......... 1971 | 1972 <-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp (frag# 1)} 1973 POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> 1974 <-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp (frag# 2)} 1975 . 1976 . 1977 . 1978 POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) --> 1979 <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} 1981 Figure 5: EST-COAP enrollment with multiple blocks 1983 N1+1 blocks have been transferred from client to the server and N2+1 1984 blocks have been transferred from server to client. 1986 Appendix C. Message content breakdown 1988 This appendix presents the breakdown of the hexadecimal dumps of the 1989 binary payloads shown in Appendix A. 1991 C.1. cacerts 1993 The breakdown of cacerts response containing one root CA certificate 1994 is 1995 Certificate: 1996 Data: 1997 Version: 3 (0x2) 1998 Serial Number: 831953162763987486 (0xb8bb0fe604f6a1e) 1999 Signature Algorithm: ecdsa-with-SHA256 2000 Issuer: C=US, ST=CA, L=LA, O=Example Inc, 2001 OU=certification, CN=Root CA 2002 Validity 2003 Not Before: Jan 31 11:27:03 2019 GMT 2004 Not After : Jan 26 11:27:03 2039 GMT 2005 Subject: C=US, ST=CA, L=LA, O=Example Inc, 2006 OU=certification, CN=Root CA 2007 Subject Public Key Info: 2008 Public Key Algorithm: id-ecPublicKey 2009 Public-Key: (256 bit) 2010 pub: 2011 04:0c:1b:1e:82:ba:8c:c7:26:80:97:3f:97:ed:b8: 2012 a0:c7:2a:b0:d4:05:f0:5d:4f:e2:9b:99:7a:14:cc: 2013 ce:89:00:83:13:d0:96:66:b6:ce:37:5c:59:5f:cc: 2014 8e:37:f8:e4:35:44:97:01:1b:e9:0e:56:79:4b:d9: 2015 1a:d9:51:ab:45 2016 ASN1 OID: prime256v1 2017 NIST CURVE: P-256 2018 X509v3 extensions: 2019 X509v3 Subject Key Identifier: 2020 1D:F1:20:89:44:D7:7B:5F:1D:9D:CB:51:EE:24:4A:52:3F:3E:F5:DE 2021 X509v3 Authority Key Identifier: 2022 keyid: 2023 1D:F1:20:89:44:D7:7B:5F:1D:9D:CB:51:EE:24:4A:52:3F:3E:F5:DE 2025 X509v3 Basic Constraints: critical 2026 CA:TRUE 2027 X509v3 Key Usage: critical 2028 Certificate Sign, CRL Sign 2029 X509v3 Subject Alternative Name: 2030 email:certify@example.com 2031 Signature Algorithm: ecdsa-with-SHA256 2032 30:45:02:20:2b:89:1d:d4:11:d0:7a:6d:6f:62:19:47:63:5b: 2033 a4:c4:31:65:29:6b:3f:63:37:26:f0:2e:51:ec:f4:64:bd:40: 2034 02:21:00:b4:be:8a:80:d0:86:75:f0:41:fb:c7:19:ac:f3:b3: 2035 9d:ed:c8:5d:c9:2b:30:35:86:8c:b2:da:a8:f0:5d:b1:96 2037 C.2. enroll / reenroll 2039 The breakdown of the enrollment request is 2040 Certificate Request: 2041 Data: 2042 Version: 0 (0x0) 2043 Subject: C=US, ST=CA, L=LA, O=example Inc, 2044 OU=IoT/serialNumber=Wt1234 2045 Subject Public Key Info: 2046 Public Key Algorithm: id-ecPublicKey 2047 Public-Key: (256 bit) 2048 pub: 2049 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 2050 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 2051 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 2052 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 2053 56:38:e5:9f:d9 2054 ASN1 OID: prime256v1 2055 NIST CURVE: P-256 2056 Attributes: 2057 challengePassword: <256-bit PoP linking value> 2058 Requested Extensions: 2059 X509v3 Subject Alternative Name: 2060 othername: 2061 Signature Algorithm: ecdsa-with-SHA256 2062 30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd: 2063 1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38: 2064 92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b: 2065 c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77 2067 The CSR contains a ChallengePassword which is used for PoP linking 2068 (Section 4). The CSR also contains an id-on-hardwareModuleName 2069 hardware identifier to customize the returned certificate to the 2070 requesting device (See [RFC7299] and [I-D.moskowitz-ecdsa-pki]). 2072 The breakdown of the issued certificate is 2073 Certificate: 2074 Data: 2075 Version: 3 (0x2) 2076 Serial Number: 9112578475118446130 (0x7e7661d7b54e4632) 2077 Signature Algorithm: ecdsa-with-SHA256 2078 Issuer: C=US, ST=CA, O=Example Inc, 2079 OU=certification, CN=802.1AR CA 2080 Validity 2081 Not Before: Jan 31 11:29:16 2019 GMT 2082 Not After : Dec 31 23:59:59 9999 GMT 2083 Subject: C=US, ST=CA, L=LA, O=example Inc, 2084 OU=IoT/serialNumber=Wt1234 2085 Subject Public Key Info: 2086 Public Key Algorithm: id-ecPublicKey 2087 Public-Key: (256 bit) 2088 pub: 2089 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 2090 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 2091 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 2092 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 2093 56:38:e5:9f:d9 2094 ASN1 OID: prime256v1 2095 NIST CURVE: P-256 2096 X509v3 extensions: 2097 X509v3 Basic Constraints: 2098 CA:FALSE 2099 X509v3 Subject Key Identifier: 2100 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 2101 X509v3 Authority Key Identifier: 2102 keyid: 2103 68:D1:65:51:F9:51:BF:C8:2A:43:1D:0D:9F:08:BC:2D:20:5B:11:60 2105 X509v3 Key Usage: critical 2106 Digital Signature, Key Encipherment 2107 X509v3 Subject Alternative Name: 2108 othername: 2109 Signature Algorithm: ecdsa-with-SHA256 2110 30:46:02:21:00:c0:d8:19:96:d2:50:7d:69:3f:3c:48:ea:a5: 2111 ee:94:91:bd:a6:db:21:40:99:d9:81:17:c6:3b:36:13:74:cd: 2112 86:02:21:00:a7:74:98:9f:4c:32:1a:5c:f2:5d:83:2a:4d:33: 2113 6a:08:ad:67:df:20:f1:50:64:21:18:8a:0a:de:6d:34:92:36 2115 C.3. serverkeygen 2117 The following is the breakdown of the server-side key generation 2118 request. 2120 Certificate Request: 2121 Data: 2122 Version: 0 (0x0) 2123 Subject: O=skg example 2124 Subject Public Key Info: 2125 Public Key Algorithm: id-ecPublicKey 2126 Public-Key: (256 bit) 2127 pub: 2128 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 2129 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 2130 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 2131 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 2132 56:38:e5:9f:d9 2133 ASN1 OID: prime256v1 2134 NIST CURVE: P-256 2135 Attributes: 2136 a0:00 2137 Signature Algorithm: ecdsa-with-SHA256 2138 30:45:02:20:7c:55:39:81:b1:fe:34:92:49:d8:a3:f5:0a:03: 2139 46:33:6b:7d:fa:a0:99:cf:74:e1:ec:7a:37:a0:a7:60:48:59: 2140 02:21:00:84:79:29:53:98:77:4b:2f:f8:e7:e8:2a:bb:0c:17: 2141 ea:ef:34:4a:50:88:fa:69:fd:63:ee:61:18:50:c3:4b:0a 2143 Following is the breakdown of the private key content of the server- 2144 side key generation response. 2146 Private-Key: (256 bit) 2147 priv: 2148 61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e: 2149 6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f: 2150 0c:37 2151 pub: 2152 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 2153 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 2154 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 2155 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 2156 56:38:e5:9f:d9 2157 ASN1 OID: prime256v1 2158 NIST CURVE: P-256 2160 The following is the breakdown of the certificate in the server-side 2161 key generation response payload. 2163 Certificate: 2164 Data: 2165 Version: 3 (0x2) 2166 Serial Number: 2167 b3:31:3e:8f:3f:c9:53:8e 2168 Signature Algorithm: ecdsa-with-SHA256 2169 Issuer: O=skg example 2170 Validity 2171 Not Before: Sep 4 07:44:03 2019 GMT 2172 Not After : Aug 30 07:44:03 2039 GMT 2173 Subject: O=skg example 2174 Subject Public Key Info: 2175 Public Key Algorithm: id-ecPublicKey 2176 Public-Key: (256 bit) 2177 pub: 2178 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 2179 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 2180 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 2181 be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 2182 56:38:e5:9f:d9 2183 ASN1 OID: prime256v1 2184 NIST CURVE: P-256 2185 X509v3 extensions: 2186 X509v3 Basic Constraints: 2187 CA:FALSE 2188 Netscape Comment: 2189 OpenSSL Generated Certificate 2190 X509v3 Subject Key Identifier: 2191 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 2192 X509v3 Authority Key Identifier: 2193 keyid: 2194 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 2196 Signature Algorithm: ecdsa-with-SHA256 2197 30:45:02:21:00:e9:5b:fa:25:a0:89:76:65:22:46:f2:d9:61: 2198 43:da:39:fc:e0:dc:4c:9b:26:b9:cc:e1:f2:41:64:cc:2b:12: 2199 b6:02:20:13:51:fd:8e:ea:65:76:4e:34:59:d3:24:e4:34:5f: 2200 f5:b2:a9:15:38:c0:49:76:11:17:96:b3:69:8b:f6:37:9c 2202 Authors' Addresses 2204 Peter van der Stok 2205 Consultant 2207 Email: consultancy@vanderstok.org 2208 Panos Kampanakis 2209 Cisco Systems 2211 Email: pkampana@cisco.com 2213 Michael C. Richardson 2214 Sandelman Software Works 2216 Email: mcr+ietf@sandelman.ca 2217 URI: http://www.sandelman.ca/ 2219 Shahid Raza 2220 RISE SICS 2221 Isafjordsgatan 22 2222 Kista, Stockholm 16440 2223 SE 2225 Email: shahid@sics.se