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