idnits 2.17.1 draft-ietf-anima-constrained-voucher-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ace-coap-est], [RFC8366]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 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 == Line 458 has weird spacing: '...ndatory false...' == Line 462 has weird spacing: '...ndatory false...' == Line 710 has weird spacing: '...ndatory false...' == Line 714 has weird spacing: '...ndatory false...' == Line 1558 has weird spacing: '...openssl x509 ...' == (2 more instances...) -- The document date (November 02, 2020) is 1264 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 953, but not defined == Missing Reference: 'This RFC' is mentioned on line 1024, but not defined == Missing Reference: 'Empty' is mentioned on line 1182, but not defined == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-44 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-14 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-13 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-01 ** Downref: Normative reference to an Informational draft: draft-selander-ace-ake-authz (ref. 'I-D.selander-ace-ake-authz') ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: May 6, 2021 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 November 02, 2020 10 Constrained Voucher Artifacts for Bootstrapping Protocols 11 draft-ietf-anima-constrained-voucher-09 13 Abstract 15 This document defines a strategy to securely assign a pledge to an 16 owner, using an artifact signed, directly or indirectly, by the 17 pledge's manufacturer. This artifact is known as a "voucher". 19 This document builds upon the work in [RFC8366], encoding the 20 resulting artifact in CBOR. Use with two signature technologies are 21 described. 23 Additionally, this document explains how constrained vouchers may be 24 transported as an extension to the [I-D.ietf-ace-coap-est] protocol. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 6, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 64 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 7 67 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7 68 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 8 69 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 9 70 6.1.4. Example voucher request artifact . . . . . . . . . . 13 71 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 13 72 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 14 73 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 14 74 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 15 75 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 17 76 6.3. Signing voucher and voucher-request artifacts . . . . . . 18 77 6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 18 78 6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 19 79 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 20 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 20 82 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 20 83 8.3. Test Domain Certificate Validity when Signing . . . . . . 20 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 20 86 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 21 87 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 21 88 9.4. The RFC SID range assignment sub-registry . . . . . . . . 21 89 9.5. The SMI Security for S/MIME CMS Content Type Registry . . 22 90 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 22 91 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 22 92 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 22 93 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 23 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 98 12.2. Informative References . . . . . . . . . . . . . . . . . 26 99 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 26 100 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 26 101 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 28 102 Appendix B. CMS signed messages . . . . . . . . . . . . . . . . 28 103 B.1. signed requestvoucher . . . . . . . . . . . . . . . . . . 28 104 B.2. requestauditing . . . . . . . . . . . . . . . . . . . . . 30 105 B.3. CMS signed voucher-request example . . . . . . . . . . . 31 106 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 34 107 C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 38 108 C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 38 109 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 38 110 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 39 111 C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 39 112 C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 39 113 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 41 114 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 43 115 C.3. COSE signed voucher request from pledge to Registrar . . 45 116 C.4. COSE signed voucher request from Registrar to MASA . . . 47 117 C.5. COSE signed voucher from MASA to Pledge via Registrar . . 49 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 120 1. Introduction 122 Enrollment of new nodes into constrained networks with constrained 123 nodes present unique challenges. 125 There are bandwidth and code space issues to contend. A solution 126 such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in 127 terms of code space or bandwidth required. 129 This document defines a constrained version of [RFC8366]. Rather 130 than serializing the YANG definition in JSON, it is serialized into 131 CBOR ([RFC7049]). 133 This document follows a similar, but not identical structure as 134 [RFC8366] and supplements the brski part to [I-D.ietf-ace-coap-est]. 136 There are three constrained situations described in this document: 1. 137 CMS signed CBOR encoded vouchers transported using CoAP, protected by 138 DTLS (coaps). 2. COSE signed CBOR encoded vouchers transported using 139 CoAP, protected by EDHOC or DTLS. 3. COSE signed CBOR encoded 140 vouchers, integrated into the key exchange as described by 141 [I-D.selander-ace-ake-authz] 143 Additional sections have been added concerning: 145 1. Addition of voucher-request specification as defined in 146 [I-D.ietf-anima-bootstrapping-keyinfra], 148 2. Addition to [I-D.ietf-ace-coap-est] of voucher transport requests 149 over CoAP. 151 The CBOR definitions for this constrained voucher format are defined 152 using the mechanism describe in [I-D.ietf-core-yang-cbor] using the 153 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 154 convert YANG documents into an list of SID keys is still in its 155 infancy, the table of SID values presented here should be considered 156 normative rather than the output of the pyang tool. 158 Two methods of signing the resulting CBOR object are described in 159 this document: 161 1. One is CMS [RFC5652]. 163 2. The other is COSE_Sign1 [RFC8152] objects. 165 2. Terminology 167 The following terms are defined in [RFC8366], and are used 168 identically as in that document: artifact, imprint, domain, Join 169 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 170 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 172 3. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in 177 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 4. Survey of Voucher Types 182 [RFC8366] provides for vouchers that assert proximity, that 183 authenticate the registrar and that include different amounts of 184 anti-replay protection. 186 This document does not make any extensions to the types of vouchers. 188 Time based vouchers are included in this definition, but given that 189 constrained devices are extremely unlikely to have accurate time, 190 their use is very unlikely. Most users of these constrained vouchers 191 will be online and will use live nonces to provide anti-replay 192 protection. 194 [RFC8366] defined only the voucher artifact, and not the Voucher 195 Request artifact, which was defined in 196 [I-D.ietf-anima-bootstrapping-keyinfra]. 198 This document defines both a constrained voucher and a constrained 199 voucher-request. They are presented in the order "voucher-request", 200 followed by a "voucher" response as this is the time order that they 201 occur. 203 This document defines both CMS-signed voucher requests and responses, 204 and COSE signed voucher requests and responses. The use of CMS 205 signatures implies the use of PKIX format certificates. The pinned- 206 domain-cert present in a voucher, is the certificate of the 207 Registrar. 209 The constrained voucher and constrained voucher request MUST be 210 signed. 212 The use of the two signing formats permit the use of both PKIX format 213 certificates, and raw public keys (RPK). 215 When RPKs are used, the voucher produced by the MASA pins the raw 216 public key of the Registrar: the pinned-domain-subject-public-key- 217 info in a voucher, is the raw public key of the Registrar. This is 218 described in the YANG definition for the constrained voucher. 220 5. Discovery and URI 222 This section describes the BRSKI extensions to EST-coaps 223 [I-D.ietf-ace-coap-est] to transport the voucher between registrar, 224 proxy and pledge over CoAP. The extensions are targeted to low- 225 resource networks with small packets. Saving header space is 226 important and the EST-coaps URI is shorter than the EST URI. 228 The presence and location of (path to) the management data are 229 discovered by sending a GET request to "/.well-known/core" including 230 a resource type (RT) parameter with the value "ace.est" [RFC6690]. 231 Upon success, the return payload will contain the root resource of 232 the EST resources. It is up to the implementation to choose its root 233 resource; throughout this document the example root resource /est is 234 used. 236 The EST-coaps server URIs differ from the EST URI by replacing the 237 scheme https by coaps and by specifying shorter resource path names: 239 coaps://www.example.com/est/short-name 241 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 242 corresponding paths which are supported by EST. Table 1 provides the 243 mapping from the BRSKI extension URI path to the EST-coaps URI path. 245 +------------------+-----------+ 246 | BRSKI | EST-coaps | 247 +------------------+-----------+ 248 | /requestvoucher | /rv | 249 | | | 250 | /voucher_status | /vs | 251 | | | 252 | /enrollstatus | /es | 253 | | | 254 | /requestauditlog | /ra | 255 +------------------+-----------+ 257 Table 1: BRSKI path to EST-coaps path 259 /requestvoucher, /voucher_status and /enrollstatus are needed between 260 pledge and Registrar. 262 When discovering the root path for the EST resources, the server MAY 263 return the full resource paths and the used content types. This is 264 useful when multiple content types are specified for EST-coaps 265 server. For example, the following more complete response is 266 possible. 268 [ EDNOTE: spell out where voucher artifacts are used in BRSKI flows 269 since the APIs ] 271 [ EDNOTE: The /requestauditlog and /voucher-status are exchanged by 272 the Registrar and MASA. The JRC will likely talk to MASA over a 273 normal (not constrained) medium. Do we need /ra and /vs? Do we need 274 to remove them from the example too? Also what happens to the 275 voucher-request and response in this case? Is MASA supposed to 276 support contrained vouchers? ] 278 REQ: GET /.well-known/core?rt=brski* 280 RES: 2.05 Content 281 ; rt="brski" 282 ; rt="brski.rv";ct=TBD2 TBD3 283 ; rt="brski.vs";ct=50 60 284 ; rt="brski.es";ct=50 60 286 The return of the content-types allows the client to choose the most 287 appropriate one from multiple content types. 289 ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and 290 ct=TBD3 stands for Content-Format "application/voucher-cose+cbor". 292 Content-Formats TBD2 and TBD3 are defined in this document. 294 The Content-Format ("application/json") 50 MAY be supported. 295 Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be 296 supported by the Registrar. 298 The Pledge and MASA need to support one or more formats for the 299 voucher. The MASA needds to support whatever formats that the 300 pledge's produced by that manufacturer supports. 302 6. Artifacts 304 This section describes the abstract (tree) definition as explained in 305 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 306 level view of the contents of each artifact. 308 Then the assigned SID values are presented. These have been assigned 309 using the rules in [I-D.ietf-core-sid], with an allocation that was 310 made via the http://comi.space service. 312 6.1. Voucher Request artifact 314 6.1.1. Tree Diagram 316 The following diagram is largely a duplicate of the contents of 317 [RFC8366], with the addition of proximity-registrar-subject-public- 318 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 320 prior-signed-voucher-request is only used between the Registrar and 321 the MASA. proximity-registrar-subject-public-key-info replaces 322 proximity-registrar-cert for the extremely constrained cases. 324 module: ietf-constrained-voucher-request 326 grouping voucher-request-constrained-grouping 327 +-- voucher 328 +-- created-on? 329 | yang:date-and-time 330 +-- expires-on? 331 | yang:date-and-time 332 +-- assertion 333 | enumeration 334 +-- serial-number 335 | string 336 +-- idevid-issuer? 337 | binary 338 +-- pinned-domain-cert? 339 | binary 340 +-- domain-cert-revocation-checks? 341 | boolean 342 +-- nonce? 343 | binary 344 +-- last-renewal-date? 345 | yang:date-and-time 346 +-- proximity-registrar-subject-public-key-info? 347 | binary 348 +-- proximity-registrar-sha256-of-subject-public-key-info? 349 | binary 350 +-- proximity-registrar-cert? 351 | binary 352 +-- prior-signed-voucher-request? 353 binary 355 6.1.2. SID values 356 SID Assigned to 357 --------- -------------------------------------------------- 358 2501 data /ietf-constrained-voucher-request:voucher 359 2502 data .../assertion 360 2503 data .../created-on 361 2504 data .../domain-cert-revocation-checks 362 2505 data .../expires-on 363 2506 data .../idevid-issuer 364 2507 data .../last-renewal-date 365 2508 data /ietf-constrained-voucher-request:voucher/nonce 366 2509 data .../pinned-domain-cert 367 2510 data .../prior-signed-voucher-request 368 2511 data .../proximity-registrar-cert 369 2512 data mity-registrar-sha256-of-subject-public-key-info 370 2513 data .../proximity-registrar-subject-public-key-info 371 2514 data .../serial-number 373 WARNING, obsolete definitions 375 6.1.3. YANG Module 377 In the constrained-voucher-request YANG module, the voucher is 378 "augmented" within the "used" grouping statement such that one 379 continuous set of SID values is generated for the constrained- 380 voucher-request module name, all voucher attributes, and the 381 constrained-voucher-request attribute. Two attributes of the voucher 382 are "refined" to be optional. 384 file "ietf-constrained-voucher-request@2019-09-01.yang" 385 module ietf-constrained-voucher-request { 386 yang-version 1.1; 388 namespace 389 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 390 prefix "constrained"; 392 import ietf-restconf { 393 prefix rc; 394 description 395 "This import statement is only present to access 396 the yang-data extension defined in RFC 8040."; 397 reference "RFC 8040: RESTCONF Protocol"; 398 } 400 import ietf-voucher { 401 prefix "v"; 402 } 403 organization 404 "IETF ANIMA Working Group"; 406 contact 407 "WG Web: 408 WG List: 409 Author: Michael Richardson 410 411 Author: Peter van der Stok 412 413 Author: Panos Kampanakis 414 "; 415 description 416 "This module defines the format for a voucher request, 417 which is produced by a pledge to request a voucher. 418 The voucher-request is sent to the potential owner's 419 Registrar, which in turn sends the voucher request to 420 the manufacturer or delegate (MASA). 422 A voucher is then returned to the pledge, binding the 423 pledge to the owner. This is a constrained version of the 424 voucher-request present in 425 draft-ietf-anima-bootstrap-keyinfra.txt. 427 This version provides a very restricted subset appropriate 428 for very constrained devices. 429 In particular, it assumes that nonce-ful operation is 430 always required, that expiration dates are rather weak, as no 431 clocks can be assumed, and that the Registrar is identified 432 by a pinned Raw Public Key. 434 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 435 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 436 and 'OPTIONAL' in the module text are to be interpreted as 437 described in RFC 2119."; 439 revision "2019-09-01" { 440 description 441 "Initial version"; 442 reference 443 "RFC XXXX: Voucher Profile for Constrained Devices"; 444 } 446 rc:yang-data voucher-request-constrained-artifact { 447 // YANG data template for a voucher. 448 uses voucher-request-constrained-grouping; 449 } 450 // Grouping defined for future usage 451 grouping voucher-request-constrained-grouping { 452 description 453 "Grouping to allow reuse/extensions in future work."; 455 uses v:voucher-artifact-grouping { 457 refine voucher/created-on { 458 mandatory false; 459 } 461 refine voucher/pinned-domain-cert { 462 mandatory false; 463 } 465 augment "voucher" { 466 description "Base the constrained voucher-request upon the 467 regular one"; 469 leaf proximity-registrar-subject-public-key-info { 470 type binary; 471 description 472 "The proximity-registrar-subject-public-key-info replaces 473 the proximit-registrar-cert in constrained uses of 474 the voucher-request. 475 The proximity-registrar-subject-public-key-info is the 476 Raw Public Key of the Registrar. This field is encoded 477 as specified in RFC7250, section 3. 478 The ECDSA algorithm MUST be supported. 479 The EdDSA algorithm as specified in 480 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 481 Support for the DSA algorithm is not recommended. 482 Support for the RSA algorithm is MAY, but due to 483 size is discouraged."; 484 } 486 leaf proximity-registrar-sha256-of-subject-public-key-info { 487 type binary; 488 description 489 "The proximity-registrar-sha256-of-subject-public-key-info 490 is an alternative to 491 proximity-registrar-subject-public-key-info. 492 and pinned-domain-cert. In many cases the 493 public key of the domain has already been transmitted 494 during the key agreement protocol, and it is wasteful 495 to transmit the public key another two times. 496 The use of a hash of public key info, at 32-bytes for 497 sha256 is a significant savings compared to an RSA 498 public key, but is only a minor savings compared to 499 a 256-bit ECDSA public-key. 500 Algorithm agility is provided by extensions to this 501 specifications which define new leaf for other hash 502 types."; 503 } 505 leaf proximity-registrar-cert { 506 type binary; 507 description 508 "An X.509 v3 certificate structure as specified by 509 RFC 5280, 510 Section 4 encoded using the ASN.1 distinguished encoding 511 rules (DER), as specified in ITU-T X.690. 513 The first certificate in the Registrar TLS server 514 certificate_list sequence (see [RFC5246]) presented by 515 the Registrar to the Pledge. This MUST be populated in a 516 Pledge's voucher request if the proximity assertion is 517 populated."; 518 } 520 leaf prior-signed-voucher-request { 521 type binary; 522 description 523 "If it is necessary to change a voucher, or re-sign and 524 forward a voucher that was previously provided along a 525 protocol path, then the previously signed voucher 526 SHOULD be included in this field. 528 For example, a pledge might sign a proximity voucher, 529 which an intermediate registrar then re-signs to 530 make its own proximity assertion. This is a simple 531 mechanism for a chain of trusted parties to change a 532 voucher, while maintaining the prior signature 533 information. 535 The pledge MUST ignore all prior voucher information 536 when accepting a voucher for imprinting. Other 537 parties MAY examine the prior signed voucher 538 information for the purposes of policy decisions. 539 For example this information could be useful to a 540 MASA to determine that both pledge and registrar 541 agree on proximity assertions. The MASA SHOULD 542 remove all prior-signed-voucher-request information when 543 signing a voucher for imprinting so as to minimize the 544 final voucher size."; 546 } 547 } 548 } 549 } 550 } 551 553 6.1.4. Example voucher request artifact 555 Below is a CBOR serialization of the constrained-voucher-request is 556 shown in diagnostic CBOR notation. The enum value of the assertion 557 field is calculated to be zero by following the algorithm described 558 in section 9.6.4.2 of [RFC7950]. 560 { 561 2501: { 562 +2 : "2016-10-07T19:31:42Z", / SID= 2503, created-on / 563 +4 : "2016-10-21T19:31:42Z", / SID= 2505, expires-on / 564 +1 : 2, / SID= 2502, assertion / 565 / "proximity" / 566 +13: "JADA123456789", / SID= 2514, serial-number / 567 +5 : h'01020D0F', / SID= 2506, idevid-issuer / 568 +10: h'cert.der', / SID=2511, proximity-registrar-cert/ 569 +3 : true, / SID= 2504, domain-cert 570 -revocation-checks/ 571 +6 : "2017-10-07T19:31:42Z", / SID= 2507, last-renewal-date / 572 +12: h'key_info' / SID= 2513, proximity-registrar 573 -subject-public-key-info / 574 } 575 } 577 6.2. Voucher artifact 579 The voucher's primary purpose is to securely assign a pledge to an 580 owner. The voucher informs the pledge which entity it should 581 consider to be its owner. 583 This document defines a voucher that is a CBOR encoded instance of 584 the YANG module defined in Section 5.3 that has been signed with CMS 585 or with COSE. 587 6.2.1. Tree Diagram 589 The following diagram is largely a duplicate of the contents of 590 [RFC8366], with only the addition of pinned-domain-subject-public- 591 key-info. 593 module: ietf-constrained-voucher 595 grouping voucher-constrained-grouping 596 +-- voucher 597 +-- created-on? 598 | yang:date-and-time 599 +-- expires-on? 600 | yang:date-and-time 601 +-- assertion enumeration 602 +-- serial-number string 603 +-- idevid-issuer? binary 604 +-- pinned-domain-cert? binary 605 +-- domain-cert-revocation-checks? boolean 606 +-- nonce? binary 607 +-- last-renewal-date? 608 | yang:date-and-time 609 +-- pinned-domain-subject-public-key-info? binary 610 +-- pinned-sha256-of-subject-public-key-info? binary 612 6.2.2. SID values 614 SID Assigned to 615 --------- -------------------------------------------------- 616 2451 data /ietf-constrained-voucher:voucher 617 2452 data /ietf-constrained-voucher:voucher/assertion 618 2453 data /ietf-constrained-voucher:voucher/created-on 619 2454 data .../domain-cert-revocation-checks 620 2455 data /ietf-constrained-voucher:voucher/expires-on 621 2456 data /ietf-constrained-voucher:voucher/idevid-issuer 622 2457 data .../last-renewal-date 623 2458 data /ietf-constrained-voucher:voucher/nonce 624 2459 data .../pinned-domain-cert 625 2460 data .../pinned-domain-subject-public-key-info 626 2461 data .../pinned-sha256-of-subject-public-key-info 627 2462 data /ietf-constrained-voucher:voucher/serial-number 629 WARNING, obsolete definitions 631 6.2.3. YANG Module 633 In the constrained-voucher YANG module, the voucher is "augmented" 634 within the "used" grouping statement such that one continuous set of 635 SID values is generated for the constrained-voucher module name, all 636 voucher attributes, and the constrained-voucher attribute. Two 637 attributes of the voucher are "refined" to be optional. 639 file "ietf-constrained-voucher@2019-09-01.yang" 640 module ietf-constrained-voucher { 641 yang-version 1.1; 643 namespace 644 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 645 prefix "constrained"; 647 import ietf-restconf { 648 prefix rc; 649 description 650 "This import statement is only present to access 651 the yang-data extension defined in RFC 8040."; 652 reference "RFC 8040: RESTCONF Protocol"; 653 } 655 import ietf-voucher { 656 prefix "v"; 657 } 659 organization 660 "IETF ANIMA Working Group"; 662 contact 663 "WG Web: 664 WG List: 665 Author: Michael Richardson 666 667 Author: Peter van der Stok 668 669 Author: Panos Kampanakis 670 "; 671 description 672 "This module defines the format for a voucher, which is produced 673 by a pledge's manufacturer or delegate (MASA) to securely assign 674 one or more pledges to an 'owner', so that the pledges may 675 establis a secure connection to the owner's network 676 infrastructure. 678 This version provides a very restricted subset appropriate 679 for very constrained devices. 680 In particular, it assumes that nonce-ful operation is 681 always required, that expiration dates are rather weak, as no 682 clocks can be assumed, and that the Registrar is identified 683 by a pinned Raw Public Key. 685 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 686 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 687 and 'OPTIONAL' in the module text are to be interpreted as 688 described in RFC 2119."; 690 revision "2019-09-01" { 691 description 692 "Initial version"; 693 reference 694 "RFC XXXX: Voucher Profile for Constrained Devices"; 695 } 697 rc:yang-data voucher-constrained-artifact { 698 // YANG data template for a voucher. 699 uses voucher-constrained-grouping; 700 } 702 // Grouping defined for future usage 703 grouping voucher-constrained-grouping { 704 description 705 "Grouping to allow reuse/extensions in future work."; 707 uses v:voucher-artifact-grouping { 709 refine voucher/created-on { 710 mandatory false; 711 } 713 refine voucher/pinned-domain-cert { 714 mandatory false; 715 } 717 augment "voucher" { 718 description "Base the constrained voucher 719 upon the regular one"; 720 leaf pinned-domain-subject-public-key-info { 721 type binary; 722 description 723 "The pinned-domain-subject-public-key-info replaces the 724 pinned-domain-cert in constrained uses of 725 the voucher. The pinned-domain-subject-public-key-info 726 is the Raw Public Key of the Registrar. 728 This field is encoded as specified in RFC7250, 729 section 3. 730 The ECDSA algorithm MUST be supported. 731 The EdDSA algorithm as specified in 732 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 733 Support for the DSA algorithm is not recommended. 734 Support for the RSA algorithm is a MAY."; 735 } 737 leaf pinned-sha256-of-subject-public-key-info { 738 type binary; 739 description 740 "The pinned-hash-subject-public-key-info is a second 741 alternative to pinned-domain-cert. In many cases the 742 public key of the domain has already been transmitted 743 during the key agreement process, and it is wasteful 744 to transmit the public key another two times. 745 The use of a hash of public key info, at 32-bytes for 746 sha256 is a significant savings compared to an RSA 747 public key, but is only a minor savings compared to 748 a 256-bit ECDSA public-key. 749 Algorithm agility is provided by extensions to this 750 specifications which define new leaf for other hash types"; 751 } 752 } 753 } 754 } 755 } 756 758 6.2.4. Example voucher artifacts 760 Below a the CBOR serialization of the constrained-voucher is shown in 761 diagnostic CBOR notation. The enum value of the assertion field is 762 calculated to be zero by following the algorithm described in section 763 9.6.4.2 of [RFC7950]. 765 { 766 2451: { 767 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 768 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 769 +1 : 0, / SID = 2452, assertion / 770 / "verified" / 771 +11: "JADA123456789", / SID = 2462, serial-number / 772 +5 : h'01020D0F', / SID = 2456, idevid-issuer / 773 +8 : h'cert.der', / SID = 2459, pinned-domain-cert/ 774 +3 : true, / SID = 2454, domain-cert 775 -revocation-checks / 776 +6 : "2017-10-07T19:31:42Z", / SID = 2457, last-renewal-date / 777 +9 : h'key-info' / SID = 2460, pinned-domain 778 -subject-public-key-info / 779 } 780 } 782 The signing of the example is shown in Appendix B.3. 784 6.3. Signing voucher and voucher-request artifacts 786 6.3.1. CMS signing 788 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 789 voucher is much like the equivalent voucher defined in [RFC8366]. 791 A different eContentType of TBD1 is used to indicate that the 792 contents are in a different format than in [RFC8366]. The id-ct- 793 animaJSONVoucher allocated by [RFC8366] indicates a voucher and 794 voucher-request encoded in JSON, and the new value TBD1 indicates 795 that the voucher and voucher-request are encoded in CBOR. 797 The ContentInfo structure contains a payload consisting of the CBOR 798 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 799 creates a canonical ordering for the keys on the wire. This 800 canonical ordering is not important as there is no expectation that 801 the content will be reproduced during the validation process. 803 Normally the recipient is the pledge and the signer is the MASA. 805 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 806 unsigned voucher requests from the pledge to the JRC. In this 807 specification, voucher-request artifact is not signed from the pledge 808 to the registrar. [EDNOTE: Confirm that voucher requests do not need 809 to be signed ] From the JRC to the MASA, the voucher-request artifact 810 MUST be signed by the domain owner key which is requesting ownership. 812 The considerations of [RFC5652] section 5.1, concerning validating 813 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 815 The CMS structure SHOULD also contain all the certificates leading up 816 to and including the signer's trust anchor certificate known to the 817 recipient. The inclusion of the trust anchor is unusual in many 818 applications, but without it third parties can not accurately audit 819 the transaction. 821 The CMS structure MAY also contain revocation objects for any 822 intermediate certificate authorities (CAs) between the voucher-issuer 823 and the trust anchor known to the recipient. However, the use of 824 CRLs and other validity mechanisms is discouraged, as the pledge is 825 unlikely to be able to perform online checks, and is unlikely to have 826 a trusted clock source. As described below, the use of short-lived 827 vouchers and/or pledge provided nonce provides a freshness guarantee. 829 6.3.2. COSE signing 831 The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152]. 832 The CBOR object that carries the body, the signature, and the 833 information about the body and signature is called the COSE_Sign1 834 structure. It is used when only one signature is used on the body. 835 Support for ECDSA with sha256 (secp256k1 and prime256v1 curves) is 836 compulsory. 838 The supported COSE-sign1 object stucture is shown in Figure 1. 839 Support for EdDSA is encouraged. [EDNOTE: Expand and add a reference 840 why. ] 842 COSE_Sign1( 843 [ 844 h'A101382E', # { "alg": EC256K1 } 845 { 846 "kid" : h'789' # hash256(public key) 847 }, 848 h'123', #voucher-request binary content 849 h'456', #voucher-request binary public signature 850 ] 851 ) 853 Figure 1: cose-sign1 example 855 The [COSE-registry] specifies the integers that replace the strings 856 and the mnemonics in Figure 1. The value of the "kid" parameter is 857 an example value. Usually a hash of the public key is used to 858 idientify the public key. The public key and its hash are derived 859 from the relevant certificate (Pledge, Registrar or MASA 860 certificate). 862 In Appendix C a binary cose-sign1 object is shown based on the 863 voucher-request example of Section 6.1.4. 865 7. Design Considerations 867 The design considerations for the CBOR encoding of vouchers is much 868 the same as for [RFC8366]. 870 One key difference is that the names of the leaves in the YANG does 871 not have a material effect on the size of the resulting CBOR, as the 872 SID translation process assigns integers to the names. 874 8. Security Considerations 876 8.1. Clock Sensitivity 878 TBD. 880 8.2. Protect Voucher PKI in HSM 882 TBD. 884 8.3. Test Domain Certificate Validity when Signing 886 TBD. 888 9. IANA Considerations 890 9.1. Resource Type Registry 892 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 893 parameters" registry are specified below. These can be registered 894 either in the Expert Review range (0-255) or IETF Review range 895 (256-9999). 897 ace.rt.rv needs registration with IANA 898 ace.rt.vs needs registration with IANA 899 ace.rt.es needs registration with IANA 900 ace.rt.ra needs registration with IANA 902 9.2. The IETF XML Registry 904 This document registers two URIs in the IETF XML registry [RFC3688]. 905 Following the format in [RFC3688], the following registration is 906 requested: 908 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 909 Registrant Contact: The ANIMA WG of the IETF. 910 XML: N/A, the requested URI is an XML namespace. 912 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 913 Registrant Contact: The ANIMA WG of the IETF. 914 XML: N/A, the requested URI is an XML namespace. 916 9.3. The YANG Module Names Registry 918 This document registers two YANG modules in the YANG Module Names 919 registry [RFC6020]. Following the format defined in [RFC6020], the 920 the following registration is requested: 922 name: ietf-constrained-voucher 923 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 924 prefix: vch 925 reference: RFC XXXX 927 name: ietf-constrained-voucher-request 928 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 929 -voucher-request 930 prefix: vch 931 reference: RFC XXXX 933 9.4. The RFC SID range assignment sub-registry 935 ------------ ------ --------------------------- ------------ 936 Entry-point | Size | Module name | RFC Number 937 ------------ ------ --------------------------- ------------ 938 2450 50 ietf-constrained-voucher [ThisRFC] 939 2500 50 ietf-constrained-voucher [ThisRFC} 940 -request 941 ----------- ------ --------------------------- ------------ 943 Warning: These SID values are defined in [I-D.ietf-core-sid], not as 944 an Early Allocation. 946 9.5. The SMI Security for S/MIME CMS Content Type Registry 948 This document registers an OID in the "SMI Security for S/MIME CMS 949 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 951 Decimal Description References 952 ------- -------------------------------------- ---------- 953 46 id-ct-animaCBORVoucher [ThisRFC] 955 9.6. Media-Type Registry 957 This section registers the 'application/voucher-cms+cbor' media type 958 and the 'application/voucher-cose+cbor' in the "Media Types" 959 registry. These media types are used to indicate that the content is 960 a CBOR voucher either signed with a cms structure or a COSE_Sign1 961 structure [RFC8152]. 963 9.6.1. application/voucher-cms+cbor 965 Type name: application 966 Subtype name: voucher-cms+cbor 967 Required parameters: none 968 Optional parameters: none 969 Encoding considerations: CMS-signed CBOR vouchers are CBOR 970 encoded. 971 Security considerations: See Security Considerations, Section 972 Interoperability considerations: The format is designed to be 973 broadly interoperable. 974 Published specification: THIS RFC. 975 Applications that use this media type: ANIMA, 6tisch, and other 976 zero-touch imprinting systems 977 Additional information: 978 Magic number(s): None 979 File extension(s): .vch 980 Macintosh file type code(s): none 981 Person & email address to contact for further information: IETF 982 ANIMA WG 983 Intended usage: LIMITED 984 Restrictions on usage: NONE 985 Author: ANIMA WG 986 Change controller: IETF 987 Provisional registration? (standards tree only): NO 989 9.6.2. application/voucher-cose+cbor 990 Type name: application 991 Subtype name: voucher-cose+cbor 992 Required parameters: none 993 Optional parameters: cose-type 994 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 995 signed with one signer. 996 Security considerations: See Security Considerations, Section 997 Interoperability considerations: The format is designed to be 998 broadly interoperable. 999 Published specification: THIS RFC. 1000 Applications that use this media type: ANIMA, 6tisch, and other 1001 zero-touch imprinting systems 1002 Additional information: 1003 Magic number(s): None 1004 File extension(s): .vch 1005 Macintosh file type code(s): none 1006 Person & email address to contact for further information: IETF 1007 ANIMA WG 1008 Intended usage: LIMITED 1009 Restrictions on usage: NONE 1010 Author: ANIMA WG 1011 Change controller: IETF 1012 Provisional registration? (standards tree only): NO 1014 9.7. CoAP Content-Format Registry 1016 Additions to the sub-registry "CoAP Content-Formats", within the 1017 "CoRE Parameters" registry are needed for two media types. These can 1018 be registered either in the Expert Review range (0-255) or IETF 1019 Review range (256-9999). 1021 Media type mime type Encoding ID References 1022 ---------------------------- ----------- --------- ---- ---------- 1023 application/voucher-cms+cbor - - CBOR TBD2 [This RFC] 1024 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 1026 10. Acknowledgements 1028 We are very grateful to Jim Schaad for explaining COSE and CMS 1029 choices. Also thanks to Jim Schaad for correctinging earlier version 1030 of the COSE Sign1 objects. 1032 Michel Veillette did extensive work on pyang to extend it to support 1033 the SID allocation process, and this document was among the first 1034 users. 1036 We are grateful for the suggestions done by Esko Dijk. 1038 11. Changelog 1040 -08 Examples for cose_sign1 are completed and improved. 1042 -06 New SID values assigned; regenerated examples 1044 -04 voucher and request-voucher MUST be signed examples for signed 1045 request are added in appendix IANA SID registration is updated SID 1046 values in examples are aligned signed cms examples aligned with new 1047 SIDs 1049 -03 1051 Examples are inverted. 1053 -02 1055 Example of requestvoucher with unsigned appllication/cbor is added 1056 attributes of voucher "refined" to optional 1057 CBOR serialization of vouchers improved 1058 Discovery port numbers are specified 1060 -01 1062 application/json is optional, application/cbor is compulsory 1063 Cms and cose mediatypes are introduced 1065 12. References 1067 12.1. Normative References 1069 [I-D.ietf-ace-coap-est] 1070 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 1071 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 1072 est-18 (work in progress), January 2020. 1074 [I-D.ietf-anima-bootstrapping-keyinfra] 1075 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1076 and K. Watsen, "Bootstrapping Remote Secure Key 1077 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1078 keyinfra-44 (work in progress), September 2020. 1080 [I-D.ietf-core-sid] 1081 Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item 1082 iDentifier (YANG SID)", draft-ietf-core-sid-14 (work in 1083 progress), July 2020. 1085 [I-D.ietf-core-yang-cbor] 1086 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 1087 Data Modeled with YANG", draft-ietf-core-yang-cbor-13 1088 (work in progress), July 2020. 1090 [I-D.selander-ace-ake-authz] 1091 Selander, G., Mattsson, J., Vucinic, M., Richardson, M., 1092 and A. Schellenbaum, "Lightweight Authorization for 1093 Authenticated Key Exchange.", draft-selander-ace-ake- 1094 authz-01 (work in progress), March 2020. 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, 1098 DOI 10.17487/RFC2119, March 1997, 1099 . 1101 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1102 DOI 10.17487/RFC3688, January 2004, 1103 . 1105 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1106 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1107 . 1109 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1110 the Network Configuration Protocol (NETCONF)", RFC 6020, 1111 DOI 10.17487/RFC6020, October 2010, 1112 . 1114 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1115 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1116 October 2013, . 1118 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1119 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1120 . 1122 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1123 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1124 . 1126 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1127 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1128 May 2017, . 1130 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1131 "A Voucher Artifact for Bootstrapping Protocols", 1132 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1133 . 1135 12.2. Informative References 1137 [COSE-registry] 1138 IANA, ., "CBOR Object Signing and Encryption (COSE) 1139 registry", 2017, 1140 . 1142 [I-D.ietf-netmod-yang-tree-diagrams] 1143 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1144 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1145 February 2018. 1147 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1148 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1149 . 1151 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1152 "Enrollment over Secure Transport", RFC 7030, 1153 DOI 10.17487/RFC7030, October 2013, 1154 . 1156 Appendix A. EST messages to EST-coaps 1158 This section extends the examples from Appendix A of 1159 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1160 the enrollstatus example. 1162 A.1. enrollstatus 1164 A coaps enrollstatus message can be : 1166 GET coaps://[192.0.2.1:8085]/est/es 1168 The corresponding coap header fields are shown below. 1170 Ver = 1 1171 T = 0 (CON) 1172 Code = 0x01 (0.01 is GET) 1173 Options 1174 Option (Uri-Path) 1175 Option Delta = 0xb (option nr = 11) 1176 Option Length = 0x3 1177 Option Value = "est" 1178 Option (Uri-Path) 1179 Option Delta = 0x0 (option nr = 11) 1180 Option Length = 0x2 1181 Option Value = "es" 1182 Payload = [Empty] 1184 The Uri-Host and Uri-Port Options are omitted because they coincide 1185 with the transport protocol destination address and port 1186 respectively. 1188 A 2.05 Content response with an unsigned voucher status (ct=60) will 1189 then be: 1191 2.05 Content (Content-Format: application/cbor) 1193 With CoAP fields and payload: 1195 Ver=1 1196 T=2 (ACK) 1197 Code = 0x45 (2.05 Content) 1198 Options 1199 Option1 (Content-Format) 1200 Option Delta = 0xC (option nr 12) 1201 Option Length = 0x2 1202 Option Value = 60 (application/cbor) 1204 Payload (CBOR diagnostic) = 1205 { 1206 "version":"1", 1207 "Status": 1, / 1 = Success, 0 = Fail / 1208 "Reason":"Informative human readable message", 1209 "reason-context": "Additional information" 1210 } 1212 The binary payload is: 1214 A46776657273696F6E6131665374617475730166526561736F6E7822 1215 496E666F726D61746976652068756D616E207265616461626C65206D 1216 6573736167656e726561736F6E2D636F6E74657874 1217 764164646974696F6E616C20696E666F726D6174696F6E 1219 The binary payload disassembles to the above CBOR diagnostic code. 1221 A.2. voucher_status 1223 A coaps voucher_status message can be: 1225 GET coaps://[2001:db8::2:1]:61616]/est/vs 1227 A 2.05 Content response with a non signed CBOR voucher status (ct=60) 1228 will then be: 1230 2.05 Content (Content-Format: application/cbor) 1231 Payload = 1232 A46776657273696F6E6131665374617475730166526561736F6E7822 1233 496E666F726D61746976652068756D616E207265616461626C65206D 1234 6573736167656e726561736F6E2D636F6E74657874 1235 764164646974696F6E616C20696E666F726D6174696F6E 1237 Appendix B. CMS signed messages 1239 Signed request-voucher-request payloads are sent from pledge to 1240 Registrar, as explained in Section 5.2 of 1241 [I-D.ietf-anima-bootstrapping-keyinfra]. 1243 B.1. signed requestvoucher 1245 A CMS signed requestvoucher message from JRC to MASA is shown below. 1246 It would be CoAP POSTED to /est/rv. 1248 POST coaps://[2001:db8::2:1]:61616]/est/rv 1249 (Content-Format: application/voucher-cms+cbor) 1251 The payload would be in binary, but is presented in base64 in this 1252 document. 1254 MIIDugYJKoZIhvcNAQcCoIIDqzCCA6cCAQExDTALBglghkgBZQMEAgEwCwYJ 1255 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1256 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1257 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1258 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1259 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1260 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1261 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1262 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1263 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1264 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1265 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1266 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1267 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1268 3m00kjYxggE/MIIBOwIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1269 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1270 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1271 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1272 DTE5MDQwODEwNDgzNlowLwYJKoZIhvcNAQkEMSIEILEdCTOLs2Zy7w3LgvSZ 1273 XZEadz3LbznoFBs6FMFN91RaMAoGCCqGSM49BAMCBEcwRQIgASjDsIpr0tW/ 1274 n6dRHqvvqsqgZlHbtFnErUbWfhS0KD4CIQDDUEqc5wTmRGf0adEQVQzqmIgh 1275 MEgF10vqXv02gL1jLw== 1277 A 2.04 Changed response returning CBOR voucher signed with a cms 1278 structure(ct=TBD2) will then be: 1280 2.04 Changed (Content-Format: application/voucher-cms+cbor) 1282 MIIDuwYJKoZIhvcNAQcCoIIDrDCCA6gCAQExDTALBglghkgBZQMEAgEwCwYJ 1283 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1284 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1285 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1286 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1287 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1288 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1289 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1290 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1291 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1292 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1293 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1294 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1295 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1296 3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1297 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1298 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1299 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1300 DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he 1301 uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG 1302 kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX 1303 hlG/g+OgTUftYMJ32so= 1305 B.2. requestauditing 1307 A coaps requestauditing message contains the signed CBOR voucher : 1309 POST coaps://[2001:db8::2:1]:61616]/est/ra 1310 (Content-Format: application/voucher-cms+cbor) 1311 Payload = 1312 TO BE FILLED 1314 A 2.05 Content response returning a log of the voucher (ct=60) will 1315 then be: 1317 2.05 Content (Content-Format: application/cbor) 1318 Payload = 1319 { 1320 "version":"1", 1321 "events":[ 1322 { 1323 "date":"", 1324 "domainID":"", 1325 "nonce":"" 1326 "assertion":"" 1327 "truncated":"" 1328 }, 1329 { 1330 "date":"", 1331 "domainID":"", 1332 "nonce":"" 1333 "assertion":"" 1334 } 1335 ], 1336 "truncation": { 1337 "nonced duplicates": "", 1338 "nonceless duplicates": "", 1339 "arbitrary": "" 1340 } 1341 } 1343 [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary] 1345 B.3. CMS signed voucher-request example 1347 The voucher-request example, visualized in CBOR diagnostic notation 1348 in Section 6.1.4 is shown as a hexadecimal dump of the binary file. 1350 a11909c5a90274323031362d31302d30375431393a33313a34325a0474323031 1351 362d31302d32315431393a33313a34325a01020d6d4a414441313233343536 1352 373839054401020d0f0a4401020d0f03f50674323031372d31302d30375431 1353 393a33313a34325a0c4401020d0f 1355 The voucher-request example has been signed by using the WT1234 1356 certificate and key pair shown in Appendix C of 1357 [I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher- 1358 request leads to a binary signed voucher-request, shown with a 1359 hexadecimal representation shown in the payload of the request part 1360 of Appendix B.1 and Appendix B.2. 1362 The breakdown of the CMS signed binary voucher-request file is 1363 visualized below: 1365 CMS_ContentInfo: 1366 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1367 d.signedData: 1368 version: 1 1369 digestAlgorithms: 1370 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1371 parameter: 1372 encapContentInfo: 1373 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1374 eContent: 1375 certificates: 1376 d.certificate: 1377 cert_info: 1378 version: 2 1379 serialNumber: 9112578475118446130 1380 signature: 1381 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1382 parameter: 1383 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1384 CN=802.1AR CA 1385 validity: 1386 notBefore: Jan 31 11:29:16 2019 GMT 1387 notAfter: Dec 31 23:59:59 9999 GMT 1388 subject: C=US, ST=CA, L=LA, O=example Inc, 1389 OU=IoT/serialNumber=Wt1234 1390 key: 1391 algor: 1392 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1393 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1394 public_key: (0 unused bits) 1395 0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf 1396 000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15 1397 001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df 1398 002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8 1399 0038 - 16 a2 b2 3b 56 38 e5 9f-d9 1400 issuerUID: 1401 subjectUID: 1402 extensions: 1403 object: X509v3 Basic Constraints (2.5.29.19) 1404 critical: BOOL ABSENT 1405 value: 1406 0000 - 30 1407 0002 - 1409 object: X509v3 Subject Key Identifier (2.5.29.14) 1410 critical: BOOL ABSENT 1411 value: 1412 0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0 1413 000d - ac 76 07 77 ad 66 5d 02-a0 1415 object: X509v3 Authority Key Identifier (2.5.29.35) 1416 critical: BOOL ABSENT 1417 value: 1418 0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a 1419 000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60 1421 object: X509v3 Key Usage (2.5.29.15) 1422 critical: TRUE 1423 value: 1424 0000 - 03 02 05 a0 1426 object: X509v3 Subject Alternative Name (2.5.29.17) 1427 critical: BOOL ABSENT 1428 value: 1429 0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08 1430 000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4 1431 001a - 3b 0a 01 04 04 01 02 03-04 1432 sig_alg: 1433 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1434 parameter: 1435 signature: (0 unused bits) 1436 0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c 1437 000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17 1438 001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c 1439 002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20 1440 003c - f1 50 64 21 18 8a 0a de-6d 34 92 36 1441 crls: 1442 1443 signerInfos: 1444 version: 1 1445 d.issuerAndSerialNumber: 1446 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1447 CN=802.1AR CA 1448 serialNumber: 9112578475118446130 1449 digestAlgorithm: 1450 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1451 parameter: 1452 signedAttrs: 1453 object: contentType (1.2.840.113549.1.9.3) 1454 value.set: 1455 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1457 object: signingTime (1.2.840.113549.1.9.5) 1458 value.set: 1459 UTCTIME:Jul 3 08:53:30 2019 GMT 1461 object: messageDigest (1.2.840.113549.1.9.4) 1462 value.set: 1463 OCTET STRING: 1464 0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d 1465 000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f 1466 001a - 0b 4f 44 9e 25 1467 0020 - 1468 signatureAlgorithm: 1469 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1470 parameter: 1471 signature: 1472 0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64 1473 000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf 1474 001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4 1475 002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af 1476 003c - 2b 59 16 cc 36 63 e7 91-89 39 df df 1477 unsignedAttrs: 1478 1480 Appendix C. COSE examples 1482 These examples are generated on a pie 4 and a PC running BASH. Keys 1483 and Certificates have been generated with openssl with the following 1484 shell script: 1486 #!/bin/bash 1487 #try-cert.sh 1488 export dir=./brski/intermediate 1489 export cadir=./brski 1490 export cnfdir=./conf 1491 export format=pem 1492 export default_crl_days=30 1493 sn=8 1495 DevID=pledge.1.2.3.4 1496 serialNumber="serialNumber=$DevID" 1497 export hwType=1.3.6.1.4.1.6715.10.1 1498 export hwSerialNum=01020304 1499 export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" 1500 echo $hwType - $hwSerialNum 1501 echo $serialNumber 1503 # remove all files 1504 rm -r ./brski/* 1505 # 1506 # initialize file structure 1507 # root level 1508 cd $cadir 1509 mkdir certs crl csr newcerts private 1510 chmod 700 private 1511 touch index.txt 1512 touch serial 1513 echo 11223344556600 >serial 1514 echo 1000 > crlnumber 1515 # intermediate level 1516 mkdir intermediate 1517 cd intermediate 1518 mkdir certs crl csr newcerts private 1519 chmod 700 private 1520 touch index.txt 1521 echo 11223344556600 >serial 1522 echo 1000 > crlnumber 1523 cd ../.. 1525 # file structure is cleaned start filling 1527 echo "#############################" 1528 echo "create registrar keys and certificates " 1529 echo "#############################" 1531 echo "create root registrar certificate using ecdsa with sha256" 1532 openssl ecparam -name prime256v1 -genkey \ 1533 -noout -out $cadir/private/ca-regis.key 1535 openssl req -new -x509 \ 1536 -key $cadir/private/ca-regis.key \ 1537 -out $cadir/certs/ca-regis.crt \ 1538 -extensions v3_ca\ 1539 -days 365 \ 1540 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok\ 1541 "/OU=consultancy/CN=registrar.stok.nl" 1543 # Combine authority certificate and key 1544 echo "Combine authority certificate and key" 1545 openssl pkcs12 -passin pass:watnietweet \ 1546 -passout pass:watnietweet \ 1547 -inkey $cadir/private/ca-regis.key \ 1548 -in $cadir/certs/ca-regis.crt -export \ 1549 -out $cadir/certs/ca-regis-comb.pfx 1551 # converteer authority pkcs12 file to pem 1552 echo "converteer authority pkcs12 file to pem" 1553 openssl pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1554 -in $cadir/certs/ca-regis-comb.pfx \\ 1555 -out $cadir/certs/ca-regis-comb.crt -nodes 1557 #show certificate in registrar combined certificate 1558 openssl x509 -in $cadir/certs/ca-regis-comb.crt -text 1560 # 1561 # Certificate Authority for MASA 1562 # 1563 echo "#############################" 1564 echo "create MASA keys and certificates " 1565 echo "#############################" 1567 echo "create root MASA certificate using ecdsa with sha 256 key" 1568 openssl ecparam -name prime256v1 -genkey -noout \ 1569 -out $cadir/private/ca-masa.key 1571 openssl req -new -x509 \ 1572 -days 365 -key $cadir/private/ca-masa.key \ 1573 -out $cadir/certs/ca-masa.crt \ 1574 -extensions v3_ca\ 1575 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/\ 1576 OU=manufacturer/CN=masa.stok.nl" 1578 # Combine authority certificate and key 1579 echo "Combine authority certificate and key for masa" 1580 openssl pkcs12 -passin pass:watnietweet \ 1581 -passout pass:watnietweet\ 1582 -inkey $cadir/private/ca-masa.key \ 1583 -in $cadir/certs/ca-masa.crt -export \ 1584 -out $cadir/certs/ca-masa-comb.pfx 1586 # converteer authority pkcs12 file to pem for masa 1587 echo "converteer authority pkcs12 file to pem for masa" 1588 openssl pkcs12 -passin pass:watnietweet \ 1589 -passout pass:watnietweet\ 1590 -in $cadir/certs/ca-masa-comb.pfx \ 1591 -out $cadir/certs/ca-masa-comb.crt -nodes 1593 #show certificate in pledge combined certificate 1594 openssl x509 -in $cadir/certs/ca-masa-comb.crt -text 1596 # 1597 # Certificate for Pledge derived from MASA certificate 1598 # 1599 echo "#############################" 1600 echo "create pledge keys and certificates " 1601 echo "#############################" 1603 # Pledge derived Certificate 1605 echo "create pledge derived certificate using ecdsa with sha256" 1606 openssl ecparam -name prime256v1 -genkey \ 1607 -noout -out $dir/private/pledge.key 1609 echo "create pledge certificate request" 1610 openssl req -nodes -new -sha256 \ 1611 -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ 1612 -subj \ 1613 "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ 1614 /CN=uuid:$DevID/$serialNumber" 1616 # Sign pledge derived Certificate 1617 echo "sign pledge derived certificate " 1618 openssl ca -config $cnfdir/openssl-pledge.cnf \ 1619 -extensions 8021ar_idevid\ 1620 -days 365 -in $dir/csr/pledge.csr -out $dir/certs/pledge.crt 1622 # Add pledge key and pledge certificate to pkcs12 file 1623 echo "Add pledge key and pledge certificate to pkcs12 file" 1624 openssl pkcs12 -passin pass:watnietweet\ 1625 -passout pass:watnietweet\ 1626 -inkey $dir/private/pledge.key \ 1627 -in $dir/certs/pledge.crt -export \ 1628 -out $dir/certs/pledge-comb.pfx 1630 # converteer pledge pkcs12 file to pem 1631 echo "converteer pledge pkcs12 file to pem" 1632 openssl pkcs12 -passin pass:watnietweet \ 1633 -passout pass:watnietweet\ 1634 -in $dir/certs/pledge-comb.pfx \ 1635 -out $dir/certs/pledge-comb.crt -nodes 1637 #show certificate in pledge-comb.crt 1638 openssl x509 -in $dir/certs/pledge-comb.crt -text 1640 #show private key in pledge-comb.crt 1641 openssl ecparam -name prime256v1 \ 1642 -in $dir/certs/pledge-comb.crt -text 1644 The xxxx-comb certificates have been generated as required by libcoap 1645 for the DTLS connection generation. 1647 C.1. Pledge, Registrar and MASA keys 1649 This first section documents the public and private keys used in the 1650 subsequent test vectors below. These keys come from test code and 1651 are not used in any production system, and should only be used only 1652 to validate implementations. 1654 C.1.1. Pledge private key 1656 -----BEGIN PRIVATE KEY----- 1657 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgIpP20ud7muTl460b 1658 xFzupPkaMoaCIIIFwSOf0hvhQByhRANCAASKnIauvAtx6ZFWQniQOqvP0Zpdaudy 1659 Ve6Vrc80AjyWRGnN3oyQ0rnr5dXynfG2xq8+cY+uGwTrAJYp9OyoZCAs 1660 -----END PRIVATE KEY----- 1661 Private-Key: (256 bit) 1662 priv: 1663 22:93:f6:d2:e7:7b:9a:e4:e5:e3:ad:1b:c4:5c:ee: 1664 a4:f9:1a:32:86:82:20:82:05:c1:23:9f:d2:1b:e1: 1665 40:1c 1666 pub: 1667 04:8a:9c:86:ae:bc:0b:71:e9:91:56:42:78:90:3a: 1668 ab:cf:d1:9a:5d:6a:e7:72:55:ee:95:ad:cf:34:02: 1669 3c:96:44:69:cd:de:8c:90:d2:b9:eb:e5:d5:f2:9d: 1670 f1:b6:c6:af:3e:71:8f:ae:1b:04:eb:00:96:29:f4: 1671 ec:a8:64:20:2c 1672 ASN1 OID: prime256v1 1673 NIST CURVE: P-256 1675 C.1.2. Registrar private key 1677 -----BEGIN PRIVATE KEY----- 1678 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgHCCOKLhln+l8pLnx 1679 gWtMUm7zRY4ugkznuFimYDKbrNihRANCAARqJKniS+I00XrUfnYMlLXh3E7hFa2J 1680 ESrUpqZLsb9o+Rd9cOkQnLSMmw3H3yZBGZ0MLb/yHtWEA4rIP0eBvhOO 1681 -----END PRIVATE KEY----- 1682 Private-Key: (256 bit) 1683 priv: 1684 1c:20:8e:28:b8:65:9f:e9:7c:a4:b9:f1:81:6b:4c: 1685 52:6e:f3:45:8e:2e:82:4c:e7:b8:58:a6:60:32:9b: 1686 ac:d8 1687 pub: 1688 04:6a:24:a9:e2:4b:e2:34:d1:7a:d4:7e:76:0c:94: 1689 b5:e1:dc:4e:e1:15:ad:89:11:2a:d4:a6:a6:4b:b1: 1690 bf:68:f9:17:7d:70:e9:10:9c:b4:8c:9b:0d:c7:df: 1691 26:41:19:9d:0c:2d:bf:f2:1e:d5:84:03:8a:c8:3f: 1692 47:81:be:13:8e 1693 ASN1 OID: prime256v1 1694 NIST CURVE: P-256 1696 C.1.3. MASA private key 1698 -----BEGIN PRIVATE KEY----- 1699 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgQODnSgB7xR/aa3Ea 1700 JrPGz9lZhJ1aEc/56OEPiBr86SKhRANCAASB9HLsnEeyjtHrODNBANNi9khQ2gLQ 1701 VrIie8hLgFmVdwfQw1iMPPI8WwCDeVTaDdGwr6HC6M0sO9CGRZ+JcwrL 1702 -----END PRIVATE KEY----- 1703 Private-Key: (256 bit) 1704 priv: 1705 40:e0:e7:4a:00:7b:c5:1f:da:6b:71:1a:26:b3:c6: 1706 cf:d9:59:84:9d:5a:11:cf:f9:e8:e1:0f:88:1a:fc: 1707 e9:22 1708 pub: 1709 04:81:f4:72:ec:9c:47:b2:8e:d1:eb:38:33:41:00: 1710 d3:62:f6:48:50:da:02:d0:56:b2:22:7b:c8:4b:80: 1711 59:95:77:07:d0:c3:58:8c:3c:f2:3c:5b:00:83:79: 1712 54:da:0d:d1:b0:af:a1:c2:e8:cd:2c:3b:d0:86:45: 1713 9f:89:73:0a:cb 1714 ASN1 OID: prime256v1 1715 NIST CURVE: P-256 1717 C.2. Pledge, Registrar and MASA certificates 1719 Below the certificates that accompany the keys. The certificate 1720 description is followed by the hexadecimal DER of the certificate 1722 C.2.1. Pledge IDevID certificate 1723 Certificate: 1724 Data: 1725 Version: 3 (0x2) 1726 Serial Number: 4822678189204992 (0x11223344556600) 1727 Signature Algorithm: ecdsa-with-SHA256 1728 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 1729 OU=manufacturer, CN=masa.stok.nl 1730 Validity 1731 Not Before: Sep 9 07:42:03 2020 GMT 1732 Not After : Dec 31 23:59:59 9999 GMT 1733 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 1734 OU=manufacturing, 1735 CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4 1736 Subject Public Key Info: 1737 Public Key Algorithm: id-ecPublicKey 1738 Public-Key: (256 bit) 1739 pub: 1740 04:8a:9c:86:ae:bc:0b:71:e9:91:56:42:78:90:3a: 1741 ab:cf:d1:9a:5d:6a:e7:72:55:ee:95:ad:cf:34:02: 1742 3c:96:44:69:cd:de:8c:90:d2:b9:eb:e5:d5:f2:9d: 1743 f1:b6:c6:af:3e:71:8f:ae:1b:04:eb:00:96:29:f4: 1744 ec:a8:64:20:2c 1745 ASN1 OID: prime256v1 1746 NIST CURVE: P-256 1747 X509v3 extensions: 1748 X509v3 Basic Constraints: 1749 CA:FALSE 1750 X509v3 Subject Key Identifier: 1751 59:B1:E1:19:F4:68:53:E9:0E:7C:9F:29:D0:FB:5B:1F:AC:C3:82:49 1752 X509v3 Authority Key Identifier: 1753 keyid: 1754 22:BC:B8:20:D9:C5:6D:2D:5B:B3:BB:64:8B:E0:8B:A7:86:5E:CE:B4 1756 X509v3 Key Usage: critical 1757 Digital Signature, Key Encipherment 1758 Signature Algorithm: ecdsa-with-SHA256 1759 30:45:02:20:4d:fd:a8:83:78:31:d2:62:a4:e5:48:a2:e0:a7: 1760 3b:c5:14:e9:7e:46:13:45:bc:30:fd:1d:e5:d6:63:3e:d8:f4: 1761 02:21:00:a8:e5:1e:c2:79:77:90:fc:40:a8:7a:bf:b1:bd:81: 1762 8b:ee:d7:56:1a:04:4d:8f:c8:3d:76:5f:4d:6e:36:a2:c2 1764 This is the hexadecimal representation in (request-)voucher examples 1765 referred to as pledge-cert-hex. 1767 30820254308201faa003020102020711223344556600300a06082a8648ce3d04 1768 0302306f310b3009060355040613024e4c310b300906035504080c024e423110 1769 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 1770 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 1771 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323030393039303734 1772 3230335a180f39393939313233313233353935395a308190310b300906035504 1773 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 1774 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 1775 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 1776 3a706c656467652e312e322e332e34311730150603550405130e706c65646765 1777 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 1778 4200048a9c86aebc0b71e991564278903aabcfd19a5d6ae77255ee95adcf3402 1779 3c964469cdde8c90d2b9ebe5d5f29df1b6c6af3e718fae1b04eb009629f4eca8 1780 64202ca35d305b30090603551d1304023000301d0603551d0e0416041459b1e1 1781 19f46853e90e7c9f29d0fb5b1facc38249301f0603551d2304183016801422bc 1782 b820d9c56d2d5bb3bb648be08ba7865eceb4300e0603551d0f0101ff04040302 1783 05a0300a06082a8648ce3d040302034800304502204dfda8837831d262a4e548 1784 a2e0a73bc514e97e461345bc30fd1de5d6633ed8f4022100a8e51ec2797790fc 1785 40a87abfb1bd818beed7561a044d8fc83d765f4d6e36a2c2 1787 C.2.2. Registrar Certificate 1788 Certificate: 1789 Data: 1790 Version: 3 (0x2) 1791 Serial Number: 1792 39:73:74:f3:fa:81:2a:0d:37:10:3b:68:c1:84:81:c5:01:bc:7c:fe 1793 Signature Algorithm: ecdsa-with-SHA256 1794 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 1795 OU=consultancy, CN=registrar.stok.nl 1796 Validity 1797 Not Before: Sep 9 07:42:03 2020 GMT 1798 Not After : Sep 9 07:42:03 2021 GMT 1799 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 1800 OU=consultancy, CN=registrar.stok.nl 1801 Subject Public Key Info: 1802 Public Key Algorithm: id-ecPublicKey 1803 Public-Key: (256 bit) 1804 pub: 1805 04:6a:24:a9:e2:4b:e2:34:d1:7a:d4:7e:76:0c:94: 1806 b5:e1:dc:4e:e1:15:ad:89:11:2a:d4:a6:a6:4b:b1: 1807 bf:68:f9:17:7d:70:e9:10:9c:b4:8c:9b:0d:c7:df: 1808 26:41:19:9d:0c:2d:bf:f2:1e:d5:84:03:8a:c8:3f: 1809 47:81:be:13:8e 1810 ASN1 OID: prime256v1 1811 NIST CURVE: P-256 1812 X509v3 extensions: 1813 X509v3 Subject Key Identifier: 1814 25:CD:93:71:B5:A1:5F:6D:1E:E8:C3:7A:51:13:BE:0B:8F:13:2C:C2 1815 X509v3 Authority Key Identifier: 1816 keyid: 1817 25:CD:93:71:B5:A1:5F:6D:1E:E8:C3:7A:51:13:BE:0B:8F:13:2C:C2 1819 X509v3 Basic Constraints: 1820 CA:TRUE 1821 Signature Algorithm: ecdsa-with-SHA256 1822 30:46:02:21:00:a6:6d:9e:24:f9:de:08:b7:f0:cf:43:c3:c0: 1823 ee:57:cc:b6:60:de:ae:2e:70:cc:61:a1:a2:b3:35:35:02:5b: 1824 ba:02:21:00:bf:fd:74:6a:99:eb:da:01:77:fc:6c:37:95:75: 1825 8a:f4:a0:9f:99:8e:bc:4a:90:62:49:f0:7a:c9:65:96:dc:75 1827 This the hexadecimal representation, in (request-)voucher examples 1828 referred to as regis-cert-hex 1829 30820239308201dea0030201020214397374f3fa812a0d37103b68c18481c501 1830 bc7cfe300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 1831 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 1832 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 1833 73756c74616e6379311a301806035504030c117265676973747261722e73746f 1834 6b2e6e6c301e170d3230303930393037343230335a170d323130393039303734 1835 3230335a3073310b3009060355040613024e4c310b300906035504080c024e42 1836 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 1837 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 1838 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 1839 8648ce3d020106082a8648ce3d030107034200046a24a9e24be234d17ad47e76 1840 0c94b5e1dc4ee115ad89112ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df 1841 2641199d0c2dbff21ed584038ac83f4781be138ea350304e301d0603551d0e04 1842 16041425cd9371b5a15f6d1ee8c37a5113be0b8f132cc2301f0603551d230418 1843 3016801425cd9371b5a15f6d1ee8c37a5113be0b8f132cc2300c0603551d1304 1844 0530030101ff300a06082a8648ce3d0403020349003046022100a66d9e24f9de 1845 08b7f0cf43c3c0ee57ccb660deae2e70cc61a1a2b33535025bba022100bffd74 1846 6a99ebda0177fc6c3795758af4a09f998ebc4a906249f07ac96596dc75 1848 C.2.3. MASA Certificate 1849 Certificate: 1850 Data: 1851 Version: 3 (0x2) 1852 Serial Number: 1853 70:5a:34:7e:67:d2:4d:70:b0:c6:ca:60:ff:fb:75:d9:46:82:e6:0e 1854 Signature Algorithm: ecdsa-with-SHA256 1855 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 1856 OU=manufacturer, CN=masa.stok.nl 1857 Validity 1858 Not Before: Sep 9 07:42:03 2020 GMT 1859 Not After : Sep 9 07:42:03 2021 GMT 1860 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 1861 OU=manufacturer, CN=masa.stok.nl 1862 Subject Public Key Info: 1863 Public Key Algorithm: id-ecPublicKey 1864 Public-Key: (256 bit) 1865 pub: 1866 04:81:f4:72:ec:9c:47:b2:8e:d1:eb:38:33:41:00: 1867 d3:62:f6:48:50:da:02:d0:56:b2:22:7b:c8:4b:80: 1868 59:95:77:07:d0:c3:58:8c:3c:f2:3c:5b:00:83:79: 1869 54:da:0d:d1:b0:af:a1:c2:e8:cd:2c:3b:d0:86:45: 1870 9f:89:73:0a:cb 1871 ASN1 OID: prime256v1 1872 NIST CURVE: P-256 1873 X509v3 extensions: 1874 X509v3 Subject Key Identifier: 1875 22:BC:B8:20:D9:C5:6D:2D:5B:B3:BB:64:8B:E0:8B:A7:86:5E:CE:B4 1876 X509v3 Authority Key Identifier: 1877 keyid: 1878 22:BC:B8:20:D9:C5:6D:2D:5B:B3:BB:64:8B:E0:8B:A7:86:5E:CE:B4 1880 X509v3 Basic Constraints: 1881 CA:TRUE 1882 Signature Algorithm: ecdsa-with-SHA256 1883 30:45:02:20:04:ac:8d:48:62:a2:a5:04:4f:61:fd:38:83:53: 1884 9f:00:e7:d6:4b:4d:30:1b:84:29:d4:2d:35:58:b0:a0:0c:7d: 1885 02:21:00:8c:f1:f4:f9:a2:11:fe:64:46:a9:87:9f:58:ca:ea: 1886 da:4f:0a:42:32:c2:6a:e8:c5:9d:62:c0:67:f0:b8:44:43 1888 This is the hexadecimal representation, in (request-)voucher examples 1889 referred to as masa-cert-hex. 1891 30820230308201d6a0030201020214705a347e67d24d70b0c6ca60fffb75d946 1892 82e60e300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 1893 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 1894 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 1895 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 1896 301e170d3230303930393037343230335a170d3231303930393037343230335a 1897 306f310b3009060355040613024e4c310b300906035504080c024e423110300e 1898 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 1899 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 1900 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 1901 2a8648ce3d0301070342000481f472ec9c47b28ed1eb38334100d362f64850da 1902 02d056b2227bc84b8059957707d0c3588c3cf23c5b00837954da0dd1b0afa1c2 1903 e8cd2c3bd086459f89730acba350304e301d0603551d0e0416041422bcb820d9 1904 c56d2d5bb3bb648be08ba7865eceb4301f0603551d2304183016801422bcb820 1905 d9c56d2d5bb3bb648be08ba7865eceb4300c0603551d13040530030101ff300a 1906 06082a8648ce3d0403020348003045022004ac8d4862a2a5044f61fd3883539f 1907 00e7d64b4d301b8429d42d3558b0a00c7d0221008cf1f4f9a211fe6446a9879f 1908 58caeada4f0a4232c26ae8c59d62c067f0b84443 1910 C.3. COSE signed voucher request from pledge to Registrar 1912 In this example the voucher request has been signed by the pledge, 1913 and has been sent to the JRC over CoAPS. This example uses the 1914 proximity-registrar-cert mechanism to request a voucher that pins the 1915 certificate of the registrar. 1917 POST coaps://registrar.example.com/est/rv 1918 (Content-Format: application/voucher-cose+cbor) 1919 signed_request_voucher 1921 The payload signed_request_voucher is shown as hexadecimal dump (with 1922 lf added): 1924 d28444a101382ea1045820f8926f5ba385b7bccf23592b97a73c1b00bffc01023 1925 0f647f06960870b1fd6ee5902aca11909c5a61909c77818323032302d31302d35 1926 5431333a34363a31332d30303a30301909c97818323032322d31302d355431333 1927 a34363a31332d30303a30301909c6021909cc5029c7bafb81a2c6160d3357d229 1928 11f5101909d26e706c656467652e312e322e332e341909cf59023d30820239308 1929 201dea0030201020214397374f3fa812a0d37103b68c18481c501bc7cfe300a06 1930 082a8648ce3d0403023073310b3009060355040613024e4c310b3009060355040 1931 80c024e423110300e06035504070c0748656c6d6f6e6431133011060355040a0c 1932 0a76616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e637 1933 9311a301806035504030c117265676973747261722e73746f6b2e6e6c301e170d 1934 3230303930393037343230335a170d3231303930393037343230335a3073310b3 1935 009060355040613024e4c310b300906035504080c024e423110300e0603550407 1936 0c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b31143 1937 012060355040b0c0b636f6e73756c74616e6379311a301806035504030c117265 1938 676973747261722e73746f6b2e6e6c3059301306072a8648ce3d020106082a864 1939 8ce3d030107034200046a24a9e24be234d17ad47e760c94b5e1dc4ee115ad8911 1940 2ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df2641199d0c2dbff21ed5840 1941 38ac83f4781be138ea350304e301d0603551d0e0416041425cd9371b5a15f6d1e 1942 e8c37a5113be0b8f132cc2301f0603551d2304183016801425cd9371b5a15f6d1 1943 ee8c37a5113be0b8f132cc2300c0603551d13040530030101ff300a06082a8648 1944 ce3d0403020349003046022100a66d9e24f9de08b7f0cf43c3c0ee57ccb660dea 1945 e2e70cc61a1a2b33535025bba022100bffd746a99ebda0177fc6c3795758af4a0 1946 9f998ebc4a906249f07ac96596dc7558473045022100fc28be418e5f25152590e 1947 872b4bbdbe334cd31d1ebb0a806e7a172cad5cff604022056ee414ddac438e7f5 1948 1dda9ddf6ec6e31a78cdde6574717fe46dd3a7c60f5bb5 1950 The representiation of signed_voucher_request in CBOR diagnostic 1951 format is: 1953 Diagnose(signed_request_voucher) = 1954 18([ 1955 h'A101382E', # {"alg": -47} 1956 {4:h'F8926F5BA385B7BCCF23592B97A73C1B00BFFC010230F647F06960870B1F 1957 D6EE'}, 1958 h'request_voucher' 1959 h'3045022100FC28BE418E5F25152590E872B4BBDBE334CD31D1EBB0A806E7A17 1960 2CAD5CFF604022056EE414DDAC438E7F51DDA9DDF6EC6E31A78CDDE6574717FE4 1961 6DD3A7C60F5BB5']) 1963 Diagnose(request_voucher) = 1964 {2501: {2503: "2020-10-5T13:46:13-00:00", 1965 2505: "2022-10-5T13:46:13-00:00", 1966 2502: 2, 1967 2508: h'29C7BAFB81A2C6160D3357D22911F510', 1968 2514: "pledge.1.2.3.4", 1969 2511: h'regis-cert-hex'}}, 1971 C.4. COSE signed voucher request from Registrar to MASA 1973 In this example the voucher request has been signed by the JRC using 1974 the private key from Appendix C.1.2. Contained within this voucher 1975 request is the voucher request from the pledge to JRC. 1977 POST coaps://masa.example.com/est/rv 1978 (Content-Format: application/voucher-cose+cbor) 1979 signed_masa_request_voucher 1981 The payload signed_masa_voucher_request is shown as hexadecimal dump 1982 (with lf added): 1984 d28444a101382ea1045820b86ae808f79af17e5948cbda731f158d04bd091c73f 1985 485f2409eac08ee7ddb5c5903fea11909c5a61909c77818323032302d31302d35 1986 5431333a34363a31332d30303a30301909c97818323032322d31302d355431333 1987 a34363a31332d30303a30301909cc5029c7bafb81a2c6160d3357d22911f51019 1988 09d26e706c656467652e312e322e332e341909ca586b433d4e4c2c2053543d4e4 1989 22c204c3d48656c6d6f6e642c204f3d76616e64657273746f6b2c204f553d6d61 1990 6e75666163747572696e672c20434e3d757569643a706c656467652e312e322e3 1991 32e342c2073657269616c4e756d6265723d706c656467652e312e322e332e3419 1992 09ce590323d28444a101382ea1045820f8926f5ba385b7bccf23592b97a73c1b0 1993 0bffc010230f647f06960870b1fd6ee5902aca11909c5a61909c7781832303230 1994 2d31302d355431333a34363a31332d30303a30301909c97818323032322d31302 1995 d355431333a34363a31332d30303a30301909c6021909cc5029c7bafb81a2c616 1996 0d3357d22911f5101909d26e706c656467652e312e322e332e341909cf59023d3 1997 0820239308201dea0030201020214397374f3fa812a0d37103b68c18481c501bc 1998 7cfe300a06082a8648ce3d0403023073310b3009060355040613024e4c310b300 1999 906035504080c024e423110300e06035504070c0748656c6d6f6e643113301106 2000 0355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e73756 2001 c74616e6379311a301806035504030c117265676973747261722e73746f6b2e6e 2002 6c301e170d3230303930393037343230335a170d3231303930393037343230335 2003 a3073310b3009060355040613024e4c310b300906035504080c024e423110300e 2004 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e646572737 2005 46f6b31143012060355040b0c0b636f6e73756c74616e6379311a301806035504 2006 030c117265676973747261722e73746f6b2e6e6c3059301306072a8648ce3d020 2007 106082a8648ce3d030107034200046a24a9e24be234d17ad47e760c94b5e1dc4e 2008 e115ad89112ad4a6a64bb1bf68f9177d70e9109cb48c9b0dc7df2641199d0c2db 2009 ff21ed584038ac83f4781be138ea350304e301d0603551d0e0416041425cd9371 2010 b5a15f6d1ee8c37a5113be0b8f132cc2301f0603551d2304183016801425cd937 2011 1b5a15f6d1ee8c37a5113be0b8f132cc2300c0603551d13040530030101ff300a 2012 06082a8648ce3d0403020349003046022100a66d9e24f9de08b7f0cf43c3c0ee5 2013 7ccb660deae2e70cc61a1a2b33535025bba022100bffd746a99ebda0177fc6c37 2014 95758af4a09f998ebc4a906249f07ac96596dc7558473045022100fc28be418e5 2015 f25152590e872b4bbdbe334cd31d1ebb0<