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