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