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