idnits 2.17.1 draft-ietf-anima-constrained-voucher-05.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 436 has weird spacing: '...ndatory false...' == Line 440 has weird spacing: '...ndatory false...' == Line 686 has weird spacing: '...ndatory false...' == Line 690 has weird spacing: '...ndatory false...' -- The document date (July 08, 2019) is 1726 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ThisRFC' is mentioned on line 924, but not defined == Missing Reference: 'This RFC' is mentioned on line 996, but not defined == Missing Reference: 'Empty' is mentioned on line 1179, but not defined == Unused Reference: 'I-D.ietf-ace-cbor-web-token' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 1101, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-12 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-22 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-06 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' ** 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 (~~), 19 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: January 9, 2020 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 July 08, 2019 10 Constrained Voucher Artifacts for Bootstrapping Protocols 11 draft-ietf-anima-constrained-voucher-05 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 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 19 81 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . 27 100 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 27 101 A.2. requestvoucher . . . . . . . . . . . . . . . . . . . . . 28 102 A.2.1. signed requestvoucher . . . . . . . . . . . . . . . . 29 103 A.3. requestauditing . . . . . . . . . . . . . . . . . . . . . 30 104 Appendix B. Signed voucher-request examples . . . . . . . . . . 32 105 B.1. CMS signed voucher-request example . . . . . . . . . . . 32 106 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 35 107 C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 35 108 C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 35 109 C.1.2. Device private key . . . . . . . . . . . . . . . . . 36 110 C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 37 111 C.1.4. Registrar private key . . . . . . . . . . . . . . . . 37 112 C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 37 113 C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 37 114 C.2. COSE signed requestvoucher with registrar certificate 115 pinned . . . . . . . . . . . . . . . . . . . . . . . . . 38 116 C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 38 117 C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 39 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 Enrollment of new nodes into constrained networks with constrained 123 nodes present unique challenges. 125 There are bandwidth and code space issues to contend. A solution 126 such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in 127 terms of code space or bandwidth required. 129 This document defines a constrained version of [RFC8366]. Rather 130 than serializing the YANG definition in JSON, it is serialized into 131 CBOR ([RFC7049]). 133 This document follows a similar, but not identical structure as 134 [RFC8366]. Some sections are left out entirely. Additional sections 135 have been added concerning: 137 1. Addition of voucher-request specification as defined in 138 [I-D.ietf-anima-bootstrapping-keyinfra], 140 2. Addition to [I-D.ietf-ace-coap-est] of voucher transport requests 141 over CoAP. 143 The CBOR definitions for this constrained voucher format are defined 144 using the mechanism describe in [I-D.ietf-core-yang-cbor] using the 145 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 146 convert YANG documents into an list of SID keys is still in its 147 infancy, the table of SID values presented here should be considered 148 normative rather than the output of the pyang tool. 150 Two methods of signing the resulting CBOR object are described in 151 this document: 153 1. One is CMS [RFC5652]. 155 2. The other is COSE_Sign1 [RFC8152] objects. 157 2. Terminology 159 The following terms are defined in [RFC8366], and are used 160 identically as in that document: artifact, imprint, domain, Join 161 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 162 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 164 3. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 4. Survey of Voucher Types 174 [RFC8366] provides for vouchers that assert proximity, that 175 authenticate the registrar and that include different amounts of 176 anti-replay protection. 178 This document does not make any extensions to the types of vouchers. 180 Time based vouchers are included in this definition, but given that 181 constrained devices are extremely unlikely to have accurate time, 182 their use is very unlikely. Most users of these constrained vouchers 183 will be online and will use live nonces to provide anti-replay 184 protection. 186 [RFC8366] defined only the voucher artifact, and not the Voucher 187 Request artifact, which was defined in 188 [I-D.ietf-anima-bootstrapping-keyinfra]. 190 This document defines both a constrained voucher and a constrained 191 voucher-request. They are presented in the order voucher-request, 192 followed by a voucher response as this is the time order that they 193 occur. 195 This document defines both CMS-signed voucher requests and responses, 196 and COSE signed voucher requests and responses. The use of CMS 197 signatures implies the use of PKIX format certificates. The pinned- 198 domain-cert present in such a voucher, is the certificate of the 199 Registrar. 201 The constrained voucher and constrained voucher request MUST be 202 signed. 204 The use of the two signing formats permit the use of both PKIX format 205 certificates, and raw public keys (RPK). When RPKs are used, the 206 voucher produced by the MASA pins the raw public key of the 207 Registrar: the pinned-domain-subject-public-key-info in such a 208 voucher, is the raw public key of the Registrar. This is described 209 in the YANG definition for the constrained voucher. 211 5. Discovery and URI 213 This section describes the BRSKI extensions to EST-coaps 214 [I-D.ietf-ace-coap-est] to transport the voucher between registrar, 215 proxy and pledge over CoAP. The extensions are targeted to low- 216 resource networks with small packets. Saving header space is 217 important and the EST-coaps URI is shorter than the EST URI. 219 The presence and location of (path to) the management data are 220 discovered by sending a GET request to "/.well-known/core" including 221 a resource type (RT) parameter with the value "ace.est" [RFC6690]. 222 Upon success, the return payload will contain the root resource of 223 the EST resources. It is up to the implementation to choose its root 224 resource; throughout this document the example root resource /est is 225 used. 227 The EST-coaps server URIs differ from the EST URI by replacing the 228 scheme https by coaps and by specifying shorter resource path names: 230 coaps://www.example.com/est/short-name 232 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 233 corresponding paths which are supported by EST. Table 1 provides the 234 mapping from the BRSKI extension URI path to the EST-coaps URI path. 236 +------------------+-----------+ 237 | BRSKI | EST-coaps | 238 +------------------+-----------+ 239 | /requestvoucher | /rv | 240 | | | 241 | /voucher_status | /vs | 242 | | | 243 | /enrollstatus | /es | 244 | | | 245 | /requestauditlog | /ra | 246 +------------------+-----------+ 248 Table 1: BRSKI path to EST-coaps path 250 /requestvoucher, /voucher_status and /enrollstatus are needed between 251 pledge and Registrar. 253 When discovering the root path for the EST resources, the server MAY 254 return the full resource paths and the used content types. This is 255 useful when multiple content types are specified for EST-coaps 256 server. For example, the following more complete response is 257 possible. 259 REQ: GET /.well-known/core?rt=ace.est* 261 RES: 2.05 Content 262 ; rt="ace.est" 263 ; rt="ace.est/rv";ct=TBD2 TBD3 264 ; rt="ace.est/vs";ct=50 60 265 ; rt="ace.est/es";ct=50 60 266 ; rt="ace.est/ra";ct=TBD2 TBD3 268 The return of the content-types allows the client to choose the most 269 appropriate one from multiple content types. 271 ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and 272 ct=TBD3 stands for Content-Format "application/voucher-cose+cbor". 274 Content-Formats TBD2 and TBD3 are defined in this document. 276 The Content-Format ("application/json") 50 MAY be supported. 277 Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be 278 supported. 280 6. Artifacts 282 This section describes the abstract (tree) definition as explained in 283 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 284 level view of the contents of each artifact. 286 Then the assigned SID values are presented. These have been assigned 287 using the rules in [I-D.ietf-core-sid], with an allocation that was 288 made via the http://comi.space service. 290 6.1. Voucher Request artifact 292 6.1.1. Tree Diagram 294 The following diagram is largely a duplicate of the contents of 295 [RFC8366], with the addition of proximity-registrar-subject-public- 296 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 298 prior-signed-voucher-request is only used between the Registrar and 299 the MASA. proximity-registrar-subject-public-key-info replaces 300 proximity-registrar-cert for the extremely constrained cases. 302 module: ietf-constrained-voucher-request 304 grouping voucher-request-constrained-grouping 305 +-- voucher 306 +-- created-on? 307 | yang:date-and-time 308 +-- expires-on? 309 | yang:date-and-time 310 +-- assertion 311 | enumeration 312 +-- serial-number 313 | string 314 +-- idevid-issuer? 315 | binary 316 +-- pinned-domain-cert? 317 | binary 318 +-- domain-cert-revocation-checks? 319 | boolean 320 +-- nonce? 321 | binary 322 +-- last-renewal-date? 323 | yang:date-and-time 324 +-- proximity-registrar-subject-public-key-info? 325 | binary 326 +-- proximity-registrar-sha256-of-subject-public-key-info? 327 | binary 328 +-- proximity-registrar-cert? 329 | binary 330 +-- prior-signed-voucher-request? 331 binary 333 6.1.2. SID values 334 SID Assigned to 335 --------- -------------------------------------------------- 336 1001154 data /ietf-constrained-voucher-request:voucher 337 1001155 data .../assertion 338 1001156 data .../created-on 339 1001157 data .../domain-cert-revocation-checks 340 1001158 data .../expires-on 341 1001159 data .../idevid-issuer 342 1001160 data .../last-renewal-date 343 1001161 data /ietf-constrained-voucher-request:voucher/nonce 344 1001162 data .../pinned-domain-cert 345 1001165 data .../prior-signed-voucher-request 346 1001166 data .../proximity-registrar-cert 347 1001167 data mity-registrar-sha256-of-subject-public-key-info 348 1001163 data .../proximity-registrar-subject-public-key-info 349 1001164 data .../serial-number 351 6.1.3. YANG Module 353 In the constrained-voucher-request YANG module, the voucher is 354 "augmented" within the "used" grouping statement such that one 355 continuous set of SID values is generated for the constrained- 356 voucher-request module name, all voucher attributes, and the 357 constrained-voucher-request attribute. Two attributes of the voucher 358 are "refined" to be optional. 360 file "ietf-constrained-voucher-request@2018-09-01.yang" 361 module ietf-constrained-voucher-request { 362 yang-version 1.1; 364 namespace 365 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 366 prefix "constrained"; 368 import ietf-restconf { 369 prefix rc; 370 description 371 "This import statement is only present to access 372 the yang-data extension defined in RFC 8040."; 373 reference "RFC 8040: RESTCONF Protocol"; 374 } 376 import ietf-voucher { 377 prefix "v"; 378 } 380 organization 381 "IETF ANIMA Working Group"; 383 contact 384 "WG Web: 385 WG List: 386 Author: Michael Richardson 387 388 Author: Peter van der Stok 389 390 Author: Panos Kampanakis 391 "; 392 description 393 "This module defines the format for a voucher request, 394 which is produced by a pledge to request a voucher. 395 The voucher-request is sent to the potential owner's 396 Registrar, which in turn sends the voucher request to 397 the manufacturer or delegate (MASA). 399 A voucher is then returned to the pledge, binding the 400 pledge to the owner. This is a constrained version of the 401 voucher-request present in 402 draft-ietf-anima-bootstrap-keyinfra.txt. 404 This version provides a very restricted subset appropriate 405 for very constrained devices. 406 In particular, it assumes that nonce-ful operation is 407 always required, that expiration dates are rather weak, as no 408 clocks can be assumed, and that the Registrar is identified 409 by a pinned Raw Public Key. 411 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 412 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 413 and 'OPTIONAL' in the module text are to be interpreted as 414 described in RFC 2119."; 416 revision "2018-09-01" { 417 description 418 "Initial version"; 419 reference 420 "RFC XXXX: Voucher Profile for Constrained Devices"; 421 } 423 rc:yang-data voucher-request-constrained-artifact { 424 // YANG data template for a voucher. 425 uses voucher-request-constrained-grouping; 426 } 428 // Grouping defined for future usage 429 grouping voucher-request-constrained-grouping { 430 description 431 "Grouping to allow reuse/extensions in future work."; 433 uses v:voucher-artifact-grouping { 435 refine voucher/created-on { 436 mandatory false; 437 } 439 refine voucher/pinned-domain-cert { 440 mandatory false; 441 } 443 augment "voucher" { 444 description "Base the constrained voucher-request upon the 445 regular one"; 447 leaf proximity-registrar-subject-public-key-info { 448 type binary; 449 description 450 "The proximity-registrar-subject-public-key-info replaces 451 the proximit-registrar-cert in constrained uses of 452 the voucher-request. 453 The proximity-registrar-subject-public-key-info is the 454 Raw Public Key of the Registrar. This field is encoded 455 as specified in RFC7250, section 3. 456 The ECDSA algorithm MUST be supported. 457 The EdDSA algorithm as specified in 458 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 459 Support for the DSA algorithm is not recommended. 460 Support for the RSA algorithm is MAY, but due to 461 size is discouraged."; 462 } 464 leaf proximity-registrar-sha256-of-subject-public-key-info { 465 type binary; 466 description 467 "The proximity-registrar-sha256-of-subject-public-key-info 468 is an alternative to 469 proximity-registrar-subject-public-key-info. 470 and pinned-domain-cert. In many cases the 471 public key of the domain has already been transmitted 472 during the key agreement protocol, and it is wasteful 473 to transmit the public key another two times. 474 The use of a hash of public key info, at 32-bytes for 475 sha256 is a significant savings compared to an RSA 476 public key, but is only a minor savings compared to 477 a 256-bit ECDSA public-key. 479 Algorithm agility is provided by extensions to this 480 specifications which define new leaf for other hash 481 types."; 482 } 484 leaf proximity-registrar-cert { 485 type binary; 486 description 487 "An X.509 v3 certificate structure as specified by 488 RFC 5280, 489 Section 4 encoded using the ASN.1 distinguished encoding 490 rules (DER), as specified in ITU-T X.690. 492 The first certificate in the Registrar TLS server 493 certificate_list sequence (see [RFC5246]) presented by 494 the Registrar to the Pledge. This MUST be populated in a 495 Pledge's voucher request if the proximity assertion is 496 populated."; 497 } 499 leaf prior-signed-voucher-request { 500 type binary; 501 description 502 "If it is necessary to change a voucher, or re-sign and 503 forward a voucher that was previously provided along a 504 protocol path, then the previously signed voucher 505 SHOULD be included in this field. 507 For example, a pledge might sign a proximity voucher, 508 which an intermediate registrar then re-signs to 509 make its own proximity assertion. This is a simple 510 mechanism for a chain of trusted parties to change a 511 voucher, while maintaining the prior signature 512 information. 514 The pledge MUST ignore all prior voucher information 515 when accepting a voucher for imprinting. Other 516 parties MAY examine the prior signed voucher 517 information for the purposes of policy decisions. 518 For example this information could be useful to a 519 MASA to determine that both pledge and registrar 520 agree on proximity assertions. The MASA SHOULD 521 remove all prior-signed-voucher-request information when 522 signing a voucher for imprinting so as to minimize the 523 final voucher size."; 524 } 525 } 526 } 528 } 529 } 530 532 6.1.4. Example voucher request artifact 534 Below is a CBOR serialization of the constrained-voucher-request is 535 shown in diagnostic CBOR notation. The enum value of the assertion 536 field is calculated to be zero by following the algorithm described 537 in section 9.6.4.2 of [RFC7950]. 539 { 540 1001154: { 541 +2 : "2016-10-07T19:31:42Z", / SID= 1001156, created-on / 542 +4 : "2016-10-21T19:31:42Z", / SID= 1001158, expires-on / 543 +1 : 2, / SID= 1001155, assertion / 544 / "proximity" / 545 +13: "JADA123456789", / SID= 1001167, serial-number / 546 +5 : h'01020D0F', / SID= 1001159, idevid-issuer / 547 +10: h'01020D0F', / SID=1001064, proximity-registrar-cert/ 548 +3 : true, / SID= 1001157, domain-cert 549 -revocation-checks/ 550 +6 : "2017-10-07T19:31:42Z", / SID= 1001160, last-renewal-date / 551 +12: h'01020D0F' / SID= 1001166, proximity-registrar 552 -subject-public-key-info / 553 } 554 } 556 6.2. Voucher artifact 558 The voucher's primary purpose is to securely assign a pledge to an 559 owner. The voucher informs the pledge which entity it should 560 consider to be its owner. 562 This document defines a voucher that is a CBOR encoded instance of 563 the YANG module defined in Section 5.3 that has been signed with CMS 564 or with COSE. 566 6.2.1. Tree Diagram 568 The following diagram is largely a duplicate of the contents of 569 [RFC8366], with only the addition of pinned-domain-subject-public- 570 key-info. 572 module: ietf-constrained-voucher 574 grouping voucher-constrained-grouping 575 +-- voucher 576 +-- created-on? 577 | yang:date-and-time 578 +-- expires-on? 579 | yang:date-and-time 580 +-- assertion enumeration 581 +-- serial-number string 582 +-- idevid-issuer? binary 583 +-- pinned-domain-cert? binary 584 +-- domain-cert-revocation-checks? boolean 585 +-- nonce? binary 586 +-- last-renewal-date? 587 | yang:date-and-time 588 +-- pinned-domain-subject-public-key-info? binary 589 +-- pinned-sha256-of-subject-public-key-info? binary 591 6.2.2. SID values 593 SID Assigned to 594 --------- -------------------------------------------------- 595 1001104 data /ietf-constrained-voucher:voucher 596 1001105 data /ietf-constrained-voucher:voucher/assertion 597 1001106 data /ietf-constrained-voucher:voucher/created-on 598 1001107 data .../domain-cert-revocation-checks 599 1001108 data /ietf-constrained-voucher:voucher/expires-on 600 1001109 data /ietf-constrained-voucher:voucher/idevid-issuer 601 1001110 data .../last-renewal-date 602 1001111 data /ietf-constrained-voucher:voucher/nonce 603 1001112 data .../pinned-domain-cert 604 1001113 data .../pinned-domain-subject-public-key-info 605 1001115 data .../pinned-sha256-of-subject-public-key-info 606 1001114 data /ietf-constrained-voucher:voucher/serial-number 608 6.2.3. YANG Module 610 In the constrained-voucher YANG module, the voucher is "augmented" 611 within the "used" grouping statement such that one continuous set of 612 SID values is generated for the constrained-voucher module name, all 613 voucher attributes, and the constrained-voucher attribute. Two 614 attributes of the voucher are "refined" to be optional. 616 file "ietf-constrained-voucher@2018-09-01.yang" 617 module ietf-constrained-voucher { 618 yang-version 1.1; 619 namespace 620 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 621 prefix "constrained"; 623 import ietf-restconf { 624 prefix rc; 625 description 626 "This import statement is only present to access 627 the yang-data extension defined in RFC 8040."; 628 reference "RFC 8040: RESTCONF Protocol"; 629 } 631 import ietf-voucher { 632 prefix "v"; 633 } 635 organization 636 "IETF ANIMA Working Group"; 638 contact 639 "WG Web: 640 WG List: 641 Author: Michael Richardson 642 643 Author: Peter van der Stok 644 645 Author: Panos Kampanakis 646 "; 647 description 648 "This module defines the format for a voucher, which is produced 649 by a pledge's manufacturer or delegate (MASA) to securely assign 650 one or more pledges to an 'owner', so that the pledges may 651 establis a secure connection to the owner's network 652 infrastructure. 654 This version provides a very restricted subset appropriate 655 for very constrained devices. 656 In particular, it assumes that nonce-ful operation is 657 always required, that expiration dates are rather weak, as no 658 clocks can be assumed, and that the Registrar is identified 659 by a pinned Raw Public Key. 661 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 662 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 663 and 'OPTIONAL' in the module text are to be interpreted as 664 described in RFC 2119."; 666 revision "2018-09-01" { 667 description 668 "Initial version"; 669 reference 670 "RFC XXXX: Voucher Profile for Constrained Devices"; 671 } 673 rc:yang-data voucher-constrained-artifact { 674 // YANG data template for a voucher. 675 uses voucher-constrained-grouping; 676 } 678 // Grouping defined for future usage 679 grouping voucher-constrained-grouping { 680 description 681 "Grouping to allow reuse/extensions in future work."; 683 uses v:voucher-artifact-grouping { 685 refine voucher/created-on { 686 mandatory false; 687 } 689 refine voucher/pinned-domain-cert { 690 mandatory false; 691 } 693 augment "voucher" { 694 description "Base the constrained voucher 695 upon the regular one"; 696 leaf pinned-domain-subject-public-key-info { 697 type binary; 698 description 699 "The pinned-domain-subject-public-key-info replaces the 700 pinned-domain-cert in constrained uses of 701 the voucher. The pinned-domain-subject-public-key-info 702 is the Raw Public Key of the Registrar. 703 This field is encoded as specified in RFC7250, 704 section 3. 705 The ECDSA algorithm MUST be supported. 706 The EdDSA algorithm as specified in 707 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 708 Support for the DSA algorithm is not recommended. 709 Support for the RSA algorithm is a MAY."; 710 } 712 leaf pinned-sha256-of-subject-public-key-info { 713 type binary; 714 description 715 "The pinned-hash-subject-public-key-info is a second 716 alternative to pinned-domain-cert. In many cases the 717 public key of the domain has already been transmitted 718 during the key agreement process, and it is wasteful 719 to transmit the public key another two times. 720 The use of a hash of public key info, at 32-bytes for 721 sha256 is a significant savings compared to an RSA 722 public key, but is only a minor savings compared to 723 a 256-bit ECDSA public-key. 724 Algorithm agility is provided by extensions to this 725 specifications which define new leaf for other hash types"; 726 } 727 } 728 } 729 } 730 } 731 733 6.2.4. Example voucher artifacts 735 Below a the CBOR serialization of the constrained-voucher is shown in 736 diagnostic CBOR notation. The enum value of the assertion field is 737 calculated to be zero by following the algorithm described in section 738 9.6.4.2 of [RFC7950]. 740 { 741 1001104: { 742 +2 : "2016-10-07T19:31:42Z", / SID = 1001106, created-on / 743 +4 : "2016-10-21T19:31:42Z", / SID = 1001108, expires-on / 744 +1 : 0, / SID = 1001105, assertion / 745 / "verified" / 746 +11: "JADA123456789", / SID = 1001115, serial-number / 747 +5 : h'01020D0F', / SID = 1001109, idevid-issuer / 748 +8 : h'01020D0F', / SID = 1001112, pinned-domain-cert/ 749 +3 : true, / SID = 1001107, domain-cert 750 -revocation-checks / 751 +6 : "2017-10-07T19:31:42Z", / SID = 1001110, last-renewal-date / 752 +9 : h'01020D0F' / SID = 1001113, pinned-domain 753 -subject-public-key-info / 754 } 755 } 757 The signing of the example is shown in Appendix B.1. 759 6.3. Signing voucher and voucher-request artifacts 761 6.3.1. CMS signing 763 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 764 voucher is much like the equivalent voucher defined in [RFC8366]. 766 A different eContentType of TBD1 is used to indicate that the 767 contents are in a different format than in [RFC8366]. 769 The ContentInfo structure contains a payload consisting of the CBOR 770 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 771 creates a canonical ordering for the keys on the wire. This 772 canonical ordering is not important as there is no expectation that 773 the content will be reproduced during the validation process. 775 Normally the recipient is the pledge and the signer is the MASA. 777 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 778 unsigned voucher requests from the pledge to the JRC. In this 779 specification, voucher-request artifact MUST be signed from the 780 pledge to the registrar. From the JRC to the MASA, the voucher- 781 request artifact MUST be signed by the domain owner key which is 782 requesting ownership. 784 The considerations of [RFC5652] section 5.1, concerning validating 785 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 787 The CMS structure SHOULD also contain all the certificates leading up 788 to and including the signer's trust anchor certificate known to the 789 recipient. The inclusion of the trust anchor is unusual in many 790 applications, but without it third parties can not accurately audit 791 the transaction. 793 The CMS structure MAY also contain revocation objects for any 794 intermediate certificate authorities (CAs) between the voucher-issuer 795 and the trust anchor known to the recipient. However, the use of 796 CRLs and other validity mechanisms is discouraged, as the pledge is 797 unlikely to be able to perform online checks, and is unlikely to have 798 a trusted clock source. As described below, the use of short-lived 799 vouchers and/or pledge provided nonce provides a freshness guarantee. 801 [EDnote: compulsory signing algorithms are ....] 803 In Appendix B.1 an example for the CMS signing of the voucher-request 804 is shown. 806 6.3.2. COSE signing 808 The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152]. 809 The CBOR object that carries the body, the signature, and the 810 information about the body and signature is called the COSE_Sign1 811 structure. It is used when only one signature is used on the body. 812 Support for EdDSA 256 with Ed25519 is compulsory. 814 The supported COSE-sign1 object stucture is shown in Figure 1. 816 COSE_Sign1( 817 [ 818 h'a10126', #{ "alg": EDdsa 256 } 819 { 820 "crv": Ed25519, 821 "kty": OKP, 822 "key_ops": "verify" 823 }, 824 h'123', #voucher-request binary content 825 h'456', #voucher-request binary public signature 826 ] 827 ) 829 Figure 1: The cose-sign1 structure. 831 The [COSE-registry] specifies the integers that replace the strings 832 and the mnemonics in Figure 1. In Appendix C a binary cose-sign1 833 object is shown based on the voucher-request example of 834 Section 6.1.4. 836 7. Design Considerations 838 The design considerations for the CBOR encoding of vouchers is much 839 the same as for [RFC8366]. 841 One key difference is that the names of the leaves in the YANG does 842 not have a material effect on the size of the resulting CBOR, as the 843 SID translation process assigns integers to the names. 845 8. Security Considerations 847 8.1. Clock Sensitivity 849 TBD. 851 8.2. Protect Voucher PKI in HSM 853 TBD. 855 8.3. Test Domain Certificate Validity when Signing 857 TBD. 859 9. IANA Considerations 861 9.1. Resource Type Registry 863 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 864 parameters" registry are specified below. These can be registered 865 either in the Expert Review range (0-255) or IETF Review range 866 (256-9999). 868 ace.rt.rv needs registration with IANA 869 ace.rt.vs needs registration with IANA 870 ace.rt.es needs registration with IANA 871 ace.rt.ra needs registration with IANA 873 9.2. The IETF XML Registry 875 This document registers two URIs in the IETF XML registry [RFC3688]. 876 Following the format in [RFC3688], the following registration is 877 requested: 879 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 880 Registrant Contact: The ANIMA WG of the IETF. 881 XML: N/A, the requested URI is an XML namespace. 883 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 884 Registrant Contact: The ANIMA WG of the IETF. 885 XML: N/A, the requested URI is an XML namespace. 887 9.3. The YANG Module Names Registry 889 This document registers two YANG modules in the YANG Module Names 890 registry [RFC6020]. Following the format defined in [RFC6020], the 891 the following registration is requested: 893 name: ietf-constrained-voucher 894 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 895 prefix: vch 896 reference: RFC XXXX 898 name: ietf-constrained-voucher-request 899 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 900 -voucher-request 901 prefix: vch 902 reference: RFC XXXX 904 9.4. The RFC SID range assignment sub-registry 906 ------------ ------ --------------------------- ------------ 907 Entry-point | Size | Module name | RFC Number 908 ------------ ------ --------------------------- ------------ 909 1001100 50 ietf-constrained-voucher [ThisRFC] 910 1001150 50 ietf-constrained-voucher [ThisRFC} 911 -request 912 ----------- ------ --------------------------- ------------ 914 Warning: These SID values will change when they transfer to the range 915 1000 - 59,999 allocated for SIDs in YANG modules defined in RFCs. 917 9.5. The SMI Security for S/MIME CMS Content Type Registry 919 This document registers an OID in the "SMI Security for S/MIME CMS 920 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 922 Decimal Description References 923 ------- -------------------------------------- ---------- 924 TBD1 id-ct-animaCBORVoucher [ThisRFC] 926 EDNOTE: should a separate value be used for Voucher Requests? 928 9.6. Media-Type Registry 930 This section registers the 'application/voucher-cms+cbor' media type 931 and the 'application/voucher-cose+cbor' in the "Media Types" 932 registry. These media types are used to indicate that the content is 933 a CBOR voucher either signed with a cms structure or a COSE_Sign1 934 structure [RFC8152]. 936 9.6.1. application/voucher-cms+cbor 937 Type name: application 938 Subtype name: voucher-cms+cbor 939 Required parameters: none 940 Optional parameters: none 941 Encoding considerations: CMS-signed CBOR vouchers are CBOR 942 encoded. 943 Security considerations: See Security Considerations, Section 944 Interoperability considerations: The format is designed to be 945 broadly interoperable. 946 Published specification: THIS RFC. 947 Applications that use this media type: ANIMA, 6tisch, and other 948 zero-touch imprinting systems 949 Additional information: 950 Magic number(s): None 951 File extension(s): .vch 952 Macintosh file type code(s): none 953 Person & email address to contact for further information: IETF 954 ANIMA WG 955 Intended usage: LIMITED 956 Restrictions on usage: NONE 957 Author: ANIMA WG 958 Change controller: IETF 959 Provisional registration? (standards tree only): NO 961 9.6.2. application/voucher-cose+cbor 962 Type name: application 963 Subtype name: voucher-cose+cbor 964 Required parameters: none 965 Optional parameters: cose-type 966 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 967 signed with one signer. 968 Security considerations: See Security Considerations, Section 969 Interoperability considerations: The format is designed to be 970 broadly interoperable. 971 Published specification: THIS RFC. 972 Applications that use this media type: ANIMA, 6tisch, and other 973 zero-touch imprinting systems 974 Additional information: 975 Magic number(s): None 976 File extension(s): .vch 977 Macintosh file type code(s): none 978 Person & email address to contact for further information: IETF 979 ANIMA WG 980 Intended usage: LIMITED 981 Restrictions on usage: NONE 982 Author: ANIMA WG 983 Change controller: IETF 984 Provisional registration? (standards tree only): NO 986 9.7. CoAP Content-Format Registry 988 Additions to the sub-registry "CoAP Content-Formats", within the 989 "CoRE Parameters" registry are needed for two media types. These can 990 be registered either in the Expert Review range (0-255) or IETF 991 Review range (256-9999). 993 Media type mime type Encoding ID References 994 ---------------------------- ----------- --------- ---- ---------- 995 application/voucher-cms+cbor - - CBOR TBD2 [This RFC] 996 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 998 10. Acknowledgements 1000 We are very grateful to Jim Schaad for explaining COSE and CMS 1001 choices. 1003 Michel Veillette did extensive work on pyang to extend it to support 1004 the SID allocation process, and this document was among the first 1005 users. 1007 We are grateful for the suggestions done by Esko Dijk. 1009 11. Changelog 1011 -04 voucher and request-voucher MUST be signed examples for signed 1012 request are added in appendix IANA SID registration is updated SID 1013 values in examples are aligned signed cms examples aligned with new 1014 SIDs 1016 -03 1018 Examples are inverted. 1020 -02 1022 Example of requestvoucher with unsigned appllication/cbor is added 1023 attributes of voucher "refined" to optional 1024 CBOR serialization of vouchers improved 1025 Discovery port numbers are specified 1027 -01 1029 application/json is optional, application/cbor is compulsory 1030 Cms and cose mediatypes are introduced 1032 12. References 1034 12.1. Normative References 1036 [I-D.ietf-ace-cbor-web-token] 1037 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1038 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 1039 (work in progress), March 2018. 1041 [I-D.ietf-ace-coap-est] 1042 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 1043 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 1044 est-12 (work in progress), June 2019. 1046 [I-D.ietf-anima-bootstrapping-keyinfra] 1047 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1048 S., and K. Watsen, "Bootstrapping Remote Secure Key 1049 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1050 keyinfra-22 (work in progress), June 2019. 1052 [I-D.ietf-core-object-security] 1053 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1054 "Object Security for Constrained RESTful Environments 1055 (OSCORE)", draft-ietf-core-object-security-16 (work in 1056 progress), March 2019. 1058 [I-D.ietf-core-sid] 1059 Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item 1060 iDentifier (SID)", draft-ietf-core-sid-06 (work in 1061 progress), March 2019. 1063 [I-D.ietf-core-yang-cbor] 1064 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 1065 Data Modeled with YANG", draft-ietf-core-yang-cbor-10 1066 (work in progress), April 2019. 1068 [ieee802-1AR] 1069 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1070 2009, . 1073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1074 Requirement Levels", BCP 14, RFC 2119, 1075 DOI 10.17487/RFC2119, March 1997, 1076 . 1078 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1079 DOI 10.17487/RFC3688, January 2004, 1080 . 1082 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1083 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1084 . 1086 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1087 the Network Configuration Protocol (NETCONF)", RFC 6020, 1088 DOI 10.17487/RFC6020, October 2010, 1089 . 1091 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1092 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1093 October 2013, . 1095 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1096 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1097 Transport Layer Security (TLS) and Datagram Transport 1098 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1099 June 2014, . 1101 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1102 Application Protocol (CoAP)", RFC 7252, 1103 DOI 10.17487/RFC7252, June 2014, 1104 . 1106 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1107 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1108 . 1110 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1111 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1112 . 1114 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1115 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1116 May 2017, . 1118 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1119 "A Voucher Artifact for Bootstrapping Protocols", 1120 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1121 . 1123 12.2. Informative References 1125 [COSE-registry] 1126 IANA, ., "CBOR Object Signing and Encryption (COSE) 1127 registry", 2017, 1128 . 1130 [duckling] 1131 Stajano, F. and R. Anderson, "The resurrecting duckling: 1132 security issues for ad-hoc wireless networks", 1999, 1133 . 1136 [I-D.ietf-netmod-yang-tree-diagrams] 1137 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1138 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1139 February 2018. 1141 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 1142 . 1144 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1145 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1146 . 1148 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1149 "Enrollment over Secure Transport", RFC 7030, 1150 DOI 10.17487/RFC7030, October 2013, 1151 . 1153 Appendix A. EST messages to EST-coaps 1155 This section extends the examples from Appendix A of 1156 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1157 the enrollstatus example. 1159 A.1. enrollstatus 1161 A coaps enrollstatus message can be : 1163 GET coaps://[192.0.2.1:8085]/est/es 1165 The corresponding coap header fields are shown below. 1167 Ver = 1 1168 T = 0 (CON) 1169 Code = 0x01 (0.01 is GET) 1170 Options 1171 Option (Uri-Path) 1172 Option Delta = 0xb (option nr = 11) 1173 Option Length = 0x3 1174 Option Value = "est" 1175 Option (Uri-Path) 1176 Option Delta = 0x0 (option nr = 11) 1177 Option Length = 0x2 1178 Option Value = "es" 1179 Payload = [Empty] 1181 The Uri-Host and Uri-Port Options are omitted because they coincide 1182 with the transport protocol destination address and port 1183 respectively. 1185 A 2.05 Content response with an unsigned voucher status (ct=60) will 1186 then be: 1188 2.05 Content (Content-Format: application/cbor) 1190 With CoAP fields and payload: 1192 Ver=1 1193 T=2 (ACK) 1194 Code = 0x45 (2.05 Content) 1195 Options 1196 Option1 (Content-Format) 1197 Option Delta = 0xC (option nr 12) 1198 Option Length = 0x2 1199 Option Value = 60 (application/cbor) 1201 Payload (CBOR diagnostic) = 1202 { 1203 "version":"1", 1204 "Status": 1, / 1 = Success, 0 = Fail / 1205 "Reason":"Informative human readable message", 1206 "reason-context": "Additional information" 1207 } 1209 Payload (binary) = 1210 A46776657273696F6E6131665374617475730166526561736F6E7822 1211 496E666F726D61746976652068756D616E207265616461626C65206D 1212 6573736167656e726561736F6E2D636F6E74657874 1213 764164646974696F6E616C20696E666F726D6174696F6E 1214 ~~~ 1216 ##voucher_status 1218 A coaps voucher_status message can be : 1220 GET coaps://[2001:db8::2:1]:61616]/est/vs ~~~~ 1222 A 2.05 Content response with a non signed CBOR voucher (ct=60) will 1223 then be: 1225 2.05 Content (Content-Format: application/cbor) 1226 Payload = 1227 A46776657273696F6E6131665374617475730166526561736F6E7822 1228 496E666F726D61746976652068756D616E207265616461626C65206D 1229 6573736167656e726561736F6E2D636F6E74657874 1230 764164646974696F6E616C20696E666F726D6174696F6E 1232 A.2. requestvoucher 1234 Signed request-voucher-request payloads are sent from pledge to 1235 Registrar, as explained in Section 5.2 of 1236 [I-D.ietf-anima-bootstrapping-keyinfra]. 1238 A.2.1. signed requestvoucher 1240 A CMS signed requestvoucher message from JRC to MASA is shown below. 1241 It would be CoAP POSTED to /est/rv. 1243 POST coaps://[2001:db8::2:1]:61616]/est/rv 1244 (Content-Format: application/voucher-cms+cbor) 1246 The payload would be in binary, but is presented in base64 in this 1247 document. 1249 MIIDugYJKoZIhvcNAQcCoIIDqzCCA6cCAQExDTALBglghkgBZQMEAgEwCwYJ 1250 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1251 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1252 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1253 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1254 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1255 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1256 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1257 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1258 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1259 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1260 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1261 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1262 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1263 3m00kjYxggE/MIIBOwIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1264 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1265 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1266 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1267 DTE5MDQwODEwNDgzNlowLwYJKoZIhvcNAQkEMSIEILEdCTOLs2Zy7w3LgvSZ 1268 XZEadz3LbznoFBs6FMFN91RaMAoGCCqGSM49BAMCBEcwRQIgASjDsIpr0tW/ 1269 n6dRHqvvqsqgZlHbtFnErUbWfhS0KD4CIQDDUEqc5wTmRGf0adEQVQzqmIgh 1270 MEgF10vqXv02gL1jLw== 1272 A 2.04 Changed response returning CBOR voucher signed with a cms 1273 structure(ct=TBD2) will then be: 1275 2.04 Changed (Content-Format: application/voucher-cms+cbor) 1277 MIIDuwYJKoZIhvcNAQcCoIIDrDCCA6gCAQExDTALBglghkgBZQMEAgEwCwYJ 1278 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1279 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1280 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1281 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1282 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1283 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1284 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1285 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1286 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1287 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1288 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1289 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1290 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1291 3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1292 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1293 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1294 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1295 DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he 1296 uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG 1297 kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX 1298 hlG/g+OgTUftYMJ32so= 1300 A.3. requestauditing 1302 A coaps requestauditing message contains the signed CBOR voucher : 1304 POST coaps://[2001:db8::2:1]:61616]/est/ra 1305 (Content-Format: application/voucher-cms+cbor) 1306 Payload = 1307 308203ba06092a864886f70d010702a08203ab308203a7020101310d300b 1308 0609608648016503040201300b06092a864886f70d010701a08202413082 1309 023d308201e2a00302010202087e7661d7b54e4632300a06082a8648ce3d 1310 040302305d310b3009060355040613025553310b300906035504080c0243 1311 4131143012060355040a0c0b4578616d706c6520496e6331163014060355 1312 040b0c0d63657274696669636174696f6e3113301106035504030c0a3830 1313 322e3141522043413020170d3139303133313131323931365a180f393939 1314 39313233313233353935395a305c310b3009060355040613025553310b30 1315 0906035504080c024341310b300906035504070c024c4131143012060355 1316 040a0c0b6578616d706c6520496e63310c300a060355040b0c03496f5431 1317 0f300d060355040513065774313233343059301306072a8648ce3d020106 1318 082a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc49 1319 4f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf 1320 75f602f9152618f816a2b23b5638e59fd9a3818a30818730090603551d13 1321 04023000301d0603551d0e0416041496600d8716bf7fd0e752d0ac760777 1322 ad665d02a0301f0603551d2304183016801468d16551f951bfc82a431d0d 1323 9f08bc2d205b1160300e0603551d0f0101ff0404030205a0302a0603551d 1324 1104233021a01f06082b06010505070804a013301106092b06010401b43b 1325 0a01040401020304300a06082a8648ce3d0403020349003046022100c0d8 1326 1996d2507d693f3c48eaa5ee9491bda6db214099d98117c63b361374cd86 1327 022100a774989f4c321a5cf25d832a4d336a08ad67df20f1506421188a0a 1328 de6d3492363182013f3082013b0201013069305d310b3009060355040613 1329 025553310b300906035504080c02434131143012060355040a0c0b457861 1330 6d706c6520496e6331163014060355040b0c0d6365727469666963617469 1331 6f6e3113301106035504030c0a3830322e31415220434102087e7661d7b5 1332 4e4632300b0609608648016503040201a069301806092a864886f70d0109 1333 03310b06092a864886f70d010701301c06092a864886f70d010905310f17 1334 0d3139303430383130343833365a302f06092a864886f70d010904312204 1335 20b11d09338bb36672ef0dcb82f4995d911a773dcb6f39e8141b3a14c14d 1336 f7545a300a06082a8648ce3d0403020447304502200128c3b08a6bd2d5bf 1337 9fa7511eabefaacaa06651dbb459c4ad46d67e14b4283e022100c3504a9c 1338 e704e64467f469d110550cea988821304805d74bea5efd3680bd632f 1340 A 2.05 Content response returning a log of the voucher (ct=60) will 1341 then be: 1343 2.05 Content (Content-Format: application/cbor) 1344 Payload = 1345 { 1346 "version":"1", 1347 "events":[ 1348 { 1349 "date":"", 1350 "domainID":"", 1351 "nonce":"" 1352 "assertion":"" 1353 "truncated":"" 1354 }, 1355 { 1356 "date":"", 1357 "domainID":"", 1358 "nonce":"" 1359 "assertion":"" 1360 } 1361 ], 1362 "truncation": { 1363 "nonced duplicates": "", 1364 "nonceless duplicates": "", 1365 "arbitrary": "" 1366 } 1367 } 1369 [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary] 1371 Appendix B. Signed voucher-request examples 1373 B.1. CMS signed voucher-request example 1375 The voucher-request example, visualized in CBOR diagnostic notation 1376 in Section 6.1.4 is shown as a hexadecimal dump of the binary file. 1378 A11A000F46C2A90274323031362D31302D30375431393A33313A34325A0 1379 474323031362D31302D32315431393A33313A34325A01020d6d4A414441 1380 313233343536373839054401020D0F0A4401020D0F03F50674323031372 1381 D31302D30375431393A33313A34325A0c4401020D0F 1383 The voucher-request example has been signed by using the WT1234 1384 certificate and key pair shown in Appendix C of 1385 [I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher- 1386 request leads to a binary signed voucher-request, shown with a 1387 hexadecimal representation shown in the payload of the request part 1388 of Appendix A.2.1 and Appendix A.3. 1390 The breakdown of the CMS signed binary voucher-request file is 1391 visualized below: 1393 CMS_ContentInfo: 1394 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1395 d.signedData: 1396 version: 1 1397 digestAlgorithms: 1398 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1399 parameter: 1400 encapContentInfo: 1401 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1402 eContent: 1403 certificates: 1404 d.certificate: 1405 cert_info: 1406 version: 2 1407 serialNumber: 9112578475118446130 1408 signature: 1409 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1410 parameter: 1411 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1412 CN=802.1AR CA 1413 validity: 1414 notBefore: Jan 31 11:29:16 2019 GMT 1415 notAfter: Dec 31 23:59:59 9999 GMT 1416 subject: C=US, ST=CA, L=LA, O=example Inc, 1417 OU=IoT/serialNumber=Wt1234 1418 key: 1419 algor: 1420 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1421 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1422 public_key: (0 unused bits) 1423 0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf 1424 000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15 1425 001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df 1426 002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8 1427 0038 - 16 a2 b2 3b 56 38 e5 9f-d9 1428 issuerUID: 1429 subjectUID: 1430 extensions: 1431 object: X509v3 Basic Constraints (2.5.29.19) 1432 critical: BOOL ABSENT 1433 value: 1434 0000 - 30 1435 0002 - 1437 object: X509v3 Subject Key Identifier (2.5.29.14) 1438 critical: BOOL ABSENT 1439 value: 1440 0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0 1441 000d - ac 76 07 77 ad 66 5d 02-a0 1443 object: X509v3 Authority Key Identifier (2.5.29.35) 1444 critical: BOOL ABSENT 1445 value: 1446 0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a 1447 000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60 1449 object: X509v3 Key Usage (2.5.29.15) 1450 critical: TRUE 1451 value: 1452 0000 - 03 02 05 a0 1454 object: X509v3 Subject Alternative Name (2.5.29.17) 1455 critical: BOOL ABSENT 1456 value: 1457 0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08 1458 000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4 1459 001a - 3b 0a 01 04 04 01 02 03-04 1460 sig_alg: 1461 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1462 parameter: 1463 signature: (0 unused bits) 1464 0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c 1465 000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17 1466 001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c 1467 002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20 1468 003c - f1 50 64 21 18 8a 0a de-6d 34 92 36 1469 crls: 1470 1471 signerInfos: 1472 version: 1 1473 d.issuerAndSerialNumber: 1474 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1475 CN=802.1AR CA 1476 serialNumber: 9112578475118446130 1477 digestAlgorithm: 1478 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1479 parameter: 1480 signedAttrs: 1481 object: contentType (1.2.840.113549.1.9.3) 1482 value.set: 1483 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1485 object: signingTime (1.2.840.113549.1.9.5) 1486 value.set: 1487 UTCTIME:Jul 3 08:53:30 2019 GMT 1489 object: messageDigest (1.2.840.113549.1.9.4) 1490 value.set: 1491 OCTET STRING: 1492 0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d 1493 000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f 1494 001a - 0b 4f 44 9e 25 1495 0020 - 1496 signatureAlgorithm: 1497 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1498 parameter: 1499 signature: 1500 0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64 1501 000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf 1502 001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4 1503 002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af 1504 003c - 2b 59 16 cc 36 63 e7 91-89 39 df df 1505 unsignedAttrs: 1506 1508 Appendix C. COSE examples 1510 These examples are from the https://minerva.sandelman.ca/ reference 1511 code, using the unit test case key pairs, with a flow between pledge 1512 ("reach" code), JRC ("fountain") code, and MASA ("highway") code. 1513 This example comes from the spec/files/product/00-D0-E5-F2-00-03 1514 directory. 1516 Thanks to Jim Schaad for verifying the COSE Sign1 objects: faults 1517 were found and corrected. 1519 C.1. Device, Registrar and MASA keys 1521 This first section documents the public and private keys used in the 1522 subsequent test vectors below. These keys come from test code and 1523 are not used in any production system, and should only be used only 1524 to validate implementations. 1526 C.1.1. Device IDevID certificate 1527 Certificate: 1528 Data: 1529 Version: 3 (0x2) 1530 Serial Number: 787697345 (0x2ef34ec1) 1531 Signature Algorithm: ecdsa-with-SHA256 1532 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = h 1533 ighway-test.example.com CA 1534 Validity 1535 Not Before: Feb 14 17:05:09 2019 GMT 1536 Not After : Dec 31 00:00:00 2999 GMT 1537 Subject: serialNumber = 00-D0-E5-F2-00-03 1538 Subject Public Key Info: 1539 Public Key Algorithm: id-ecPublicKey 1540 Public-Key: (256 bit) 1541 pub: 1542 04:82:c4:28:5b:7c:f0:37:18:c7:90:14:dc:cb:f4: 1543 4d:7e:b0:00:ed:c0:de:bd:4d:25:55:4e:35:f9:d5: 1544 6a:57:14:b4:94:af:ce:6d:53:c8:60:c2:ce:53:3f: 1545 2c:1b:42:f1:c0:8b:5f:c1:7b:3d:f3:29:54:87:46: 1546 86:a4:0c:8b:b7 1547 ASN1 OID: prime256v1 1548 NIST CURVE: P-256 1549 X509v3 extensions: 1550 X509v3 Subject Key Identifier: 1551 C8:A3:87:72:82:82:E6:EA:90:D0:E1:81:BC:C7:51:08:78:0 1552 F:D7:52 1553 X509v3 Basic Constraints: 1554 CA:FALSE 1555 X509v3 Subject Alternative Name: 1556 othername: 1557 1.3.6.1.4.1.46930.2: 1558 ..highway-test.example.com:9443 1559 Signature Algorithm: ecdsa-with-SHA256 1560 30:65:02:31:00:b2:9a:7a:1a:74:20:8f:e9:e0:5d:fc:af:d6: 1561 4a:80:1f:66:e3:bf:17:2e:3e:07:87:39:be:65:bd:94:57:71: 1562 1f:df:e5:fc:4d:ef:96:8a:3a:03:5b:d1:ca:a1:72:55:a3:02: 1563 30:13:43:08:a4:af:c8:28:19:d2:a0:93:3d:ed:53:fa:09:7d: 1564 76:9c:b7:0b:95:2b:8f:2f:b4:fa:87:02:ec:b4:2d:19:92:5b: 1565 b2:bb:79:04:63:6e:17:0e:79:8a:65:f5:a3 1567 C.1.2. Device private key 1569 -----BEGIN EC PRIVATE KEY----- 1570 MHcCAQEEIA1sa0l4bkj/rJxPUN1bKSBNYolVVzx+T28wo60cYpuaoAoGCCqGSM49 1571 AwEHoUQDQgAEgsQoW3zwNxjHkBTcy/RNfrAA7cDevU0lVU41+dVqVxS0lK/ObVPI 1572 YMLOUz8sG0LxwItfwXs98ylUh0aGpAyLtw== 1573 -----END EC PRIVATE KEY----- 1575 C.1.3. Registrar Certificate 1577 -----BEGIN CERTIFICATE----- 1578 MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxMRIwEAYKCZImiZPyLGQBGRYC 1579 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xQDA+BgNVBAMMNyM8U3lzdGVt 1580 VmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4gVW5zdHJ1bmcgRm91bnRhaW4gQ0Ew 1581 HhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQB 1582 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2Fs 1583 aG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lI 1584 noEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqj 1585 DTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQ 1586 XHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKi 1587 IiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ== 1588 -----END CERTIFICATE----- 1590 C.1.4. Registrar private key 1592 -----BEGIN EC PRIVATE KEY----- 1593 MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 1594 AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E 1595 jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== 1596 -----END EC PRIVATE KEY----- 1598 C.1.5. MASA Certificate 1600 -----BEGIN CERTIFICATE----- 1601 MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h 1602 ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE 1603 AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX 1604 DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh 1605 cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l 1606 eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5 1607 4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf 1608 WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA 1609 vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6 1610 AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP 1611 D0jJ 1612 -----END CERTIFICATE----- 1614 C.1.6. MASA private key 1616 -----BEGIN EC PRIVATE KEY----- 1617 MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 1618 AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ 1619 gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== 1620 -----END EC PRIVATE KEY----- 1622 C.2. COSE signed requestvoucher with registrar certificate pinned 1624 This voucher request has been signed by the pledge, using the private 1625 key given above, and has been sent to the JRC over CoAPS. This 1626 example uses the proximity-registrar-cert mechanism to request a 1627 voucher that pins the certificate of the registrar. 1629 This is the CBOR diagnostic format, folded to 60 characters: 1631 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 1632 D1E49970A5130302D44302D45352D46322D30302D303307765F715674477 1633 738565342626C65394D34557036354C770C5901D4308201D030820157A00 1634 30201020204228ECD27300A06082A8648CE3D040302306E31123010060A0 1635 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1636 0340F4E6D0F9F702553FA53BE572ACF0EED858275B6AC75994332FB25FB3 1637 A54411E9FA02E6F75FD1AADB7EA9A61F5409E02303E615E75C8F07432A59 1638 0C8D48798BEDA1EB49E5E7D8E0EA118BD17A02D02F0313D144816002F756 1639 B528ABD1B0ADB749D', h'96B82530AC57650346C2BFFB5A6CC16B28F16F 1640 ACFE5A2FD1BCF3D5F5D62733F7F7812D67D43BE1CF9906E356FB0C2BDD36 1641 777FD7DBAE22B8CEB07D51D8F55AD3']) 1643 This is the raw binary, encoded in base64: 1645 0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G 1646 Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD 1647 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1648 NA9ObQ+fcCVT+lO+VyrPDu2FgnW2rHWZQzL7Jfs6VEEen6Aub3X9Gq236pph 1649 9UCeAjA+YV51yPB0MqWQyNSHmL7aHrSeXn2ODqEYvRegLQLwMT0USBYAL3Vr 1650 Uoq9GwrbdJ1YQJa4JTCsV2UDRsK/+1pswWso8W+s/lov0bzz1fXWJzP394Et 1651 Z9Q74c+ZBuNW+wwr3TZ3f9fbriK4zrB9Udj1WtM= 1653 C.3. COSE signed parboiled requestvoucher 1655 This voucher request has been signed by the JRC using the private key 1656 from Appendix C.1.4. Contained within this voucher request is the 1657 pledge voucher request above. 1659 This is the CBOR diagnostic format, folded to 60 characters: 1661 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 1662 9DD3BFD0A5130302D44302D45352D46322D30302D303307765F715674477 1663 738565342626C65394D34557036354C770B590266D28441A0A059021CA11 1664 A000F46C2A5016970726F78696D69747902C11A5D1E49970A5130302D443 1665 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1666 AADB7EA9A61F5409E02303E615E75C8F07432A590C8D48798BEDA1EB49E5 1667 E7D8E0EA118BD17A02D02F0313D144816002F756B528ABD1B0ADB749D584 1668 096B82530AC57650346C2BFFB5A6CC16B28F16FACFE5A2FD1BCF3D5F5D62 1669 733F7F7812D67D43BE1CF9906E356FB0C2BDD36777FD7DBAE22B8CEB07D5 1670 1D8F55AD3', h'EAE868ECC176883766C5DC5BA5B8DCA25DAB3C2E56A551 1671 CE5705B793914348E1F93C2B81E88CCBE28E90800F66945EFBBECE4F741D 1672 0EDE18EB1008EF7E9A279C']) 1674 This is the raw binary, encoded in base64: 1676 0oRBoKBZAq6hGgAPRsKlAWlwcm94aW1pdHkCwRpZ3Tv9ClEwMC1EMC1FNS1G 1677 Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwtZAmbShEGgoFkCHKEa 1678 AA9GwqUBaXByb3hpbWl0eQLBGl0eSZcKUTAwLUQwLUU1LUYyLTAwLTAzB3Zf 1679 ** KNOWN TO BE BAD, NOT YET VALIDATED ** 1680 U75XKs8O7YWCdbasdZlDMvsl+zpUQR6foC5vdf0arbfqmmH1QJ4CMD5hXnXI 1681 8HQypZDI1IeYvtoetJ5efY4OoRi9F6AtAvAxPRRIFgAvdWtSir0bCtt0nVhA 1682 lrglMKxXZQNGwr/7WmzBayjxb6z+Wi/RvPPV9dYnM/f3gS1n1Dvhz5kG41b7 1683 DCvdNnd/19uuIrjOsH1R2PVa01hA6uho7MF2iDdmxdxbpbjcol2rPC5WpVHO 1684 VwW3k5FDSOH5PCuB6IzL4o6QgA9mlF77vs5PdB0O3hjrEAjvfponnA== 1686 C.4. COSE signed voucher 1688 The resulting voucher is created by the MASA and returned via the JRC 1689 to the Pledge. It is signed by the MASA's private key Appendix C.1.6 1690 and can be verified by the pledge using the MASA's publie key. 1692 This is the CBOR diagnostic format, folded to 60 characters: 1694 18([h'A0', {}, h'A11A000F468CA505666C6F6767656406C11A5D1E499 1695 A0E7130302D44302D45352D46322D30302D30330B765F715674477738565 1696 342626C65394D34557036354C770C7902744D49494230544343415661674 1697 177494241674942416A414B42676771686B6A4F50515144417A42784D524 1698 9774541594B435A496D695A50794C4751424752594359324578475441584 1699 2676F4A6B69614A6B2F49735A41455A46676C7A5957356B5A57787459573 1700 4785144412B42674E5642414D4D4E794D3855336C7A64475674566D46796 1701 1574669624755364D4867774D4441774D4441774E4759354D5446684D443 1702 4675657357A64484A31626D6367526D3931626E526861573467513045774 1703 868634E4D5463784D5441334D6A4D304E5449345768634E4D546B784D544 1704 1334D6A4D304E544934576A42444D5249774541594B435A496D695A50794 1705 C47514247525943593245784754415842676F4A6B69614A6B2F49735A414 1706 55A46676C7A5957356B5A57787459573478456A415142674E5642414D4D4 1707 3577876593246736147397A6444425A4D424D4742797147534D343941674 1708 54743437147534D34394177454841304941424A5A6C5548493075702F6C3 1709 3655A6639764342622B6C496E6F454D45676337526F2B585A43746A41493 1710 0434431664A664A522F68497979446D48577959694E46625243483966796 1711 172666B7A67583470307A54697A716A4454414C4D416B474131556445775 1712 1434D414177436759494B6F5A497A6A304541774D44615141775A6749784 1713 14C514D4E75726638747635306C524F443544515848454F4A4A4E5733515 1714 632673951456444536B324D592B416F537242536D47534E6A68346F6C454 1715 F6845754C674978414A346E57664E772B426A625A6D4B694969554563547 1716 7484D68475658614D48592F46376E333977774B634242534F6E644E50714 1717 3704F454C6C36627133435A71513D3D', h'7468FB16A4035FDAF510DBF5 1718 A88F67B6FB849CFBA8B094B77AD5248900E4BCD6E892FE74B39AB787637B 1719 121944BED4D1CB4B8DC8F59212EAC2AD20469C71C1F6']) 1721 This is the raw binary, encoded in base64: 1723 0oRBoKBZArmhGgAPRoylBWZsb2dnZWQGwRpdHkmaDnEwMC1EMC1FNS1GMi0w 1724 MC0wMwt2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwx5AnRNSUlCMFRDQ0FWYWdB 1725 d0lCQWdJQkFqQUtCZ2dxaGtqT1BRUURBekJ4TVJJd0VBWUtDWkltaVpQeUxH 1726 UUJHUllDWTJFeEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0 1727 eFFEQStCZ05WQkFNTU55TThVM2x6ZEdWdFZtRnlhV0ZpYkdVNk1IZ3dNREF3 1728 TURBd05HWTVNVEZoTUQ0Z1ZXNXpkSEoxYm1jZ1JtOTFiblJoYVc0Z1EwRXdI 1729 aGNOTVRjeE1UQTNNak0wTlRJNFdoY05NVGt4TVRBM01qTTBOVEk0V2pCRE1S 1730 SXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFF 1731 WkZnbHpZVzVrWld4dFlXNHhFakFRQmdOVkJBTU1DV3h2WTJGc2FHOXpkREJa 1732 TUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wz 1733 ZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt 1734 SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dBMVVkRXdR 1735 Q01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUwbFJP 1736 RDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP 1737 aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24z 1738 OXd3S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09WEB0aPsWpANf2vUQ2/Wo 1739 j2e2+4Sc+6iwlLd61SSJAOS81uiS/nSzmreHY3sSGUS+1NHLS43I9ZIS6sKt 1740 IEacccH2 1742 Authors' Addresses 1744 Michael Richardson 1745 Sandelman Software Works 1747 Email: mcr+ietf@sandelman.ca 1749 Peter van der Stok 1750 vanderstok consultancy 1752 Email: consultancy@vanderstok.org 1754 Panos Kampanakis 1755 Cisco Systems 1757 Email: pkampana@cisco.com