idnits 2.17.1 draft-ietf-anima-constrained-voucher-06.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 438 has weird spacing: '...ndatory false...' == Line 442 has weird spacing: '...ndatory false...' == Line 688 has weird spacing: '...ndatory false...' == Line 692 has weird spacing: '...ndatory false...' -- The document date (January 14, 2020) is 1535 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 929, but not defined == Missing Reference: 'This RFC' is mentioned on line 1001, but not defined == Missing Reference: 'Empty' is mentioned on line 1151, but not defined == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-34 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-08 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-11 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). 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: July 17, 2020 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 January 14, 2020 10 Constrained Voucher Artifacts for Bootstrapping Protocols 11 draft-ietf-anima-constrained-voucher-06 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 July 17, 2020. 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 . . . . . . . . . . . . . . . . . . . . 13 73 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 14 74 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 20 87 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 20 88 9.4. The RFC SID range assignment sub-registry . . . . . . . . 21 89 9.5. The SMI Security for S/MIME CMS Content Type Registry . . 21 90 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 21 91 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . 27 102 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 28 103 A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 28 104 A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 29 105 Appendix B. Signed voucher-request examples . . . . . . . . . . 30 106 B.1. CMS signed voucher-request example . . . . . . . . . . . 30 107 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 33 108 C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 33 109 C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 33 110 C.1.2. Device private key . . . . . . . . . . . . . . . . . 34 111 C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 35 112 C.1.4. Registrar private key . . . . . . . . . . . . . . . . 35 113 C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 35 114 C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 35 115 C.2. COSE signed requestvoucher with registrar certificate 116 pinned . . . . . . . . . . . . . . . . . . . . . . . . . 36 117 C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 36 118 C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 37 119 C.5. COSE signed request voucher . . . . . . . . . . . . . . . 39 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 122 1. Introduction 124 Enrollment of new nodes into constrained networks with constrained 125 nodes present unique challenges. 127 There are bandwidth and code space issues to contend. A solution 128 such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in 129 terms of code space or bandwidth required. 131 This document defines a constrained version of [RFC8366]. Rather 132 than serializing the YANG definition in JSON, it is serialized into 133 CBOR ([RFC7049]). 135 This document follows a similar, but not identical structure as 136 [RFC8366]. Some sections are left out entirely. Additional sections 137 have been added concerning: 139 1. Addition of voucher-request specification as defined in 140 [I-D.ietf-anima-bootstrapping-keyinfra], 142 2. Addition to [I-D.ietf-ace-coap-est] of voucher transport requests 143 over CoAP. 145 The CBOR definitions for this constrained voucher format are defined 146 using the mechanism describe in [I-D.ietf-core-yang-cbor] using the 147 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 148 convert YANG documents into an list of SID keys is still in its 149 infancy, the table of SID values presented here should be considered 150 normative rather than the output of the pyang tool. 152 Two methods of signing the resulting CBOR object are described in 153 this document: 155 1. One is CMS [RFC5652]. 157 2. The other is COSE_Sign1 [RFC8152] objects. 159 2. Terminology 161 The following terms are defined in [RFC8366], and are used 162 identically as in that document: artifact, imprint, domain, Join 163 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 164 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 166 3. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 4. Survey of Voucher Types 176 [RFC8366] provides for vouchers that assert proximity, that 177 authenticate the registrar and that include different amounts of 178 anti-replay protection. 180 This document does not make any extensions to the types of vouchers. 182 Time based vouchers are included in this definition, but given that 183 constrained devices are extremely unlikely to have accurate time, 184 their use is very unlikely. Most users of these constrained vouchers 185 will be online and will use live nonces to provide anti-replay 186 protection. 188 [RFC8366] defined only the voucher artifact, and not the Voucher 189 Request artifact, which was defined in 190 [I-D.ietf-anima-bootstrapping-keyinfra]. 192 This document defines both a constrained voucher and a constrained 193 voucher-request. They are presented in the order voucher-request, 194 followed by a voucher response as this is the time order that they 195 occur. 197 This document defines both CMS-signed voucher requests and responses, 198 and COSE signed voucher requests and responses. The use of CMS 199 signatures implies the use of PKIX format certificates. The pinned- 200 domain-cert present in such a voucher, is the certificate of the 201 Registrar. 203 The constrained voucher and constrained voucher request MUST be 204 signed. 206 The use of the two signing formats permit the use of both PKIX format 207 certificates, and raw public keys (RPK). When RPKs are used, the 208 voucher produced by the MASA pins the raw public key of the 209 Registrar: the pinned-domain-subject-public-key-info in such a 210 voucher, is the raw public key of the Registrar. This is described 211 in the YANG definition for the constrained voucher. 213 5. Discovery and URI 215 This section describes the BRSKI extensions to EST-coaps 216 [I-D.ietf-ace-coap-est] to transport the voucher between registrar, 217 proxy and pledge over CoAP. The extensions are targeted to low- 218 resource networks with small packets. Saving header space is 219 important and the EST-coaps URI is shorter than the EST URI. 221 The presence and location of (path to) the management data are 222 discovered by sending a GET request to "/.well-known/core" including 223 a resource type (RT) parameter with the value "ace.est" [RFC6690]. 224 Upon success, the return payload will contain the root resource of 225 the EST resources. It is up to the implementation to choose its root 226 resource; throughout this document the example root resource /est is 227 used. 229 The EST-coaps server URIs differ from the EST URI by replacing the 230 scheme https by coaps and by specifying shorter resource path names: 232 coaps://www.example.com/est/short-name 234 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 235 corresponding paths which are supported by EST. Table 1 provides the 236 mapping from the BRSKI extension URI path to the EST-coaps URI path. 238 +------------------+-----------+ 239 | BRSKI | EST-coaps | 240 +------------------+-----------+ 241 | /requestvoucher | /rv | 242 | | | 243 | /voucher_status | /vs | 244 | | | 245 | /enrollstatus | /es | 246 | | | 247 | /requestauditlog | /ra | 248 +------------------+-----------+ 250 Table 1: BRSKI path to EST-coaps path 252 /requestvoucher, /voucher_status and /enrollstatus are needed between 253 pledge and Registrar. 255 When discovering the root path for the EST resources, the server MAY 256 return the full resource paths and the used content types. This is 257 useful when multiple content types are specified for EST-coaps 258 server. For example, the following more complete response is 259 possible. 261 REQ: GET /.well-known/core?rt=ace.est* 263 RES: 2.05 Content 264 ; rt="ace.est" 265 ; rt="ace.est/rv";ct=TBD2 TBD3 266 ; rt="ace.est/vs";ct=50 60 267 ; rt="ace.est/es";ct=50 60 268 ; rt="ace.est/ra";ct=TBD2 TBD3 270 The return of the content-types allows the client to choose the most 271 appropriate one from multiple content types. 273 ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and 274 ct=TBD3 stands for Content-Format "application/voucher-cose+cbor". 276 Content-Formats TBD2 and TBD3 are defined in this document. 278 The Content-Format ("application/json") 50 MAY be supported. 279 Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be 280 supported. 282 6. Artifacts 284 This section describes the abstract (tree) definition as explained in 285 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 286 level view of the contents of each artifact. 288 Then the assigned SID values are presented. These have been assigned 289 using the rules in [I-D.ietf-core-sid], with an allocation that was 290 made via the http://comi.space service. 292 6.1. Voucher Request artifact 294 6.1.1. Tree Diagram 296 The following diagram is largely a duplicate of the contents of 297 [RFC8366], with the addition of proximity-registrar-subject-public- 298 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 300 prior-signed-voucher-request is only used between the Registrar and 301 the MASA. proximity-registrar-subject-public-key-info replaces 302 proximity-registrar-cert for the extremely constrained cases. 304 module: ietf-constrained-voucher-request 306 grouping voucher-request-constrained-grouping 307 +-- voucher 308 +-- created-on? 309 | yang:date-and-time 310 +-- expires-on? 311 | yang:date-and-time 312 +-- assertion 313 | enumeration 314 +-- serial-number 315 | string 316 +-- idevid-issuer? 317 | binary 318 +-- pinned-domain-cert? 319 | binary 320 +-- domain-cert-revocation-checks? 321 | boolean 322 +-- nonce? 323 | binary 324 +-- last-renewal-date? 325 | yang:date-and-time 326 +-- proximity-registrar-subject-public-key-info? 327 | binary 328 +-- proximity-registrar-sha256-of-subject-public-key-info? 329 | binary 330 +-- proximity-registrar-cert? 331 | binary 332 +-- prior-signed-voucher-request? 333 binary 335 6.1.2. SID values 336 SID Assigned to 337 --------- -------------------------------------------------- 338 2501 data /ietf-constrained-voucher-request:voucher 339 2502 data .../assertion 340 2503 data .../created-on 341 2504 data .../domain-cert-revocation-checks 342 2505 data .../expires-on 343 2506 data .../idevid-issuer 344 2507 data .../last-renewal-date 345 2508 data /ietf-constrained-voucher-request:voucher/nonce 346 2509 data .../pinned-domain-cert 347 2510 data .../prior-signed-voucher-request 348 2511 data .../proximity-registrar-cert 349 2512 data mity-registrar-sha256-of-subject-public-key-info 350 2513 data .../proximity-registrar-subject-public-key-info 351 2514 data .../serial-number 353 6.1.3. YANG Module 355 In the constrained-voucher-request YANG module, the voucher is 356 "augmented" within the "used" grouping statement such that one 357 continuous set of SID values is generated for the constrained- 358 voucher-request module name, all voucher attributes, and the 359 constrained-voucher-request attribute. Two attributes of the voucher 360 are "refined" to be optional. 362 file "ietf-constrained-voucher-request@2019-09-01.yang" 363 module ietf-constrained-voucher-request { 364 yang-version 1.1; 366 namespace 367 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 368 prefix "constrained"; 370 import ietf-restconf { 371 prefix rc; 372 description 373 "This import statement is only present to access 374 the yang-data extension defined in RFC 8040."; 375 reference "RFC 8040: RESTCONF Protocol"; 376 } 378 import ietf-voucher { 379 prefix "v"; 380 } 382 organization 383 "IETF ANIMA Working Group"; 385 contact 386 "WG Web: 387 WG List: 388 Author: Michael Richardson 389 390 Author: Peter van der Stok 391 392 Author: Panos Kampanakis 393 "; 394 description 395 "This module defines the format for a voucher request, 396 which is produced by a pledge to request a voucher. 397 The voucher-request is sent to the potential owner's 398 Registrar, which in turn sends the voucher request to 399 the manufacturer or delegate (MASA). 401 A voucher is then returned to the pledge, binding the 402 pledge to the owner. This is a constrained version of the 403 voucher-request present in 404 draft-ietf-anima-bootstrap-keyinfra.txt. 406 This version provides a very restricted subset appropriate 407 for very constrained devices. 408 In particular, it assumes that nonce-ful operation is 409 always required, that expiration dates are rather weak, as no 410 clocks can be assumed, and that the Registrar is identified 411 by a pinned Raw Public Key. 413 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 414 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 415 and 'OPTIONAL' in the module text are to be interpreted as 416 described in RFC 2119."; 418 revision "2019-09-01" { 419 description 420 "Initial version"; 421 reference 422 "RFC XXXX: Voucher Profile for Constrained Devices"; 423 } 425 rc:yang-data voucher-request-constrained-artifact { 426 // YANG data template for a voucher. 427 uses voucher-request-constrained-grouping; 428 } 430 // Grouping defined for future usage 431 grouping voucher-request-constrained-grouping { 432 description 433 "Grouping to allow reuse/extensions in future work."; 435 uses v:voucher-artifact-grouping { 437 refine voucher/created-on { 438 mandatory false; 439 } 441 refine voucher/pinned-domain-cert { 442 mandatory false; 443 } 445 augment "voucher" { 446 description "Base the constrained voucher-request upon the 447 regular one"; 449 leaf proximity-registrar-subject-public-key-info { 450 type binary; 451 description 452 "The proximity-registrar-subject-public-key-info replaces 453 the proximit-registrar-cert in constrained uses of 454 the voucher-request. 455 The proximity-registrar-subject-public-key-info is the 456 Raw Public Key of the Registrar. This field is encoded 457 as specified in RFC7250, section 3. 458 The ECDSA algorithm MUST be supported. 459 The EdDSA algorithm as specified in 460 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 461 Support for the DSA algorithm is not recommended. 462 Support for the RSA algorithm is MAY, but due to 463 size is discouraged."; 464 } 466 leaf proximity-registrar-sha256-of-subject-public-key-info { 467 type binary; 468 description 469 "The proximity-registrar-sha256-of-subject-public-key-info 470 is an alternative to 471 proximity-registrar-subject-public-key-info. 472 and pinned-domain-cert. In many cases the 473 public key of the domain has already been transmitted 474 during the key agreement protocol, and it is wasteful 475 to transmit the public key another two times. 476 The use of a hash of public key info, at 32-bytes for 477 sha256 is a significant savings compared to an RSA 478 public key, but is only a minor savings compared to 479 a 256-bit ECDSA public-key. 480 Algorithm agility is provided by extensions to this 481 specifications which define new leaf for other hash 482 types."; 483 } 485 leaf proximity-registrar-cert { 486 type binary; 487 description 488 "An X.509 v3 certificate structure as specified by 489 RFC 5280, 490 Section 4 encoded using the ASN.1 distinguished encoding 491 rules (DER), as specified in ITU-T X.690. 493 The first certificate in the Registrar TLS server 494 certificate_list sequence (see [RFC5246]) presented by 495 the Registrar to the Pledge. This MUST be populated in a 496 Pledge's voucher request if the proximity assertion is 497 populated."; 498 } 500 leaf prior-signed-voucher-request { 501 type binary; 502 description 503 "If it is necessary to change a voucher, or re-sign and 504 forward a voucher that was previously provided along a 505 protocol path, then the previously signed voucher 506 SHOULD be included in this field. 508 For example, a pledge might sign a proximity voucher, 509 which an intermediate registrar then re-signs to 510 make its own proximity assertion. This is a simple 511 mechanism for a chain of trusted parties to change a 512 voucher, while maintaining the prior signature 513 information. 515 The pledge MUST ignore all prior voucher information 516 when accepting a voucher for imprinting. Other 517 parties MAY examine the prior signed voucher 518 information for the purposes of policy decisions. 519 For example this information could be useful to a 520 MASA to determine that both pledge and registrar 521 agree on proximity assertions. The MASA SHOULD 522 remove all prior-signed-voucher-request information when 523 signing a voucher for imprinting so as to minimize the 524 final voucher size."; 525 } 527 } 528 } 529 } 530 } 531 533 6.1.4. Example voucher request artifact 535 Below is a CBOR serialization of the constrained-voucher-request is 536 shown in diagnostic CBOR notation. The enum value of the assertion 537 field is calculated to be zero by following the algorithm described 538 in section 9.6.4.2 of [RFC7950]. 540 { 541 2501: { 542 +2 : "2016-10-07T19:31:42Z", / SID= 2503, created-on / 543 +4 : "2016-10-21T19:31:42Z", / SID= 2505, expires-on / 544 +1 : 2, / SID= 2502, assertion / 545 / "proximity" / 546 +13: "JADA123456789", / SID= 2514, serial-number / 547 +5 : h'01020D0F', / SID= 2506, idevid-issuer / 548 +10: h'01020D0F', / SID=2511, proximity-registrar-cert/ 549 +3 : true, / SID= 2504, domain-cert 550 -revocation-checks/ 551 +6 : "2017-10-07T19:31:42Z", / SID= 2507, last-renewal-date / 552 +12: h'01020D0F' / SID= 2513, proximity-registrar 553 -subject-public-key-info / 554 } 555 } 557 6.2. Voucher artifact 559 The voucher's primary purpose is to securely assign a pledge to an 560 owner. The voucher informs the pledge which entity it should 561 consider to be its owner. 563 This document defines a voucher that is a CBOR encoded instance of 564 the YANG module defined in Section 5.3 that has been signed with CMS 565 or with COSE. 567 6.2.1. Tree Diagram 569 The following diagram is largely a duplicate of the contents of 570 [RFC8366], with only the addition of pinned-domain-subject-public- 571 key-info. 573 module: ietf-constrained-voucher 575 grouping voucher-constrained-grouping 576 +-- voucher 577 +-- created-on? 578 | yang:date-and-time 579 +-- expires-on? 580 | yang:date-and-time 581 +-- assertion enumeration 582 +-- serial-number string 583 +-- idevid-issuer? binary 584 +-- pinned-domain-cert? binary 585 +-- domain-cert-revocation-checks? boolean 586 +-- nonce? binary 587 +-- last-renewal-date? 588 | yang:date-and-time 589 +-- pinned-domain-subject-public-key-info? binary 590 +-- pinned-sha256-of-subject-public-key-info? binary 592 6.2.2. SID values 594 SID Assigned to 595 --------- -------------------------------------------------- 596 2451 data /ietf-constrained-voucher:voucher 597 2452 data /ietf-constrained-voucher:voucher/assertion 598 2453 data /ietf-constrained-voucher:voucher/created-on 599 2454 data .../domain-cert-revocation-checks 600 2455 data /ietf-constrained-voucher:voucher/expires-on 601 2456 data /ietf-constrained-voucher:voucher/idevid-issuer 602 2457 data .../last-renewal-date 603 2458 data /ietf-constrained-voucher:voucher/nonce 604 2459 data .../pinned-domain-cert 605 2460 data .../pinned-domain-subject-public-key-info 606 2461 data .../pinned-sha256-of-subject-public-key-info 607 2462 data /ietf-constrained-voucher:voucher/serial-number 609 6.2.3. YANG Module 611 In the constrained-voucher YANG module, the voucher is "augmented" 612 within the "used" grouping statement such that one continuous set of 613 SID values is generated for the constrained-voucher module name, all 614 voucher attributes, and the constrained-voucher attribute. Two 615 attributes of the voucher are "refined" to be optional. 617 file "ietf-constrained-voucher@2019-09-01.yang" 618 module ietf-constrained-voucher { 619 yang-version 1.1; 621 namespace 622 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 623 prefix "constrained"; 625 import ietf-restconf { 626 prefix rc; 627 description 628 "This import statement is only present to access 629 the yang-data extension defined in RFC 8040."; 630 reference "RFC 8040: RESTCONF Protocol"; 631 } 633 import ietf-voucher { 634 prefix "v"; 635 } 637 organization 638 "IETF ANIMA Working Group"; 640 contact 641 "WG Web: 642 WG List: 643 Author: Michael Richardson 644 645 Author: Peter van der Stok 646 647 Author: Panos Kampanakis 648 "; 649 description 650 "This module defines the format for a voucher, which is produced 651 by a pledge's manufacturer or delegate (MASA) to securely assign 652 one or more pledges to an 'owner', so that the pledges may 653 establis a secure connection to the owner's network 654 infrastructure. 656 This version provides a very restricted subset appropriate 657 for very constrained devices. 658 In particular, it assumes that nonce-ful operation is 659 always required, that expiration dates are rather weak, as no 660 clocks can be assumed, and that the Registrar is identified 661 by a pinned Raw Public Key. 663 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 664 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 665 and 'OPTIONAL' in the module text are to be interpreted as 666 described in RFC 2119."; 668 revision "2019-09-01" { 669 description 670 "Initial version"; 671 reference 672 "RFC XXXX: Voucher Profile for Constrained Devices"; 673 } 675 rc:yang-data voucher-constrained-artifact { 676 // YANG data template for a voucher. 677 uses voucher-constrained-grouping; 678 } 680 // Grouping defined for future usage 681 grouping voucher-constrained-grouping { 682 description 683 "Grouping to allow reuse/extensions in future work."; 685 uses v:voucher-artifact-grouping { 687 refine voucher/created-on { 688 mandatory false; 689 } 691 refine voucher/pinned-domain-cert { 692 mandatory false; 693 } 695 augment "voucher" { 696 description "Base the constrained voucher 697 upon the regular one"; 698 leaf pinned-domain-subject-public-key-info { 699 type binary; 700 description 701 "The pinned-domain-subject-public-key-info replaces the 702 pinned-domain-cert in constrained uses of 703 the voucher. The pinned-domain-subject-public-key-info 704 is the Raw Public Key of the Registrar. 705 This field is encoded as specified in RFC7250, 706 section 3. 707 The ECDSA algorithm MUST be supported. 708 The EdDSA algorithm as specified in 709 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 710 Support for the DSA algorithm is not recommended. 711 Support for the RSA algorithm is a MAY."; 712 } 714 leaf pinned-sha256-of-subject-public-key-info { 715 type binary; 716 description 717 "The pinned-hash-subject-public-key-info is a second 718 alternative to pinned-domain-cert. In many cases the 719 public key of the domain has already been transmitted 720 during the key agreement process, and it is wasteful 721 to transmit the public key another two times. 722 The use of a hash of public key info, at 32-bytes for 723 sha256 is a significant savings compared to an RSA 724 public key, but is only a minor savings compared to 725 a 256-bit ECDSA public-key. 726 Algorithm agility is provided by extensions to this 727 specifications which define new leaf for other hash types"; 728 } 729 } 730 } 731 } 732 } 733 735 6.2.4. Example voucher artifacts 737 Below a the CBOR serialization of the constrained-voucher is shown in 738 diagnostic CBOR notation. The enum value of the assertion field is 739 calculated to be zero by following the algorithm described in section 740 9.6.4.2 of [RFC7950]. 742 { 743 2451: { 744 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 745 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 746 +1 : 0, / SID = 2452, assertion / 747 / "verified" / 748 +11: "JADA123456789", / SID = 2462, serial-number / 749 +5 : h'01020D0F', / SID = 2456, idevid-issuer / 750 +8 : h'01020D0F', / SID = 2459, pinned-domain-cert/ 751 +3 : true, / SID = 2454, domain-cert 752 -revocation-checks / 753 +6 : "2017-10-07T19:31:42Z", / SID = 2457, last-renewal-date / 754 +9 : h'01020D0F' / SID = 2460, pinned-domain 755 -subject-public-key-info / 756 } 757 } 759 The signing of the example is shown in Appendix B.1. 761 6.3. Signing voucher and voucher-request artifacts 763 6.3.1. CMS signing 765 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 766 voucher is much like the equivalent voucher defined in [RFC8366]. 768 A different eContentType of TBD1 is used to indicate that the 769 contents are in a different format than in [RFC8366]. The id-ct- 770 animaJSONVoucher allocated by [RFC8366] indicates a voucher and 771 voucher-request encoded in JSON, and the new value TBD1 indicates 772 that the voucher and voucher-request are encoded in CBOR. 774 The ContentInfo structure contains a payload consisting of the CBOR 775 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 776 creates a canonical ordering for the keys on the wire. This 777 canonical ordering is not important as there is no expectation that 778 the content will be reproduced during the validation process. 780 Normally the recipient is the pledge and the signer is the MASA. 782 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 783 unsigned voucher requests from the pledge to the JRC. In this 784 specification, voucher-request artifact MUST be signed from the 785 pledge to the registrar. From the JRC to the MASA, the voucher- 786 request artifact MUST be signed by the domain owner key which is 787 requesting ownership. 789 The considerations of [RFC5652] section 5.1, concerning validating 790 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 792 The CMS structure SHOULD also contain all the certificates leading up 793 to and including the signer's trust anchor certificate known to the 794 recipient. The inclusion of the trust anchor is unusual in many 795 applications, but without it third parties can not accurately audit 796 the transaction. 798 The CMS structure MAY also contain revocation objects for any 799 intermediate certificate authorities (CAs) between the voucher-issuer 800 and the trust anchor known to the recipient. However, the use of 801 CRLs and other validity mechanisms is discouraged, as the pledge is 802 unlikely to be able to perform online checks, and is unlikely to have 803 a trusted clock source. As described below, the use of short-lived 804 vouchers and/or pledge provided nonce provides a freshness guarantee. 806 [EDnote: compulsory signing algorithms are ......] 807 In Appendix B.1 an example for the CMS signing of the voucher-request 808 is shown. 810 6.3.2. COSE signing 812 The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152]. 813 The CBOR object that carries the body, the signature, and the 814 information about the body and signature is called the COSE_Sign1 815 structure. It is used when only one signature is used on the body. 816 Support for EdDSA with Ed25519 is compulsory. 818 The supported COSE-sign1 object stucture is shown in Figure 1. 820 COSE_Sign1( 821 [ 822 h'a10127', # { "alg": EDdsa } 823 { 824 "kid" : h'789' # hash(pblic key) 825 }, 826 h'123', #voucher-request binary content 827 h'456', #voucher-request binary public signature 828 ] 829 ) 831 Figure 1: cose-sign1 example 833 The [COSE-registry] specifies the integers that replace the strings 834 and the mnemonics in Figure 1. The value of the "kid" parameter is 835 an example value. Usually a hash of the public key is used to 836 idientify the public key. The distribution of the public key and its 837 hash is done out of band. 839 In Appendix C a binary cose-sign1 object is shown based on the 840 voucher-request example of Section 6.1.4. 842 7. Design Considerations 844 The design considerations for the CBOR encoding of vouchers is much 845 the same as for [RFC8366]. 847 One key difference is that the names of the leaves in the YANG does 848 not have a material effect on the size of the resulting CBOR, as the 849 SID translation process assigns integers to the names. 851 8. Security Considerations 853 8.1. Clock Sensitivity 855 TBD. 857 8.2. Protect Voucher PKI in HSM 859 TBD. 861 8.3. Test Domain Certificate Validity when Signing 863 TBD. 865 9. IANA Considerations 867 9.1. Resource Type Registry 869 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 870 parameters" registry are specified below. These can be registered 871 either in the Expert Review range (0-255) or IETF Review range 872 (256-9999). 874 ace.rt.rv needs registration with IANA 875 ace.rt.vs needs registration with IANA 876 ace.rt.es needs registration with IANA 877 ace.rt.ra needs registration with IANA 879 9.2. The IETF XML Registry 881 This document registers two URIs in the IETF XML registry [RFC3688]. 882 Following the format in [RFC3688], the following registration is 883 requested: 885 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 886 Registrant Contact: The ANIMA WG of the IETF. 887 XML: N/A, the requested URI is an XML namespace. 889 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 890 Registrant Contact: The ANIMA WG of the IETF. 891 XML: N/A, the requested URI is an XML namespace. 893 9.3. The YANG Module Names Registry 895 This document registers two YANG modules in the YANG Module Names 896 registry [RFC6020]. Following the format defined in [RFC6020], the 897 the following registration is requested: 899 name: ietf-constrained-voucher 900 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 901 prefix: vch 902 reference: RFC XXXX 904 name: ietf-constrained-voucher-request 905 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 906 -voucher-request 907 prefix: vch 908 reference: RFC XXXX 910 9.4. The RFC SID range assignment sub-registry 912 ------------ ------ --------------------------- ------------ 913 Entry-point | Size | Module name | RFC Number 914 ------------ ------ --------------------------- ------------ 915 2450 50 ietf-constrained-voucher [ThisRFC] 916 2500 50 ietf-constrained-voucher [ThisRFC} 917 -request 918 ----------- ------ --------------------------- ------------ 920 Warning: These SID values are defined in [I-D.ietf-core-sid]. 922 9.5. The SMI Security for S/MIME CMS Content Type Registry 924 This document registers an OID in the "SMI Security for S/MIME CMS 925 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 927 Decimal Description References 928 ------- -------------------------------------- ---------- 929 TBD1 id-ct-animaCBORVoucher [ThisRFC] 931 EDNOTE: should a separate value be used for Voucher Requests? 933 9.6. Media-Type Registry 935 This section registers the 'application/voucher-cms+cbor' media type 936 and the 'application/voucher-cose+cbor' in the "Media Types" 937 registry. These media types are used to indicate that the content is 938 a CBOR voucher either signed with a cms structure or a COSE_Sign1 939 structure [RFC8152]. 941 9.6.1. application/voucher-cms+cbor 942 Type name: application 943 Subtype name: voucher-cms+cbor 944 Required parameters: none 945 Optional parameters: none 946 Encoding considerations: CMS-signed CBOR vouchers are CBOR 947 encoded. 948 Security considerations: See Security Considerations, Section 949 Interoperability considerations: The format is designed to be 950 broadly interoperable. 951 Published specification: THIS RFC. 952 Applications that use this media type: ANIMA, 6tisch, and other 953 zero-touch imprinting systems 954 Additional information: 955 Magic number(s): None 956 File extension(s): .vch 957 Macintosh file type code(s): none 958 Person & email address to contact for further information: IETF 959 ANIMA WG 960 Intended usage: LIMITED 961 Restrictions on usage: NONE 962 Author: ANIMA WG 963 Change controller: IETF 964 Provisional registration? (standards tree only): NO 966 9.6.2. application/voucher-cose+cbor 967 Type name: application 968 Subtype name: voucher-cose+cbor 969 Required parameters: none 970 Optional parameters: cose-type 971 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 972 signed with one signer. 973 Security considerations: See Security Considerations, Section 974 Interoperability considerations: The format is designed to be 975 broadly interoperable. 976 Published specification: THIS RFC. 977 Applications that use this media type: ANIMA, 6tisch, and other 978 zero-touch imprinting systems 979 Additional information: 980 Magic number(s): None 981 File extension(s): .vch 982 Macintosh file type code(s): none 983 Person & email address to contact for further information: IETF 984 ANIMA WG 985 Intended usage: LIMITED 986 Restrictions on usage: NONE 987 Author: ANIMA WG 988 Change controller: IETF 989 Provisional registration? (standards tree only): NO 991 9.7. CoAP Content-Format Registry 993 Additions to the sub-registry "CoAP Content-Formats", within the 994 "CoRE Parameters" registry are needed for two media types. These can 995 be registered either in the Expert Review range (0-255) or IETF 996 Review range (256-9999). 998 Media type mime type Encoding ID References 999 ---------------------------- ----------- --------- ---- ---------- 1000 application/voucher-cms+cbor - - CBOR TBD2 [This RFC] 1001 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 1003 10. Acknowledgements 1005 We are very grateful to Jim Schaad for explaining COSE and CMS 1006 choices. Also thanks to Jim Schaad for correctinging earlier version 1007 of the COSE Sign1 objects. 1009 Michel Veillette did extensive work on pyang to extend it to support 1010 the SID allocation process, and this document was among the first 1011 users. 1013 We are grateful for the suggestions done by Esko Dijk. 1015 11. Changelog 1017 -06 New SID values assigned; regenerated examples 1019 -04 voucher and request-voucher MUST be signed examples for signed 1020 request are added in appendix IANA SID registration is updated SID 1021 values in examples are aligned signed cms examples aligned with new 1022 SIDs 1024 -03 1026 Examples are inverted. 1028 -02 1030 Example of requestvoucher with unsigned appllication/cbor is added 1031 attributes of voucher "refined" to optional 1032 CBOR serialization of vouchers improved 1033 Discovery port numbers are specified 1035 -01 1037 application/json is optional, application/cbor is compulsory 1038 Cms and cose mediatypes are introduced 1040 12. References 1042 12.1. Normative References 1044 [I-D.ietf-ace-coap-est] 1045 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 1046 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 1047 est-18 (work in progress), January 2020. 1049 [I-D.ietf-anima-bootstrapping-keyinfra] 1050 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1051 and K. Watsen, "Bootstrapping Remote Secure Key 1052 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1053 keyinfra-34 (work in progress), January 2020. 1055 [I-D.ietf-core-sid] 1056 Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item 1057 iDentifier (SID)", draft-ietf-core-sid-08 (work in 1058 progress), January 2020. 1060 [I-D.ietf-core-yang-cbor] 1061 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 1062 Data Modeled with YANG", draft-ietf-core-yang-cbor-11 1063 (work in progress), September 2019. 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, 1067 DOI 10.17487/RFC2119, March 1997, 1068 . 1070 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1071 DOI 10.17487/RFC3688, January 2004, 1072 . 1074 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1075 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1076 . 1078 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1079 the Network Configuration Protocol (NETCONF)", RFC 6020, 1080 DOI 10.17487/RFC6020, October 2010, 1081 . 1083 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1084 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1085 October 2013, . 1087 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1088 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1089 . 1091 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1092 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1093 . 1095 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1096 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1097 May 2017, . 1099 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1100 "A Voucher Artifact for Bootstrapping Protocols", 1101 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1102 . 1104 12.2. Informative References 1106 [COSE-registry] 1107 IANA, ., "CBOR Object Signing and Encryption (COSE) 1108 registry", 2017, 1109 . 1111 [I-D.ietf-netmod-yang-tree-diagrams] 1112 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1113 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1114 February 2018. 1116 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1117 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1118 . 1120 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1121 "Enrollment over Secure Transport", RFC 7030, 1122 DOI 10.17487/RFC7030, October 2013, 1123 . 1125 Appendix A. EST messages to EST-coaps 1127 This section extends the examples from Appendix A of 1128 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1129 the enrollstatus example. 1131 A.1. enrollstatus 1133 A coaps enrollstatus message can be : 1135 GET coaps://[192.0.2.1:8085]/est/es 1137 The corresponding coap header fields are shown below. 1139 Ver = 1 1140 T = 0 (CON) 1141 Code = 0x01 (0.01 is GET) 1142 Options 1143 Option (Uri-Path) 1144 Option Delta = 0xb (option nr = 11) 1145 Option Length = 0x3 1146 Option Value = "est" 1147 Option (Uri-Path) 1148 Option Delta = 0x0 (option nr = 11) 1149 Option Length = 0x2 1150 Option Value = "es" 1151 Payload = [Empty] 1153 The Uri-Host and Uri-Port Options are omitted because they coincide 1154 with the transport protocol destination address and port 1155 respectively. 1157 A 2.05 Content response with an unsigned voucher status (ct=60) will 1158 then be: 1160 2.05 Content (Content-Format: application/cbor) 1162 With CoAP fields and payload: 1164 Ver=1 1165 T=2 (ACK) 1166 Code = 0x45 (2.05 Content) 1167 Options 1168 Option1 (Content-Format) 1169 Option Delta = 0xC (option nr 12) 1170 Option Length = 0x2 1171 Option Value = 60 (application/cbor) 1173 Payload (CBOR diagnostic) = 1174 { 1175 "version":"1", 1176 "Status": 1, / 1 = Success, 0 = Fail / 1177 "Reason":"Informative human readable message", 1178 "reason-context": "Additional information" 1179 } 1181 The binary payload is: 1183 A46776657273696F6E6131665374617475730166526561736F6E7822 1184 496E666F726D61746976652068756D616E207265616461626C65206D 1185 6573736167656e726561736F6E2D636F6E74657874 1186 764164646974696F6E616C20696E666F726D6174696F6E 1188 The binary payload disassembles to the above CBOR diagnostic code. 1190 A.2. voucher_status 1192 A coaps voucher_status message can be: 1194 GET coaps://[2001:db8::2:1]:61616]/est/vs 1196 A 2.05 Content response with a non signed CBOR voucher status (ct=60) 1197 will then be: 1199 2.05 Content (Content-Format: application/cbor) 1200 Payload = 1201 A46776657273696F6E6131665374617475730166526561736F6E7822 1202 496E666F726D61746976652068756D616E207265616461626C65206D 1203 6573736167656e726561736F6E2D636F6E74657874 1204 764164646974696F6E616C20696E666F726D6174696F6E 1206 A.3. requestvoucher 1208 Signed request-voucher-request payloads are sent from pledge to 1209 Registrar, as explained in Section 5.2 of 1210 [I-D.ietf-anima-bootstrapping-keyinfra]. 1212 A.3.1. signed requestvoucher 1214 A CMS signed requestvoucher message from JRC to MASA is shown below. 1215 It would be CoAP POSTED to /est/rv. 1217 POST coaps://[2001:db8::2:1]:61616]/est/rv 1218 (Content-Format: application/voucher-cms+cbor) 1220 The payload would be in binary, but is presented in base64 in this 1221 document. 1223 MIIDugYJKoZIhvcNAQcCoIIDqzCCA6cCAQExDTALBglghkgBZQMEAgEwCwYJ 1224 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1225 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1226 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1227 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1228 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1229 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1230 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1231 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1232 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1233 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1234 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1235 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1236 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1237 3m00kjYxggE/MIIBOwIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1238 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1239 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1240 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1241 DTE5MDQwODEwNDgzNlowLwYJKoZIhvcNAQkEMSIEILEdCTOLs2Zy7w3LgvSZ 1242 XZEadz3LbznoFBs6FMFN91RaMAoGCCqGSM49BAMCBEcwRQIgASjDsIpr0tW/ 1243 n6dRHqvvqsqgZlHbtFnErUbWfhS0KD4CIQDDUEqc5wTmRGf0adEQVQzqmIgh 1244 MEgF10vqXv02gL1jLw== 1245 A 2.04 Changed response returning CBOR voucher signed with a cms 1246 structure(ct=TBD2) will then be: 1248 2.04 Changed (Content-Format: application/voucher-cms+cbor) 1250 MIIDuwYJKoZIhvcNAQcCoIIDrDCCA6gCAQExDTALBglghkgBZQMEAgEwCwYJ 1251 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1252 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1253 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1254 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1255 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1256 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1257 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1258 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1259 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1260 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1261 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1262 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1263 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1264 3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1265 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1266 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1267 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1268 DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he 1269 uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG 1270 kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX 1271 hlG/g+OgTUftYMJ32so= 1273 A.4. requestauditing 1275 A coaps requestauditing message contains the signed CBOR voucher : 1277 POST coaps://[2001:db8::2:1]:61616]/est/ra 1278 (Content-Format: application/voucher-cms+cbor) 1279 Payload = 1280 TO BE FILLED 1282 A 2.05 Content response returning a log of the voucher (ct=60) will 1283 then be: 1285 2.05 Content (Content-Format: application/cbor) 1286 Payload = 1287 { 1288 "version":"1", 1289 "events":[ 1290 { 1291 "date":"", 1292 "domainID":"", 1293 "nonce":"" 1294 "assertion":"" 1295 "truncated":"" 1296 }, 1297 { 1298 "date":"", 1299 "domainID":"", 1300 "nonce":"" 1301 "assertion":"" 1302 } 1303 ], 1304 "truncation": { 1305 "nonced duplicates": "", 1306 "nonceless duplicates": "", 1307 "arbitrary": "" 1308 } 1309 } 1311 [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary] 1313 Appendix B. Signed voucher-request examples 1315 B.1. CMS signed voucher-request example 1317 The voucher-request example, visualized in CBOR diagnostic notation 1318 in Section 6.1.4 is shown as a hexadecimal dump of the binary file. 1320 a11909c5a90274323031362d31302d30375431393a33313a34325a0474323031 1321 362d31302d32315431393a33313a34325a01020d6d4a414441313233343536 1322 373839054401020d0f0a4401020d0f03f50674323031372d31302d30375431 1323 393a33313a34325a0c4401020d0f 1325 The voucher-request example has been signed by using the WT1234 1326 certificate and key pair shown in Appendix C of 1327 [I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher- 1328 request leads to a binary signed voucher-request, shown with a 1329 hexadecimal representation shown in the payload of the request part 1330 of Appendix A.3.1 and Appendix A.4. 1332 The breakdown of the CMS signed binary voucher-request file is 1333 visualized below: 1335 CMS_ContentInfo: 1336 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1337 d.signedData: 1338 version: 1 1339 digestAlgorithms: 1340 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1341 parameter: 1342 encapContentInfo: 1343 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1344 eContent: 1345 certificates: 1346 d.certificate: 1347 cert_info: 1348 version: 2 1349 serialNumber: 9112578475118446130 1350 signature: 1351 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1352 parameter: 1353 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1354 CN=802.1AR CA 1355 validity: 1356 notBefore: Jan 31 11:29:16 2019 GMT 1357 notAfter: Dec 31 23:59:59 9999 GMT 1358 subject: C=US, ST=CA, L=LA, O=example Inc, 1359 OU=IoT/serialNumber=Wt1234 1360 key: 1361 algor: 1362 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1363 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1364 public_key: (0 unused bits) 1365 0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf 1366 000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15 1367 001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df 1368 002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8 1369 0038 - 16 a2 b2 3b 56 38 e5 9f-d9 1370 issuerUID: 1371 subjectUID: 1372 extensions: 1373 object: X509v3 Basic Constraints (2.5.29.19) 1374 critical: BOOL ABSENT 1375 value: 1376 0000 - 30 1377 0002 - 1379 object: X509v3 Subject Key Identifier (2.5.29.14) 1380 critical: BOOL ABSENT 1381 value: 1382 0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0 1383 000d - ac 76 07 77 ad 66 5d 02-a0 1385 object: X509v3 Authority Key Identifier (2.5.29.35) 1386 critical: BOOL ABSENT 1387 value: 1388 0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a 1389 000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60 1391 object: X509v3 Key Usage (2.5.29.15) 1392 critical: TRUE 1393 value: 1394 0000 - 03 02 05 a0 1396 object: X509v3 Subject Alternative Name (2.5.29.17) 1397 critical: BOOL ABSENT 1398 value: 1399 0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08 1400 000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4 1401 001a - 3b 0a 01 04 04 01 02 03-04 1402 sig_alg: 1403 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1404 parameter: 1405 signature: (0 unused bits) 1406 0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c 1407 000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17 1408 001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c 1409 002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20 1410 003c - f1 50 64 21 18 8a 0a de-6d 34 92 36 1411 crls: 1412 1413 signerInfos: 1414 version: 1 1415 d.issuerAndSerialNumber: 1416 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1417 CN=802.1AR CA 1418 serialNumber: 9112578475118446130 1419 digestAlgorithm: 1420 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1421 parameter: 1422 signedAttrs: 1423 object: contentType (1.2.840.113549.1.9.3) 1424 value.set: 1425 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1427 object: signingTime (1.2.840.113549.1.9.5) 1428 value.set: 1429 UTCTIME:Jul 3 08:53:30 2019 GMT 1431 object: messageDigest (1.2.840.113549.1.9.4) 1432 value.set: 1433 OCTET STRING: 1434 0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d 1435 000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f 1436 001a - 0b 4f 44 9e 25 1437 0020 - 1438 signatureAlgorithm: 1439 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1440 parameter: 1441 signature: 1442 0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64 1443 000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf 1444 001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4 1445 002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af 1446 003c - 2b 59 16 cc 36 63 e7 91-89 39 df df 1447 unsignedAttrs: 1448 1450 Appendix C. COSE examples 1452 These examples are from the https://minerva.sandelman.ca/ reference 1453 code, using the unit test case key pairs, with a flow between pledge 1454 ("reach" code), JRC ("fountain") code, and MASA ("highway") code. 1455 This example comes from the spec/files/product/00-D0-E5-F2-00-03 1456 directory. 1458 C.1. Device, Registrar and MASA keys 1460 This first section documents the public and private keys used in the 1461 subsequent test vectors below. These keys come from test code and 1462 are not used in any production system, and should only be used only 1463 to validate implementations. 1465 C.1.1. Device IDevID certificate 1466 Certificate: 1467 Data: 1468 Version: 3 (0x2) 1469 Serial Number: 787697345 (0x2ef34ec1) 1470 Signature Algorithm: ecdsa-with-SHA256 1471 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = h 1472 ighway-test.example.com CA 1473 Validity 1474 Not Before: Feb 14 17:05:09 2019 GMT 1475 Not After : Dec 31 00:00:00 2999 GMT 1476 Subject: serialNumber = 00-D0-E5-F2-00-03 1477 Subject Public Key Info: 1478 Public Key Algorithm: id-ecPublicKey 1479 Public-Key: (256 bit) 1480 pub: 1481 04:82:c4:28:5b:7c:f0:37:18:c7:90:14:dc:cb:f4: 1482 4d:7e:b0:00:ed:c0:de:bd:4d:25:55:4e:35:f9:d5: 1483 6a:57:14:b4:94:af:ce:6d:53:c8:60:c2:ce:53:3f: 1484 2c:1b:42:f1:c0:8b:5f:c1:7b:3d:f3:29:54:87:46: 1485 86:a4:0c:8b:b7 1486 ASN1 OID: prime256v1 1487 NIST CURVE: P-256 1488 X509v3 extensions: 1489 X509v3 Subject Key Identifier: 1490 C8:A3:87:72:82:82:E6:EA:90:D0:E1:81:BC:C7:51:08:78:0 1491 F:D7:52 1492 X509v3 Basic Constraints: 1493 CA:FALSE 1494 X509v3 Subject Alternative Name: 1495 othername: 1496 1.3.6.1.4.1.46930.2: 1497 ..highway-test.example.com:9443 1498 Signature Algorithm: ecdsa-with-SHA256 1499 30:65:02:31:00:b2:9a:7a:1a:74:20:8f:e9:e0:5d:fc:af:d6: 1500 4a:80:1f:66:e3:bf:17:2e:3e:07:87:39:be:65:bd:94:57:71: 1501 1f:df:e5:fc:4d:ef:96:8a:3a:03:5b:d1:ca:a1:72:55:a3:02: 1502 30:13:43:08:a4:af:c8:28:19:d2:a0:93:3d:ed:53:fa:09:7d: 1503 76:9c:b7:0b:95:2b:8f:2f:b4:fa:87:02:ec:b4:2d:19:92:5b: 1504 b2:bb:79:04:63:6e:17:0e:79:8a:65:f5:a3 1506 C.1.2. Device private key 1508 -----BEGIN EC PRIVATE KEY----- 1509 MHcCAQEEIA1sa0l4bkj/rJxPUN1bKSBNYolVVzx+T28wo60cYpuaoAoGCCqGSM49 1510 AwEHoUQDQgAEgsQoW3zwNxjHkBTcy/RNfrAA7cDevU0lVU41+dVqVxS0lK/ObVPI 1511 YMLOUz8sG0LxwItfwXs98ylUh0aGpAyLtw== 1512 -----END EC PRIVATE KEY----- 1514 C.1.3. Registrar Certificate 1516 -----BEGIN CERTIFICATE----- 1517 MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxMRIwEAYKCZImiZPyLGQBGRYC 1518 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xQDA+BgNVBAMMNyM8U3lzdGVt 1519 VmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4gVW5zdHJ1bmcgRm91bnRhaW4gQ0Ew 1520 HhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQB 1521 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2Fs 1522 aG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lI 1523 noEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqj 1524 DTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQ 1525 XHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKi 1526 IiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ== 1527 -----END CERTIFICATE----- 1529 C.1.4. Registrar private key 1531 -----BEGIN EC PRIVATE KEY----- 1532 MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 1533 AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E 1534 jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== 1535 -----END EC PRIVATE KEY----- 1537 C.1.5. MASA Certificate 1539 -----BEGIN CERTIFICATE----- 1540 MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h 1541 ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE 1542 AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX 1543 DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh 1544 cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l 1545 eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5 1546 4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf 1547 WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA 1548 vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6 1549 AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP 1550 D0jJ 1551 -----END CERTIFICATE----- 1553 C.1.6. MASA private key 1555 -----BEGIN EC PRIVATE KEY----- 1556 MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 1557 AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ 1558 gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== 1559 -----END EC PRIVATE KEY----- 1561 C.2. COSE signed requestvoucher with registrar certificate pinned 1563 EDNote: These examples do not parse 1565 This voucher request has been signed by the pledge, and has been sent 1566 to the JRC over CoAPS. This example uses the proximity-registrar- 1567 cert mechanism to request a voucher that pins the certificate of the 1568 registrar. 1570 This is the CBOR diagnostic format, folded to 60 characters: 1572 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 1573 D1E49970A5130302D44302D45352D46322D30302D303307765F715674477 1574 738565342626C65394D34557036354C770C5901D4308201D030820157A00 1575 30201020204228ECD27300A06082A8648CE3D040302306E31123010060A0 1576 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1577 0340F4E6D0F9F702553FA53BE572ACF0EED858275B6AC75994332FB25FB3 1578 A54411E9FA02E6F75FD1AADB7EA9A61F5409E02303E615E75C8F07432A59 1579 0C8D48798BEDA1EB49E5E7D8E0EA118BD17A02D02F0313D144816002F756 1580 B528ABD1B0ADB749D', h'96B82530AC57650346C2BFFB5A6CC16B28F16F 1581 ACFE5A2FD1BCF3D5F5D62733F7F7812D67D43BE1CF9906E356FB0C2BDD36 1582 777FD7DBAE22B8CEB07D51D8F55AD3']) 1584 This is the raw binary, shown as hex dump: 1586 0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G 1587 Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD 1588 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1589 NA9ObQ+fcCVT+lO+VyrPDu2FgnW2rHWZQzL7Jfs6VEEen6Aub3X9Gq236pph 1590 9UCeAjA+YV51yPB0MqWQyNSHmL7aHrSeXn2ODqEYvRegLQLwMT0USBYAL3Vr 1591 Uoq9GwrbdJ1YQJa4JTCsV2UDRsK/+1pswWso8W+s/lov0bzz1fXWJzP394Et 1592 Z9Q74c+ZBuNW+wwr3TZ3f9fbriK4zrB9Udj1WtM= 1594 C.3. COSE signed parboiled requestvoucher 1596 These example do not parse 1598 This voucher request has been signed by the JRC using the private key 1599 from Appendix C.1.4. Contained within this voucher request is the 1600 pledge voucher request above. 1602 This is the CBOR diagnostic format, folded to 60 characters: 1604 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 1605 9DD3BFD0A5130302D44302D45352D46322D30302D303307765F715674477 1606 738565342626C65394D34557036354C770B590266D28441A0A059021CA11 1607 A000F46C2A5016970726F78696D69747902C11A5D1E49970A5130302D443 1608 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1609 AADB7EA9A61F5409E02303E615E75C8F07432A590C8D48798BEDA1EB49E5 1610 E7D8E0EA118BD17A02D02F0313D144816002F756B528ABD1B0ADB749D584 1611 096B82530AC57650346C2BFFB5A6CC16B28F16FACFE5A2FD1BCF3D5F5D62 1612 733F7F7812D67D43BE1CF9906E356FB0C2BDD36777FD7DBAE22B8CEB07D5 1613 1D8F55AD3', h'EAE868ECC176883766C5DC5BA5B8DCA25DAB3C2E56A551 1614 CE5705B793914348E1F93C2B81E88CCBE28E90800F66945EFBBECE4F741D 1615 0EDE18EB1008EF7E9A279C']) 1617 This is the raw binary, encoded in base64: 1619 0oRBoKBZAq6hGgAPRsKlAWlwcm94aW1pdHkCwRpZ3Tv9ClEwMC1EMC1FNS1G 1620 Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwtZAmbShEGgoFkCHKEa 1621 AA9GwqUBaXByb3hpbWl0eQLBGl0eSZcKUTAwLUQwLUU1LUYyLTAwLTAzB3Zf 1622 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1623 U75XKs8O7YWCdbasdZlDMvsl+zpUQR6foC5vdf0arbfqmmH1QJ4CMD5hXnXI 1624 8HQypZDI1IeYvtoetJ5efY4OoRi9F6AtAvAxPRRIFgAvdWtSir0bCtt0nVhA 1625 lrglMKxXZQNGwr/7WmzBayjxb6z+Wi/RvPPV9dYnM/f3gS1n1Dvhz5kG41b7 1626 DCvdNnd/19uuIrjOsH1R2PVa01hA6uho7MF2iDdmxdxbpbjcol2rPC5WpVHO 1627 VwW3k5FDSOH5PCuB6IzL4o6QgA9mlF77vs5PdB0O3hjrEAjvfponnA== 1629 C.4. COSE signed voucher 1631 The resulting voucher is created by the MASA and returned via the JRC 1632 to the Pledge. It is signed by the MASA's private key Appendix C.1.6 1633 and can be verified by the pledge using the MASA's publie key. 1635 This is the CBOR diagnostic format, folded to 60 characters: 1637 18([h'A0', {}, h'A11A000F468CA505666C6F6767656406C11A5D1E499 1638 A0E7130302D44302D45352D46322D30302D30330B765F715674477738565 1639 342626C65394D34557036354C770C7902744D49494230544343415661674 1640 177494241674942416A414B42676771686B6A4F50515144417A42784D524 1641 9774541594B435A496D695A50794C4751424752594359324578475441584 1642 2676F4A6B69614A6B2F49735A41455A46676C7A5957356B5A57787459573 1643 4785144412B42674E5642414D4D4E794D3855336C7A64475674566D46796 1644 1574669624755364D4867774D4441774D4441774E4759354D5446684D443 1645 4675657357A64484A31626D6367526D3931626E526861573467513045774 1646 868634E4D5463784D5441334D6A4D304E5449345768634E4D546B784D544 1647 1334D6A4D304E544934576A42444D5249774541594B435A496D695A50794 1648 C47514247525943593245784754415842676F4A6B69614A6B2F49735A414 1649 55A46676C7A5957356B5A57787459573478456A415142674E5642414D4D4 1650 3577876593246736147397A6444425A4D424D4742797147534D343941674 1651 54743437147534D34394177454841304941424A5A6C5548493075702F6C3 1652 3655A6639764342622B6C496E6F454D45676337526F2B585A43746A41493 1653 0434431664A664A522F68497979446D48577959694E46625243483966796 1654 172666B7A67583470307A54697A716A4454414C4D416B474131556445775 1655 1434D414177436759494B6F5A497A6A304541774D44615141775A6749784 1656 14C514D4E75726638747635306C524F443544515848454F4A4A4E5733515 1657 632673951456444536B324D592B416F537242536D47534E6A68346F6C454 1658 F6845754C674978414A346E57664E772B426A625A6D4B694969554563547 1659 7484D68475658614D48592F46376E333977774B634242534F6E644E50714 1660 3704F454C6C36627133435A71513D3D', h'7468FB16A4035FDAF510DBF5 1661 A88F67B6FB849CFBA8B094B77AD5248900E4BCD6E892FE74B39AB787637B 1662 121944BED4D1CB4B8DC8F59212EAC2AD20469C71C1F6']) 1664 This is the raw binary, encoded in base64: 1666 0oRBoKBZArmhGgAPRoylBWZsb2dnZWQGwRpdHkmaDnEwMC1EMC1FNS1GMi0w 1667 MC0wMwt2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwx5AnRNSUlCMFRDQ0FWYWdB 1668 d0lCQWdJQkFqQUtCZ2dxaGtqT1BRUURBekJ4TVJJd0VBWUtDWkltaVpQeUxH 1669 UUJHUllDWTJFeEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0 1670 eFFEQStCZ05WQkFNTU55TThVM2x6ZEdWdFZtRnlhV0ZpYkdVNk1IZ3dNREF3 1671 TURBd05HWTVNVEZoTUQ0Z1ZXNXpkSEoxYm1jZ1JtOTFiblJoYVc0Z1EwRXdI 1672 aGNOTVRjeE1UQTNNak0wTlRJNFdoY05NVGt4TVRBM01qTTBOVEk0V2pCRE1S 1673 SXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFF 1674 WkZnbHpZVzVrWld4dFlXNHhFakFRQmdOVkJBTU1DV3h2WTJGc2FHOXpkREJa 1675 TUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wz 1676 ZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt 1677 SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dBMVVkRXdR 1678 Q01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUwbFJP 1679 RDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP 1680 aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24z 1681 OXd3S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09WEB0aPsWpANf2vUQ2/Wo 1682 j2e2+4Sc+6iwlLd61SSJAOS81uiS/nSzmreHY3sSGUS+1NHLS43I9ZIS6sKt 1683 IEacccH2 1685 C.5. COSE signed request voucher 1687 The headecimal dump of request-voucher shown in Appendix B.1 is used 1688 for this example. The cose sign1 object of Figure 1 provides the 1689 structure of the cose sign1 example. To identify the public key a 1690 hash of the public key is made using murmur3 with seed 42. 1692 public key: 1693 84 44 de 3a b7 b5 a0 2f 20 ed e7 80 1a f0 76 d6 52 0a e5 c8 a1 1694 04 41 61 b2 64 57 fe 0e ae 08 4d 1696 murmur3 hash of public key: 0x4727e669 or 1193797225 1698 Using the values "kid" = 4, EDdsa = -8, "alg" = 2, COSE_Sign1 = 18, 1699 and using the murmur3 hash value for the "kid" parameter, the CBOR 1700 object is: 1702 18([h'A10127', {4: 1193797225}, 1703 h'A11909C5A90274323031362D31302D30375431393A33313A34325A04743 1704 23031362D31302D32315431393A33313A34325A01020D6D4A414441313233 1705 343536373839054401020D0F0A4401020D0F03F50674323031372D31302D3 1706 0375431393A33313A34325A0C4401020D0F', 1707 h'955D82A26B7C0869EE8FE5A09EE3D68DDFFE8FE39E3BCADFA80F2F9A6E13F 1708 F0349A2CA131C8F6A9AAF7780BAB671F63CBB158EC17322323C1AB82B1CDC 1709 B62A06']) 1711 The corresponding hexadecimal dump is: 1713 d28443a10127a1041a4727e669586ca11909c5a90274323031362d31302d 1714 30375431393a33313a34325a0474323031362d31302d32315431393a3331 1715 3a34325a01020d6d4a414441313233343536373839054401020d0f0a4401 1716 020d0f03f50674323031372d31302d30375431393a33313a34325a0c4401 1717 020d0f5840955d82a26b7c0869ee8fe5a09ee3d68ddffe8fe39e3bcadfa8 1718 0f2f9a6e13ff0349a2ca131c8f6a9aaf7780bab671f63cbb158ec1732232 1719 3c1ab82b1cdcb62a06 1721 Authors' Addresses 1723 Michael Richardson 1724 Sandelman Software Works 1726 Email: mcr+ietf@sandelman.ca 1728 Peter van der Stok 1729 vanderstok consultancy 1731 Email: consultancy@vanderstok.org 1732 Panos Kampanakis 1733 Cisco Systems 1735 Email: pkampana@cisco.com