idnits 2.17.1 draft-ietf-anima-constrained-voucher-04.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 465 has weird spacing: '...ndatory false...' == Line 469 has weird spacing: '...ndatory false...' == Line 720 has weird spacing: '...ndatory false...' == Line 724 has weird spacing: '...ndatory false...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 04, 2019) is 1755 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 959, but not defined == Missing Reference: 'This RFC' is mentioned on line 1032, but not defined == Missing Reference: 'Empty' is mentioned on line 1211, but not defined == Unused Reference: 'I-D.ietf-ace-cbor-web-token' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 1131, 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 (~~), 18 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 5, 2020 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 July 04, 2019 10 Constrained Voucher Artifacts for Bootstrapping Protocols 11 draft-ietf-anima-constrained-voucher-04 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 5, 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 . . . . . . . . . . . . . . . . . . . . 14 72 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 14 73 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 15 74 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 15 75 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 18 76 6.3. Signing voucher and voucher-request artifacts . . . . . . 19 77 6.3.1. CMS signing . . . . . . . . . . . . . . . . . . . . . 19 78 6.3.2. COSE signing . . . . . . . . . . . . . . . . . . . . 20 79 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 21 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 81 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 21 82 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 21 83 8.3. Test Domain Certificate Validity when Signing . . . . . . 21 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 21 86 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 21 87 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 22 88 9.4. The RFC SID range assignment sub-registry . . . . . . . . 22 89 9.5. The SMI Security for S/MIME CMS Content Type Registry . . 22 90 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 23 91 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 23 92 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 23 93 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 24 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 95 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 12.2. Informative References . . . . . . . . . . . . . . . . . 27 99 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 27 100 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 28 101 A.2. requestvoucher . . . . . . . . . . . . . . . . . . . . . 29 102 A.2.1. signed requestvoucher . . . . . . . . . . . . . . . . 30 103 A.3. requestauditing . . . . . . . . . . . . . . . . . . . . . 31 104 Appendix B. Signed voucher-request examples . . . . . . . . . . 33 105 B.1. CMS signed voucher-request example . . . . . . . . . . . 33 106 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 36 107 C.1. Device, Registrar and MASA keys . . . . . . . . . . . . . 36 108 C.1.1. Device IDevID certificate . . . . . . . . . . . . . . 36 109 C.1.2. Device private key . . . . . . . . . . . . . . . . . 38 110 C.1.3. Registrar Certificate . . . . . . . . . . . . . . . . 38 111 C.1.4. Registrar private key . . . . . . . . . . . . . . . . 38 112 C.1.5. MASA Certificate . . . . . . . . . . . . . . . . . . 38 113 C.1.6. MASA private key . . . . . . . . . . . . . . . . . . 39 114 C.2. COSE signed requestvoucher with registrar certificate 115 pinned . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 C.3. COSE signed parboiled requestvoucher . . . . . . . . . . 40 117 C.4. COSE signed voucher . . . . . . . . . . . . . . . . . . . 42 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 167 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 168 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 169 [RFC2119] and indicate requirement levels for compliant STuPiD 170 implementations. 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 know the correct 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 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 also raw public keys (RPK). When RPKs are used, 206 the 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 and /enrollstatus are needed between pledge and 251 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 Port numbers, not returned in the example, are assumed to be the 272 default numbers 5683 and 5684 for coap and coaps respectively 273 (sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY 274 be returned in the of the payload. 276 ct=TBD2 stands for Content-Format "application/voucher-cms+cbor, and 277 ct=TBD3 stands for Content-Format "application/voucher-cose+cbor". 279 Content-Formats TBD2 and TBD3 are defined in this document. 281 The Content-Format ("application/json") 50 MAY be supported. 282 Content-Formats ("application/cbor") 60, TBD2, and TBD3 MUST be 283 supported. 285 6. Artifacts 287 This section describes the abstract (tree) definition as explained in 288 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 289 level view of the contents of each artifact. 291 Then the assigned SID values are presented. These have been assigned 292 using the rules in [I-D.ietf-core-sid], with an allocation that was 293 made via the http://comi.space service. 295 6.1. Voucher Request artifact 297 6.1.1. Tree Diagram 299 The following diagram is largely a duplicate of the contents of 300 [RFC8366], with the addition of proximity-registrar-subject-public- 301 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 303 prior-signed-voucher-request is only used between the Registrar and 304 the MASA. proximity-registrar-subject-public-key-info replaces 305 proximity-registrar-cert for the extremely constrained cases. 307 module: ietf-constrained-voucher-request 309 grouping voucher-request-constrained-grouping 310 +-- voucher 311 +-- created-on? 312 | yang:date-and-time 313 +-- expires-on? 314 | yang:date-and-time 315 +-- assertion 316 | enumeration 317 +-- serial-number 318 | string 319 +-- idevid-issuer? 320 | binary 321 +-- pinned-domain-cert? 322 | binary 323 +-- domain-cert-revocation-checks? 324 | boolean 325 +-- nonce? 326 | binary 327 +-- last-renewal-date? 328 | yang:date-and-time 329 +-- proximity-registrar-subject-public-key-info? 330 | binary 331 +-- proximity-registrar-sha256-of-subject-public-key-info? 332 | binary 333 +-- proximity-registrar-cert? 334 | binary 335 +-- prior-signed-voucher-request? 336 binary 338 6.1.2. SID values 339 Base SID value for voucher request: 1001150. 341 SID Assigned to 342 --------- -------------------------------------------------- 343 1001167 module ietf-constrained-voucher-request 344 1001168 module ietf-restconf 345 1001169 module ietf-voucher 346 1001170 module ietf-yang-types 347 1001171 data /ietf-constrained-voucher-request:voucher 348 1001154 data .../ietf-constrained-voucher-request:voucher 349 1001155 data .../assertion 350 1001156 data .../created-on 351 1001157 data .../domain-cert-revocation-checks 352 1001158 data .../expires-on 353 1001159 data .../idevid-issuer 354 1001160 data .../last-renewal-date 355 1001161 data .../nonce 356 1001162 data .../pinned-domain-cert 357 1001165 data .../prior-signed-voucher-request 358 1001166 data .../proximity-registrar-cert 359 1001163 data .../proximity-registrar-subject-public-key-info 360 1001164 data .../serial-number 361 1001172 data .../assertion 362 1001173 data .../created-on 363 1001174 data .../domain-cert-revocation-checks 364 1001175 data .../expires-on 365 1001176 data .../idevid-issuer 366 1001177 data .../last-renewal-date 367 1001178 data /ietf-constrained-voucher-request:voucher/nonce 368 1001179 data .../pinned-domain-cert 369 1001180 data .../prior-signed-voucher-request 370 1001181 data .../proximity-registrar-cert 371 1001182 data .../proximity-registrar-subject-public-key-info 372 1001183 data .../serial-number 373 1001150 data ietf-constrained-voucher-request 374 1001151 data ietf-restconf 375 1001152 data ietf-voucher 376 1001153 data ietf-yang-types 378 WARNING, obsolete definitions 380 6.1.3. YANG Module 382 In the constrained-voucher-request YANG module, the voucher is 383 "augmented" within the "used" grouping statement such that one 384 continuous set of SID values is generated for the constrained- 385 voucher-request module name, all voucher attributes, and the 386 constrained-voucher-request attribute. Two attributes of the voucher 387 are "refined" to be optional. 389 file "ietf-constrained-voucher-request@2018-09-01.yang" 390 module ietf-constrained-voucher-request { 391 yang-version 1.1; 393 namespace 394 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 395 prefix "constrained"; 397 import ietf-restconf { 398 prefix rc; 399 description 400 "This import statement is only present to access 401 the yang-data extension defined in RFC 8040."; 402 reference "RFC 8040: RESTCONF Protocol"; 403 } 405 import ietf-voucher { 406 prefix "v"; 407 } 409 organization 410 "IETF ANIMA Working Group"; 412 contact 413 "WG Web: 414 WG List: 415 Author: Michael Richardson 416 417 Author: Peter van der Stok 418 419 Author: Panos Kampanakis 420 "; 421 description 422 "This module defines the format for a voucher request, 423 which is produced by a pledge to request a voucher. 424 The voucher-request is sent to the potential owner's 425 Registrar, which in turn sends the voucher request to 426 the manufacturer or delegate (MASA). 428 A voucher is then returned to the pledge, binding the 429 pledge to the owner. This is a constrained version of the 430 voucher-request present in 431 draft-ietf-anima-bootstrap-keyinfra.txt. 433 This version provides a very restricted subset appropriate 434 for very constrained devices. 435 In particular, it assumes that nonce-ful operation is 436 always required, that expiration dates are rather weak, as no 437 clocks can be assumed, and that the Registrar is identified 438 by a pinned Raw Public Key. 440 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 441 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 442 and 'OPTIONAL' in the module text are to be interpreted as 443 described in RFC 2119."; 445 revision "2018-09-01" { 446 description 447 "Initial version"; 448 reference 449 "RFC XXXX: Voucher Profile for Constrained Devices"; 450 } 452 rc:yang-data voucher-request-constrained-artifact { 453 // YANG data template for a voucher. 454 uses voucher-request-constrained-grouping; 455 } 457 // Grouping defined for future usage 458 grouping voucher-request-constrained-grouping { 459 description 460 "Grouping to allow reuse/extensions in future work."; 462 uses v:voucher-artifact-grouping { 464 refine voucher/created-on { 465 mandatory false; 466 } 468 refine voucher/pinned-domain-cert { 469 mandatory false; 470 } 472 augment "voucher" { 473 description "Base the constrained voucher-request upon the 474 regular one"; 476 leaf proximity-registrar-subject-public-key-info { 477 type binary; 478 description 479 "The proximity-registrar-subject-public-key-info replaces 480 the proximit-registrar-cert in constrained uses of 481 the voucher-request. 482 The proximity-registrar-subject-public-key-info is the 483 Raw Public Key of the Registrar. This field is encoded 484 as specified in RFC7250, section 3. 485 The ECDSA algorithm MUST be supported. 486 The EdDSA algorithm as specified in 487 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 488 Support for the DSA algorithm is not recommended. 489 Support for the RSA algorithm is MAY, but due to 490 size is discouraged."; 491 } 493 leaf proximity-registrar-sha256-of-subject-public-key-info { 494 type binary; 495 description 496 "The proximity-registrar-sha256-of-subject-public-key-info 497 is an alternative to 498 proximity-registrar-subject-public-key-info. 499 and pinned-domain-cert. In many cases the 500 public key of the domain has already been transmitted 501 during the key agreement protocol, and it is wasteful 502 to transmit the public key another two times. 503 The use of a hash of public key info, at 32-bytes for 504 sha256 is a significant savings compared to an RSA 505 public key, but is only a minor savings compared to 506 a 256-bit ECDSA public-key. 507 Algorithm agility is provided by extensions to this 508 specifications which define new leaf for other hash 509 types."; 510 } 512 leaf proximity-registrar-cert { 513 type binary; 514 description 515 "An X.509 v3 certificate structure as specified by 516 RFC 5280, 517 Section 4 encoded using the ASN.1 distinguished encoding 518 rules (DER), as specified in ITU-T X.690. 520 The first certificate in the Registrar TLS server 521 certificate_list sequence (see [RFC5246]) presented by 522 the Registrar to the Pledge. This MUST be populated in a 523 Pledge's voucher request if the proximity assertion is 524 populated."; 525 } 527 leaf prior-signed-voucher-request { 528 type binary; 529 description 530 "If it is necessary to change a voucher, or re-sign and 531 forward a voucher that was previously provided along a 532 protocol path, then the previously signed voucher 533 SHOULD be included in this field. 535 For example, a pledge might sign a proximity voucher, 536 which an intermediate registrar then re-signs to 537 make its own proximity assertion. This is a simple 538 mechanism for a chain of trusted parties to change a 539 voucher, while maintaining the prior signature 540 information. 542 The pledge MUST ignore all prior voucher information 543 when accepting a voucher for imprinting. Other 544 parties MAY examine the prior signed voucher 545 information for the purposes of policy decisions. 546 For example this information could be useful to a 547 MASA to determine that both pledge and registrar 548 agree on proximity assertions. The MASA SHOULD 549 remove all prior-signed-voucher-request information when 550 signing a voucher for imprinting so as to minimize the 551 final voucher size."; 552 } 553 } 554 } 555 } 556 } 557 559 6.1.4. Example voucher request artifact 561 Below a CBOR serialization of the constrained-voucher-request is 562 shown in diagnostic CBOR notation. The enum value of the assertion 563 field is calculated to be zero by following the algorithm described 564 in section 9.6.4.2 of [RFC7950]. 566 { 567 1001154: { 568 +2 : "2016-10-07T19:31:42Z", / SID= 1001156, created-on / 569 +4 : "2016-10-21T19:31:42Z", / SID= 1001158, expires-on / 570 +1 : 2, / SID= 1001155, assertion / 571 / "proximity" / 572 +13: "JADA123456789", / SID= 1001167, serial-number / 573 +5 : h'01020D0F', / SID= 1001159, idevid-issuer / 574 +10: h'01020D0F', / SID=1001064, proximity-registrar-cert/ 575 +3 : true, / SID= 1001157, domain-cert 576 -revocation-checks/ 577 +6 : "2017-10-07T19:31:42Z", / SID= 1001160, last-renewal-date / 578 +12: h'01020D0F' / SID= 1001166, proximity-registrar 579 -subject-public-key-info / 580 } 581 } 583 6.2. Voucher artifact 585 The voucher's primary purpose is to securely assign a pledge to an 586 owner. The voucher informs the pledge which entity it should 587 consider to be its owner. 589 This document defines a voucher that is a CBOR encoded instance of 590 the YANG module defined in Section 5.3 that has been signed with CMS 591 or with COSE. 593 6.2.1. Tree Diagram 595 The following diagram is largely a duplicate of the contents of 596 [RFC8366], with only the addition of pinned-domain-subject-public- 597 key-info. 599 module: ietf-constrained-voucher 601 grouping voucher-constrained-grouping 602 +-- voucher 603 +-- created-on? 604 | yang:date-and-time 605 +-- expires-on? 606 | yang:date-and-time 607 +-- assertion enumeration 608 +-- serial-number string 609 +-- idevid-issuer? binary 610 +-- pinned-domain-cert? binary 611 +-- domain-cert-revocation-checks? boolean 612 +-- nonce? binary 613 +-- last-renewal-date? 614 | yang:date-and-time 615 +-- pinned-domain-subject-public-key-info? binary 616 +-- pinned-sha256-of-subject-public-key-info? binary 618 6.2.2. SID values 620 Base SID value for voucher request: 1001101. 622 SID Assigned to 623 --------- -------------------------------------------------- 624 1001115 module ietf-constrained-voucher 625 1001116 module ietf-restconf 626 1001117 module ietf-voucher 627 1001118 module ietf-yang-types 628 1001119 data /ietf-constrained-voucher:voucher 629 1001104 data .../ietf-constrained-voucher:voucher 630 1001105 data .../assertion 631 1001106 data .../created-on 632 1001107 data .../domain-cert-revocation-checks 633 1001108 data .../expires-on 634 1001109 data .../idevid-issuer 635 1001110 data .../last-renewal-date 636 1001111 data .../nonce 637 1001112 data .../pinned-domain-cert 638 1001113 data .../pinned-domain-subject-public-key-info 639 1001114 data .../serial-number 641 6.2.3. YANG Module 643 In the constraine-voucher YANG module, the voucher is "augmented" 644 within the "used" grouping statement such that one continuous set of 645 SID values is generated for the constrained-voucher module name, all 646 voucher attributes, and the constrained-voucher attribute. Two 647 attributes of the voucher are "refined" to be optional. 649 file "ietf-constrained-voucher@2018-09-01.yang" 650 module ietf-constrained-voucher { 651 yang-version 1.1; 653 namespace 654 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 655 prefix "constrained"; 657 import ietf-restconf { 658 prefix rc; 659 description 660 "This import statement is only present to access 661 the yang-data extension defined in RFC 8040."; 662 reference "RFC 8040: RESTCONF Protocol"; 663 } 665 import ietf-voucher { 666 prefix "v"; 667 } 669 organization 670 "IETF ANIMA Working Group"; 672 contact 673 "WG Web: 674 WG List: 675 Author: Michael Richardson 676 677 Author: Peter van der Stok 678 679 Author: Panos Kampanakis 680 "; 681 description 682 "This module defines the format for a voucher, which is produced 683 by a pledge's manufacturer or delegate (MASA) to securely assign 684 one or more pledges to an 'owner', so that the pledges may 685 establis a secure connection to the owner's network 686 infrastructure. 688 This version provides a very restricted subset appropriate 689 for very constrained devices. 690 In particular, it assumes that nonce-ful operation is 691 always required, that expiration dates are rather weak, as no 692 clocks can be assumed, and that the Registrar is identified 693 by a pinned Raw Public Key. 695 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 696 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 697 and 'OPTIONAL' in the module text are to be interpreted as 698 described in RFC 2119."; 700 revision "2018-09-01" { 701 description 702 "Initial version"; 703 reference 704 "RFC XXXX: Voucher Profile for Constrained Devices"; 705 } 707 rc:yang-data voucher-constrained-artifact { 708 // YANG data template for a voucher. 709 uses voucher-constrained-grouping; 710 } 712 // Grouping defined for future usage 713 grouping voucher-constrained-grouping { 714 description 715 "Grouping to allow reuse/extensions in future work."; 717 uses v:voucher-artifact-grouping { 719 refine voucher/created-on { 720 mandatory false; 721 } 723 refine voucher/pinned-domain-cert { 724 mandatory false; 725 } 727 augment "voucher" { 728 description "Base the constrained voucher 729 upon the regular one"; 730 leaf pinned-domain-subject-public-key-info { 731 type binary; 732 description 733 "The pinned-domain-subject-public-key-info replaces the 734 pinned-domain-cert in constrained uses of 735 the voucher. The pinned-domain-subject-public-key-info 736 is the Raw Public Key of the Registrar. 737 This field is encoded as specified in RFC7250, 738 section 3. 739 The ECDSA algorithm MUST be supported. 740 The EdDSA algorithm as specified in 741 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 742 Support for the DSA algorithm is not recommended. 744 Support for the RSA algorithm is a MAY."; 745 } 747 leaf pinned-sha256-of-subject-public-key-info { 748 type binary; 749 description 750 "The pinned-hash-subject-public-key-info is a second 751 alternative to pinned-domain-cert. In many cases the 752 public key of the domain has already been transmitted 753 during the key agreement process, and it is wasteful 754 to transmit the public key another two times. 755 The use of a hash of public key info, at 32-bytes for 756 sha256 is a significant savings compared to an RSA 757 public key, but is only a minor savings compared to 758 a 256-bit ECDSA public-key. 759 Algorithm agility is provided by extensions to this 760 specifications which define new leaf for other hash types"; 761 } 762 } 763 } 764 } 765 } 766 768 6.2.4. Example voucher artifacts 770 Below a the CBOR serialization of the the constrained-voucher is 771 shown in diagnostic CBOR notation. The enum value of the assertion 772 field is calculated to be zero by following the algorithm described 773 in section 9.6.4.2 of [RFC7950]. 775 { 776 1001104: { 777 +2 : "2016-10-07T19:31:42Z", / SID = 1001106, created-on / 778 +4 : "2016-10-21T19:31:42Z", / SID = 1001108, expires-on / 779 +1 : 0, / SID = 1001105, assertion / 780 / "verified" / 781 +11: "JADA123456789", / SID = 1001115, serial-number / 782 +5 : h'01020D0F', / SID = 1001109, idevid-issuer / 783 +8 : h'01020D0F', / SID = 1001112, pinned-domain-cert/ 784 +3 : true, / SID = 1001107, domain-cert 785 -revocation-checks / 786 +6 : "2017-10-07T19:31:42Z", / SID = 1001110, last-renewal-date / 787 +9 : h'01020D0F' / SID = 1001113, pinned-domain 788 -subject-public-key-info / 789 } 790 } 792 The signing of the example is shown in Appendix B.1. 794 6.3. Signing voucher and voucher-request artifacts 796 6.3.1. CMS signing 798 The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed 799 voucher is much like the equivalent voucher defined in [RFC8366]. 801 A different eContentType of TBD1 is used to indicate that the 802 contents are in a different format than in [RFC8366]. 804 The ContentInfo structure contains a payload consisting of the CBOR 805 encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding 806 creates a canonical ordering for the keys on the wire. This 807 canonical ordering is not important as there is no expectation that 808 the content will be reproduced during the validation process. 810 Normally the recipient is the pledge and the signer is the MASA. 812 [I-D.ietf-anima-bootstrapping-keyinfra] supports both signed and 813 unsigned voucher requests from the pledge to the JRC. In this 814 specification, voucher-request artifact MUST be signed from the 815 pledge to the registrar. From the JRC to the MASA, the voucher- 816 request artifact MUST be signed by the domain owner key which is 817 requesting ownership. 819 The considerations of [RFC5652] section 5.1, concerning validating 820 CMS objects which are really PKCS7 objects (cmsVersion=1) applies. 822 The CMS structure SHOULD also contain all the certificates leading up 823 to and including the signer's trust anchor certificate known to the 824 recipient. The inclusion of the trust anchor is unusual in many 825 applications, but without it third parties can not accurately audit 826 the transaction. 828 The CMS structure MAY also contain revocation objects for any 829 intermediate certificate authorities (CAs) between the voucher-issuer 830 and the trust anchor known to the recipient. However, the use of 831 CRLs and other validity mechanisms is discouraged, as the pledge is 832 unlikely to be able to perform online checks, and is unlikely to have 833 a trusted clock source. As described below, the use of short-lived 834 vouchers and/or pledge provided nonce provides a freshness guarantee. 836 [EDnote: compulsory signing algorithms are ....] 838 In Appendix B.1 an example for the CMS signing of the voucher-request 839 is shown. 841 6.3.2. COSE signing 843 The COSE-Sign1 structure is discussed in section 4.2 of [RFC8152]. 844 The CBOR object that carries the body, the signature, and the 845 information about the body and signature is called the COSE_Sign1 846 structure. It is used when only one signature is used on the body. 847 Support for EDdsa 256 with Ed25519 is compulsory. 849 The supported COSE-sign1 object stucture is shown in Figure 1. 851 COSE_Sign1( 852 [ 853 h'a10126', #{ "alg": EDdsa 256 } 854 { 855 "crv": Ed25519, 856 "kty": OKP, 857 "key_ops": "verify" 858 }, 859 h'123', #voucher-request binary content 860 h'456', #voucher-request binary public signature 861 ] 862 ) 864 Figure 1: The cose-sign1 structure. 866 The [COSE-registry] specifies the integers that replace the strings 867 and the mnemonics in Figure 1. In Appendix C a binary cose-sign1 868 object is shown based on the voucher-request example of 869 Section 6.1.4. 871 7. Design Considerations 873 The design considerations for the CBOR encoding of vouchers is much 874 the same as for [RFC8366]. 876 One key difference is that the names of the leaves in the YANG does 877 not have a material effect on the size of the resulting CBOR, as the 878 SID translation process assigns integers to the names. 880 8. Security Considerations 882 8.1. Clock Sensitivity 884 TBD. 886 8.2. Protect Voucher PKI in HSM 888 TBD. 890 8.3. Test Domain Certificate Validity when Signing 892 TBD. 894 9. IANA Considerations 896 9.1. Resource Type Registry 898 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 899 parameters" registry are specified below. These can be registered 900 either in the Expert Review range (0-255) or IETF Review range 901 (256-9999). 903 ace.rt.rv needs registration with IANA 904 ace.rt.vs needs registration with IANA 905 ace.rt.es needs registration with IANA 906 ace.rt.ra needs registration with IANA 908 9.2. The IETF XML Registry 910 This document registers two URIs in the IETF XML registry [RFC3688]. 911 Following the format in [RFC3688], the following registration is 912 requested: 914 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 915 Registrant Contact: The ANIMA WG of the IETF. 916 XML: N/A, the requested URI is an XML namespace. 918 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 919 Registrant Contact: The ANIMA WG of the IETF. 920 XML: N/A, the requested URI is an XML namespace. 922 9.3. The YANG Module Names Registry 924 This document registers two YANG modules in the YANG Module Names 925 registry [RFC6020]. Following the format defined in [RFC6020], the 926 the following registration is requested: 928 name: ietf-constrained-voucher 929 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 930 prefix: vch 931 reference: RFC XXXX 933 name: ietf-constrained-voucher-request 934 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 935 -voucher-request 936 prefix: vch 937 reference: RFC XXXX 939 9.4. The RFC SID range assignment sub-registry 941 ------------ ------ --------------------------- ------------ 942 Entry-point | Size | Module name | RFC Number 943 ------------ ------ --------------------------- ------------ 944 1001100 50 ietf-constrained-voucher [ThisRFC] 945 1001150 50 ietf-constrained-voucher [ThisRFC} 946 -request 947 ----------- ------ --------------------------- ------------ 949 Warning: These SID values will change when they transfer to the range 950 1000 - 59,999 allocated for SIDs in YANG modules defined in RFCs. 952 9.5. The SMI Security for S/MIME CMS Content Type Registry 954 This document registers an OID in the "SMI Security for S/MIME CMS 955 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 957 Decimal Description References 958 ------- -------------------------------------- ---------- 959 TBD1 id-ct-animaCBORVoucher [ThisRFC] 961 EDNOTE: should a separate value be used for Voucher Requests? 963 9.6. Media-Type Registry 965 This section registers the 'application/voucher-cms+cbor' media type 966 and the 'application/voucher-cose+cbor'in the "Media Types" registry. 967 These media types are used to indicate that the content is a CBOR 968 voucher either signed with a cms structure or a COSE_Sign1 structure 969 [RFC8152]. 971 9.6.1. application/voucher-cms+cbor 973 Type name: application 974 Subtype name: voucher-cms+cbor 975 Required parameters: none 976 Optional parameters: none 977 Encoding considerations: CMS-signed CBOR vouchers are CBOR 978 encoded. 979 Security considerations: See Security Considerations, Section 980 Interoperability considerations: The format is designed to be 981 broadly interoperable. 982 Published specification: THIS RFC. 983 Applications that use this media type: ANIMA, 6tisch, and other 984 zero-touch imprinting systems 985 Additional information: 986 Magic number(s): None 987 File extension(s): .vch 988 Macintosh file type code(s): none 989 Person & email address to contact for further information: IETF 990 ANIMA WG 991 Intended usage: LIMITED 992 Restrictions on usage: NONE 993 Author: ANIMA WG 994 Change controller: IETF 995 Provisional registration? (standards tree only): NO 997 9.6.2. application/voucher-cose+cbor 998 Type name: application 999 Subtype name: voucher-cose+cbor 1000 Required parameters: none 1001 Optional parameters: cose-type 1002 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 1003 signed with one signer. 1004 Security considerations: See Security Considerations, Section 1005 Interoperability considerations: The format is designed to be 1006 broadly interoperable. 1007 Published specification: THIS RFC. 1008 Applications that use this media type: ANIMA, 6tisch, and other 1009 zero-touch imprinting systems 1010 Additional information: 1011 Magic number(s): None 1012 File extension(s): .vch 1013 Macintosh file type code(s): none 1014 Person & email address to contact for further information: IETF 1015 ANIMA WG 1016 Intended usage: LIMITED 1017 Restrictions on usage: NONE 1018 Author: ANIMA WG 1019 Change controller: IETF 1020 Provisional registration? (standards tree only): NO 1022 9.7. CoAP Content-Format Registry 1024 Additions to the sub-registry "CoAP Content-Formats", within the 1025 "CoRE Parameters" registry are needed for two media types. These can 1026 be registered either in the Expert Review range (0-255) or IETF 1027 Review range (256-9999). 1029 Media type mime type Encoding ID References 1030 ---------------------------- ----------- --------- ---- ---------- 1031 application/voucher-cms+cbor - - CBOR TBD2 [This RFC] 1032 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 1034 10. Acknowledgements 1036 We are very grateful to Jim Schaad for explaining COSE and CMS 1037 choices. 1039 Michel Veillette did extensive work on pyang to extend it to support 1040 the SID allocation process, and this document was among the first 1041 users. 1043 We are grateful for the suggestions done by Esko Dijk. 1045 11. Changelog 1047 -04 voucher and request-voucher MUST be signed examples for signed 1048 request are added in appendix IANA SID registration is updated SID 1049 values in examples are aligned signed cms examples aligned with new 1050 SIDs 1052 -03 1054 Examples are inverted. 1056 -02 1058 Example of requestvoucher with unsigned appllication/cbor is added 1059 attributes of voucher "refined" to optional 1060 CBOR serialization of vouchers improved 1061 Discovery port numbers are specified 1063 -01 1065 application/json is optional, application/cbor is compulsory 1066 Cms and cose mediatypes are introduced 1068 12. References 1070 12.1. Normative References 1072 [I-D.ietf-ace-cbor-web-token] 1073 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1074 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 1075 (work in progress), March 2018. 1077 [I-D.ietf-ace-coap-est] 1078 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 1079 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 1080 est-12 (work in progress), June 2019. 1082 [I-D.ietf-anima-bootstrapping-keyinfra] 1083 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1084 S., and K. Watsen, "Bootstrapping Remote Secure Key 1085 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1086 keyinfra-22 (work in progress), June 2019. 1088 [I-D.ietf-core-object-security] 1089 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1090 "Object Security for Constrained RESTful Environments 1091 (OSCORE)", draft-ietf-core-object-security-16 (work in 1092 progress), March 2019. 1094 [I-D.ietf-core-sid] 1095 Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item 1096 iDentifier (SID)", draft-ietf-core-sid-06 (work in 1097 progress), March 2019. 1099 [I-D.ietf-core-yang-cbor] 1100 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 1101 Data Modeled with YANG", draft-ietf-core-yang-cbor-10 1102 (work in progress), April 2019. 1104 [ieee802-1AR] 1105 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1106 2009, . 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, 1111 DOI 10.17487/RFC2119, March 1997, 1112 . 1114 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1115 DOI 10.17487/RFC3688, January 2004, 1116 . 1118 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1119 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1120 . 1122 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1123 the Network Configuration Protocol (NETCONF)", RFC 6020, 1124 DOI 10.17487/RFC6020, October 2010, 1125 . 1127 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1128 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1129 October 2013, . 1131 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1132 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1133 Transport Layer Security (TLS) and Datagram Transport 1134 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1135 June 2014, . 1137 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1138 Application Protocol (CoAP)", RFC 7252, 1139 DOI 10.17487/RFC7252, June 2014, 1140 . 1142 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1143 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1144 . 1146 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1147 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1148 . 1150 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1151 "A Voucher Artifact for Bootstrapping Protocols", 1152 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1153 . 1155 12.2. Informative References 1157 [COSE-registry] 1158 IANA, ., "CBOR Object Signing and Encryption (COSE) 1159 registry", 2017, 1160 . 1162 [duckling] 1163 Stajano, F. and R. Anderson, "The resurrecting duckling: 1164 security issues for ad-hoc wireless networks", 1999, 1165 . 1168 [I-D.ietf-netmod-yang-tree-diagrams] 1169 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1170 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1171 February 2018. 1173 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 1174 . 1176 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1177 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1178 . 1180 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1181 "Enrollment over Secure Transport", RFC 7030, 1182 DOI 10.17487/RFC7030, October 2013, 1183 . 1185 Appendix A. EST messages to EST-coaps 1187 This section extends the examples from Appendix A of 1188 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1189 the enrollstatus example. 1191 A.1. enrollstatus 1193 A coaps enrollstatus message can be : 1195 GET coaps://[192.0.2.1:8085]/est/es 1197 The corresponding coap header fields are shown below. 1199 Ver = 1 1200 T = 0 (CON) 1201 Code = 0x01 (0.01 is GET) 1202 Options 1203 Option (Uri-Path) 1204 Option Delta = 0xb (option nr = 11) 1205 Option Length = 0x3 1206 Option Value = "est" 1207 Option (Uri-Path) 1208 Option Delta = 0x0 (option nr = 11) 1209 Option Length = 0x2 1210 Option Value = "es" 1211 Payload = [Empty] 1213 The Uri-Host and Uri-Port Options are omitted because they coincide 1214 with the transport protocol destination address and port 1215 respectively. 1217 A 2.05 Content response with an unsigned voucher status (ct=60) will 1218 then be: 1220 2.05 Content (Content-Format: application/cbor) 1222 With CoAP fields and payload: 1224 Ver=1 1225 T=2 (ACK) 1226 Code = 0x45 (2.05 Content) 1227 Options 1228 Option1 (Content-Format) 1229 Option Delta = 0xC (option nr 12) 1230 Option Length = 0x2 1231 Option Value = 60 (application/cbor) 1233 Payload (CBOR diagnostic) = 1234 { 1235 "version":"1", 1236 "Status": 1, / 1 = Success, 0 = Fail / 1237 "Reason":"Informative human readable message", 1238 "reason-context": "Additional information" 1239 } 1241 Payload (binary) = 1242 A46776657273696F6E6131665374617475730166526561736F6E7822 1243 496E666F726D61746976652068756D616E207265616461626C65206D 1244 6573736167656e726561736F6E2D636F6E74657874 1245 764164646974696F6E616C20696E666F726D6174696F6E 1246 ~~~ 1248 ##voucher_status 1250 A coaps voucher_status message can be : 1252 GET coaps://[2001:db8::2:1]:61616]/est/vs ~~~~ 1254 A 2.05 Content response with a non signed CBOR voucher (ct=60) will 1255 then be: 1257 2.05 Content (Content-Format: application/cbor) 1258 Payload = 1259 A46776657273696F6E6131665374617475730166526561736F6E7822 1260 496E666F726D61746976652068756D616E207265616461626C65206D 1261 6573736167656e726561736F6E2D636F6E74657874 1262 764164646974696F6E616C20696E666F726D6174696F6E 1264 A.2. requestvoucher 1266 Signed request-voucher-request payloads are sent from pledge to 1267 Registrar, as explained in Section 5.2 of 1268 [I-D.ietf-anima-bootstrapping-keyinfra]. 1270 A.2.1. signed requestvoucher 1272 A CMS signed requestvoucher message from JRC to MASA is shown below. 1273 It would be CoAP POSTED to /est/rv. 1275 POST coaps://[2001:db8::2:1]:61616]/est/rv 1276 (Content-Format: application/voucher-cms+cbor) 1278 The payload would be in binary, but is presented in base64 in this 1279 document. 1281 MIIDugYJKoZIhvcNAQcCoIIDqzCCA6cCAQExDTALBglghkgBZQMEAgEwCwYJ 1282 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1283 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1284 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1285 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1286 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1287 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1288 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1289 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1290 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1291 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1292 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1293 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1294 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1295 3m00kjYxggE/MIIBOwIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1296 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1297 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1298 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1299 DTE5MDQwODEwNDgzNlowLwYJKoZIhvcNAQkEMSIEILEdCTOLs2Zy7w3LgvSZ 1300 XZEadz3LbznoFBs6FMFN91RaMAoGCCqGSM49BAMCBEcwRQIgASjDsIpr0tW/ 1301 n6dRHqvvqsqgZlHbtFnErUbWfhS0KD4CIQDDUEqc5wTmRGf0adEQVQzqmIgh 1302 MEgF10vqXv02gL1jLw== 1304 A 2.04 Changed response returning CBOR voucher signed with a cms 1305 structure(ct=TBD2) will then be: 1307 2.04 Changed (Content-Format: application/voucher-cms+cbor) 1309 MIIDuwYJKoZIhvcNAQcCoIIDrDCCA6gCAQExDTALBglghkgBZQMEAgEwCwYJ 1310 KoZIhvcNAQcBoIICQTCCAj0wggHioAMCAQICCH52Yde1TkYyMAoGCCqGSM49 1311 BAMCMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UECgwLRXhh 1312 bXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRpb24xEzARBgNVBAMMCjgw 1313 Mi4xQVIgQ0EwIBcNMTkwMTMxMTEyOTE2WhgPOTk5OTEyMzEyMzU5NTlaMFwx 1314 CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTELMAkGA1UEBwwCTEExFDASBgNV 1315 BAoMC2V4YW1wbGUgSW5jMQwwCgYDVQQLDANJb1QxDzANBgNVBAUTBld0MTIz 1316 NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMi0IfEcJeR+OsVxI78tn9xJ 1317 TwKLw1HMgMA/FQv1DP+VjXVBnYGmokXf+ueQvpXPdfYC+RUmGPgWorI7Vjjl 1318 n9mjgYowgYcwCQYDVR0TBAIwADAdBgNVHQ4EFgQUlmANhxa/f9DnUtCsdgd3 1319 rWZdAqAwHwYDVR0jBBgwFoAUaNFlUflRv8gqQx0Nnwi8LSBbEWAwDgYDVR0P 1320 AQH/BAQDAgWgMCoGA1UdEQQjMCGgHwYIKwYBBQUHCASgEzARBgkrBgEEAbQ7 1321 CgEEBAECAwQwCgYIKoZIzj0EAwIDSQAwRgIhAMDYGZbSUH1pPzxI6qXulJG9 1322 ptshQJnZgRfGOzYTdM2GAiEAp3SYn0wyGlzyXYMqTTNqCK1n3yDxUGQhGIoK 1323 3m00kjYxggFAMIIBPAIBATBpMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJD 1324 QTEUMBIGA1UECgwLRXhhbXBsZSBJbmMxFjAUBgNVBAsMDWNlcnRpZmljYXRp 1325 b24xEzARBgNVBAMMCjgwMi4xQVIgQ0ECCH52Yde1TkYyMAsGCWCGSAFlAwQC 1326 AaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X 1327 DTE5MDQwODA3MzQxMFowLwYJKoZIhvcNAQkEMSIEIP2rKa+J8LVdwYEmB2he 1328 uxsz05As0zoAAYkeyNqsh4fiMAoGCCqGSM49BAMCBEgwRgIhALOd2FKbe9FG 1329 kN4Pg7FIgF+//cQv/N+v7tDZMzGBAFN0AiEAu5BI0oQ4o0wZcrDyKoU2GbeX 1330 hlG/g+OgTUftYMJ32so= 1332 A.3. requestauditing 1334 A coaps requestauditing message contains the signed CBOR voucher : 1336 POST coaps://[2001:db8::2:1]:61616]/est/ra 1337 (Content-Format: application/voucher-cms+cbor) 1338 Payload = 1339 308203ba06092a864886f70d010702a08203ab308203a7020101310d300b 1340 0609608648016503040201300b06092a864886f70d010701a08202413082 1341 023d308201e2a00302010202087e7661d7b54e4632300a06082a8648ce3d 1342 040302305d310b3009060355040613025553310b300906035504080c0243 1343 4131143012060355040a0c0b4578616d706c6520496e6331163014060355 1344 040b0c0d63657274696669636174696f6e3113301106035504030c0a3830 1345 322e3141522043413020170d3139303133313131323931365a180f393939 1346 39313233313233353935395a305c310b3009060355040613025553310b30 1347 0906035504080c024341310b300906035504070c024c4131143012060355 1348 040a0c0b6578616d706c6520496e63310c300a060355040b0c03496f5431 1349 0f300d060355040513065774313233343059301306072a8648ce3d020106 1350 082a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc49 1351 4f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf 1352 75f602f9152618f816a2b23b5638e59fd9a3818a30818730090603551d13 1353 04023000301d0603551d0e0416041496600d8716bf7fd0e752d0ac760777 1354 ad665d02a0301f0603551d2304183016801468d16551f951bfc82a431d0d 1355 9f08bc2d205b1160300e0603551d0f0101ff0404030205a0302a0603551d 1356 1104233021a01f06082b06010505070804a013301106092b06010401b43b 1357 0a01040401020304300a06082a8648ce3d0403020349003046022100c0d8 1358 1996d2507d693f3c48eaa5ee9491bda6db214099d98117c63b361374cd86 1359 022100a774989f4c321a5cf25d832a4d336a08ad67df20f1506421188a0a 1360 de6d3492363182013f3082013b0201013069305d310b3009060355040613 1361 025553310b300906035504080c02434131143012060355040a0c0b457861 1362 6d706c6520496e6331163014060355040b0c0d6365727469666963617469 1363 6f6e3113301106035504030c0a3830322e31415220434102087e7661d7b5 1364 4e4632300b0609608648016503040201a069301806092a864886f70d0109 1365 03310b06092a864886f70d010701301c06092a864886f70d010905310f17 1366 0d3139303430383130343833365a302f06092a864886f70d010904312204 1367 20b11d09338bb36672ef0dcb82f4995d911a773dcb6f39e8141b3a14c14d 1368 f7545a300a06082a8648ce3d0403020447304502200128c3b08a6bd2d5bf 1369 9fa7511eabefaacaa06651dbb459c4ad46d67e14b4283e022100c3504a9c 1370 e704e64467f469d110550cea988821304805d74bea5efd3680bd632f 1372 A 2.05 Content response returning a log of the voucher (ct=60) will 1373 then be: 1375 2.05 Content (Content-Format: application/cbor) 1376 Payload = 1377 { 1378 "version":"1", 1379 "events":[ 1380 { 1381 "date":"", 1382 "domainID":"", 1383 "nonce":"" 1384 "assertion":"" 1385 "truncated":"" 1386 }, 1387 { 1388 "date":"", 1389 "domainID":"", 1390 "nonce":"" 1391 "assertion":"" 1392 } 1393 ], 1394 "truncation": { 1395 "nonced duplicates": "", 1396 "nonceless duplicates": "", 1397 "arbitrary": "" 1398 } 1399 } 1401 [EDNOTE: Change JSON to CBOR; Serialize CBOR payload to binary] 1403 Appendix B. Signed voucher-request examples 1405 B.1. CMS signed voucher-request example 1407 The voucher-request example, visualized in CBOR diagnostic notation 1408 in Section 6.1.4 is shown as a hexadecimal dump of the binary file. 1410 A11A000F46C2A90274323031362D31302D30375431393A33313A34325A0 1411 474323031362D31302D32315431393A33313A34325A01020d6d4A414441 1412 313233343536373839054401020D0F0A4401020D0F03F50674323031372 1413 D31302D30375431393A33313A34325A0c4401020D0F 1415 The voucher-request example has been signed by using the WT1234 1416 certificate and key pair shown in Appendix C of 1417 [I-D.ietf-ace-coap-est]. The CMS signing of the binary voucher- 1418 request leads to a binary signed voucher-request, shown with a 1419 hexadecimal representation shown in the payload of the request part 1420 of Appendix A.2.1 and Appendix A.3. 1422 The breakdown of the CMS signed binary voucher-request file is 1423 visualized below: 1425 CMS_ContentInfo: 1426 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1427 d.signedData: 1428 version: 1 1429 digestAlgorithms: 1430 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1431 parameter: 1432 encapContentInfo: 1433 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1434 eContent: 1435 certificates: 1436 d.certificate: 1437 cert_info: 1438 version: 2 1439 serialNumber: 9112578475118446130 1440 signature: 1441 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1442 parameter: 1443 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1444 CN=802.1AR CA 1445 validity: 1446 notBefore: Jan 31 11:29:16 2019 GMT 1447 notAfter: Dec 31 23:59:59 9999 GMT 1448 subject: C=US, ST=CA, L=LA, O=example Inc, 1449 OU=IoT/serialNumber=Wt1234 1450 key: 1451 algor: 1452 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1453 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1454 public_key: (0 unused bits) 1455 0000 - 04 c8 b4 21 f1 1c 25 e4-7e 3a c5 71 23 bf 1456 000e - 2d 9f dc 49 4f 02 8b c3-51 cc 80 c0 3f 15 1457 001c - 0b f5 0c ff 95 8d 75 41-9d 81 a6 a2 45 df 1458 002a - fa e7 90 be 95 cf 75 f6-02 f9 15 26 18 f8 1459 0038 - 16 a2 b2 3b 56 38 e5 9f-d9 1460 issuerUID: 1461 subjectUID: 1462 extensions: 1463 object: X509v3 Basic Constraints (2.5.29.19) 1464 critical: BOOL ABSENT 1465 value: 1466 0000 - 30 1467 0002 - 1469 object: X509v3 Subject Key Identifier (2.5.29.14) 1470 critical: BOOL ABSENT 1471 value: 1472 0000 - 04 14 96 60 0d 87 16 bf-7f d0 e7 52 d0 1473 000d - ac 76 07 77 ad 66 5d 02-a0 1475 object: X509v3 Authority Key Identifier (2.5.29.35) 1476 critical: BOOL ABSENT 1477 value: 1478 0000 - 30 16 80 14 68 d1 65 51-f9 51 bf c8 2a 1479 000d - 43 1d 0d 9f 08 bc 2d 20-5b 11 60 1481 object: X509v3 Key Usage (2.5.29.15) 1482 critical: TRUE 1483 value: 1484 0000 - 03 02 05 a0 1486 object: X509v3 Subject Alternative Name (2.5.29.17) 1487 critical: BOOL ABSENT 1488 value: 1489 0000 - 30 21 a0 1f 06 08 2b 06-01 05 05 07 08 1490 000d - 04 a0 13 30 11 06 09 2b-06 01 04 01 b4 1491 001a - 3b 0a 01 04 04 01 02 03-04 1492 sig_alg: 1493 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1494 parameter: 1495 signature: (0 unused bits) 1496 0000 - 30 46 02 21 00 c0 d8 19-96 d2 50 7d 69 3f 3c 1497 000f - 48 ea a5 ee 94 91 bd a6-db 21 40 99 d9 81 17 1498 001e - c6 3b 36 13 74 cd 86 02-21 00 a7 74 98 9f 4c 1499 002d - 32 1a 5c f2 5d 83 2a 4d-33 6a 08 ad 67 df 20 1500 003c - f1 50 64 21 18 8a 0a de-6d 34 92 36 1501 crls: 1502 1503 signerInfos: 1504 version: 1 1505 d.issuerAndSerialNumber: 1506 issuer: C=US, ST=CA, O=Example Inc, OU=certification, 1507 CN=802.1AR CA 1508 serialNumber: 9112578475118446130 1509 digestAlgorithm: 1510 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1511 parameter: 1512 signedAttrs: 1513 object: contentType (1.2.840.113549.1.9.3) 1514 value.set: 1515 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1517 object: signingTime (1.2.840.113549.1.9.5) 1518 value.set: 1519 UTCTIME:Jul 3 08:53:30 2019 GMT 1521 object: messageDigest (1.2.840.113549.1.9.4) 1522 value.set: 1523 OCTET STRING: 1524 0000 - d4 b0 5c dd c8 b4 91 28-4a 18 ca 25 9d 1525 000d - be d0 60 23 cf ad a0 aa-c2 95 ac e9 3f 1526 001a - 0b 4f 44 9e 25 1527 0020 - 1528 signatureAlgorithm: 1529 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1530 parameter: 1531 signature: 1532 0000 - 30 46 02 21 00 e5 e1 7f-23 c3 aa 14 9f 35 64 1533 000f - 1e c4 4a 0f 68 fe b0 16-3b e6 7c 06 51 af bf 1534 001e - 5a a0 99 59 e0 28 1f 02-21 00 b4 07 2f 7c c4 1535 002d - f9 26 0c 6d 47 a7 93 56-de b8 da f7 23 f0 af 1536 003c - 2b 59 16 cc 36 63 e7 91-89 39 df df 1537 unsignedAttrs: 1538 1540 Appendix C. COSE examples 1542 C.1. Device, Registrar and MASA keys 1544 This first section documents the public and private keys used in the 1545 subsequent test vectors below. These keys come from test code and 1546 are not used in any production system, and should only be used only 1547 to validate implementations. 1549 C.1.1. Device IDevID certificate 1550 Certificate: 1551 Data: 1552 Version: 3 (0x2) 1553 Serial Number: 787697345 (0x2ef34ec1) 1554 Signature Algorithm: ecdsa-with-SHA256 1555 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN 1556 = highway-test.example.com CA 1557 Validity 1558 Not Before: Feb 14 17:05:09 2019 GMT 1559 Not After : Dec 31 00:00:00 2999 GMT 1560 Subject: serialNumber = 00-D0-E5-F2-00-03 1561 Subject Public Key Info: 1562 Public Key Algorithm: id-ecPublicKey 1563 Public-Key: (256 bit) 1564 pub: 1565 04:82:c4:28:5b:7c:f0:37:18:c7:90:14:dc:c 1566 b:f4: 1567 4d:7e:b0:00:ed:c0:de:bd:4d:25:55:4e:35:f 1568 9:d5: 1569 6a:57:14:b4:94:af:ce:6d:53:c8:60:c2:ce:5 1570 3:3f: 1571 2c:1b:42:f1:c0:8b:5f:c1:7b:3d:f3:29:54:8 1572 7:46: 1573 86:a4:0c:8b:b7 1574 ASN1 OID: prime256v1 1575 NIST CURVE: P-256 1576 X509v3 extensions: 1577 X509v3 Subject Key Identifier: 1578 C8:A3:87:72:82:82:E6:EA:90:D0:E1:81:BC:C7:51 1579 :08:78:0F:D7:52 1580 X509v3 Basic Constraints: 1581 CA:FALSE 1582 X509v3 Subject Alternative Name: 1583 othername: 1584 1.3.6.1.4.1.46930.2: 1585 ..highway-test.example.com:9443 1586 Signature Algorithm: ecdsa-with-SHA256 1587 30:65:02:31:00:b2:9a:7a:1a:74:20:8f:e9:e0:5d:fc:af: 1588 d6: 1589 4a:80:1f:66:e3:bf:17:2e:3e:07:87:39:be:65:bd:94:57: 1590 71: 1591 1f:df:e5:fc:4d:ef:96:8a:3a:03:5b:d1:ca:a1:72:55:a3: 1592 02: 1593 30:13:43:08:a4:af:c8:28:19:d2:a0:93:3d:ed:53:fa:09: 1594 7d: 1595 76:9c:b7:0b:95:2b:8f:2f:b4:fa:87:02:ec:b4:2d:19:92: 1596 5b: 1597 b2:bb:79:04:63:6e:17:0e:79:8a:65:f5:a3 1599 C.1.2. Device private key 1601 -----BEGIN EC PRIVATE KEY----- 1602 MHcCAQEEIA1sa0l4bkj/rJxPUN1bKSBNYolVVzx+T28wo60cYpuaoAoGCCqGSM49 1603 AwEHoUQDQgAEgsQoW3zwNxjHkBTcy/RNfrAA7cDevU0lVU41+dVqVxS0lK/ObVPI 1604 YMLOUz8sG0LxwItfwXs98ylUh0aGpAyLtw== 1605 -----END EC PRIVATE KEY----- 1607 C.1.3. Registrar Certificate 1609 -----BEGIN CERTIFICATE----- 1610 MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxMRIwEAYKCZImiZPyLGQBGRYC 1611 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xQDA+BgNVBAMMNyM8U3lzdGVt 1612 VmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4gVW5zdHJ1bmcgRm91bnRhaW4gQ0Ew 1613 HhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQB 1614 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2Fs 1615 aG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lI 1616 noEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqj 1617 DTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQ 1618 XHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKi 1619 IiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ== 1620 -----END CERTIFICATE----- 1622 C.1.4. Registrar private key 1624 -----BEGIN EC PRIVATE KEY----- 1625 MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 1626 AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E 1627 jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== 1628 -----END EC PRIVATE KEY----- 1630 C.1.5. MASA Certificate 1632 -----BEGIN CERTIFICATE----- 1633 MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h 1634 ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE 1635 AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX 1636 DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh 1637 cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l 1638 eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5 1639 4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf 1640 WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA 1641 vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6 1642 AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP 1643 D0jJ 1644 -----END CERTIFICATE----- 1646 C.1.6. MASA private key 1648 -----BEGIN EC PRIVATE KEY----- 1649 MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 1650 AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ 1651 gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== 1652 -----END EC PRIVATE KEY----- 1654 C.2. COSE signed requestvoucher with registrar certificate pinned 1656 This voucher request has been signed by the pledge, using the private 1657 key given above, and has been sent to the JRC over CoAPS. This 1658 example uses the proximity-registrar-cert mechanism to request a 1659 voucher that pins the certificate of the registrar. 1661 This is the CBOR diagnostic format, folded to 60 characters: 1663 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 1664 D1E49970A5130302D44302D45352D46322D30302D303307765F715674477 1665 738565342626C65394D34557036354C770C5901D4308201D030820157A00 1666 30201020204228ECD27300A06082A8648CE3D040302306E31123010060A0 1667 992268993F22C6401191602636131193017060A0992268993F22C6401191 1668 60973616E64656C6D616E313D303B06035504030C34666F756E7461696E2 1669 D746573742E6578616D706C652E636F6D0A20556E737472756E6720466F7 1670 56E7461696E20526F6F74204341301E170D3139303431363138353431315 1671 A170D3139303531373034353431315A305331123010060A0992268993F22 1672 C6401191602636131193017060A0992268993F22C640119160973616E646 1673 56C6D616E3122302006035504030C19666F756E7461696E2D746573742E6 1674 578616D706C652E636F6D3059301306072A8648CE3D020106082A8648CE3 1675 D030107034200049665507234BA9FE5DDE65FF6F0816FE9489E810C12073 1676 B468F97642B63008D020F57C97C947F848CB20E61D6C9888D15B4421FD7F 1677 26AB7E4CE05F8A74CD38B3A300A06082A8648CE3D0403020367003064023 1678 0340F4E6D0F9F702553FA53BE572ACF0EED858275B6AC75994332FB25FB3 1679 A54411E9FA02E6F75FD1AADB7EA9A61F5409E02303E615E75C8F07432A59 1680 0C8D48798BEDA1EB49E5E7D8E0EA118BD17A02D02F0313D144816002F756 1681 B528ABD1B0ADB749D', h'96B82530AC57650346C2BFFB5A6CC16B28F16F 1682 ACFE5A2FD1BCF3D5F5D62733F7F7812D67D43BE1CF9906E356FB0C2BDD36 1683 777FD7DBAE22B8CEB07D51D8F55AD3']) 1685 This is the raw binary, encoded in base64: 1687 0oRBoKBZAhyhGgAPRsKlAWlwcm94aW1pdHkCwRpdHkmXClEwMC1EMC1FNS1G 1688 Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwxZAdQwggHQMIIBV6AD 1689 AgECAgQijs0nMAoGCCqGSM49BAMCMG4xEjAQBgoJkiaJk/IsZAEZFgJjYTEZ 1690 MBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE9MDsGA1UEAww0Zm91bnRhaW4t 1691 dGVzdC5leGFtcGxlLmNvbQogVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe 1692 Fw0xOTA0MTYxODU0MTFaFw0xOTA1MTcwNDU0MTFaMFMxEjAQBgoJkiaJk/Is 1693 ZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZ 1694 Zm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49 1695 AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/ 1696 hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizowCgYIKoZIzj0EAwIDZwAwZAIw 1697 NA9ObQ+fcCVT+lO+VyrPDu2FgnW2rHWZQzL7Jfs6VEEen6Aub3X9Gq236pph 1698 9UCeAjA+YV51yPB0MqWQyNSHmL7aHrSeXn2ODqEYvRegLQLwMT0USBYAL3Vr 1699 Uoq9GwrbdJ1YQJa4JTCsV2UDRsK/+1pswWso8W+s/lov0bzz1fXWJzP394Et 1700 Z9Q74c+ZBuNW+wwr3TZ3f9fbriK4zrB9Udj1WtM= 1702 C.3. COSE signed parboiled requestvoucher 1704 This voucher request has been signed by the JRC using the private key 1705 from Appendix C.1.4. Contained within this voucher request is the 1706 pledge voucher request above. 1708 This is the CBOR diagnostic format, folded to 60 characters: 1710 18([h'A0', {}, h'A11A000F46C2A5016970726F78696D69747902C11A5 1711 9DD3BFD0A5130302D44302D45352D46322D30302D303307765F715674477 1712 738565342626C65394D34557036354C770B590266D28441A0A059021CA11 1713 A000F46C2A5016970726F78696D69747902C11A5D1E49970A5130302D443 1714 02D45352D46322D30302D303307765F715674477738565342626C65394D3 1715 4557036354C770C5901D4308201D030820157A0030201020204228ECD273 1716 00A06082A8648CE3D040302306E31123010060A0992268993F22C6401191 1717 602636131193017060A0992268993F22C640119160973616E64656C6D616 1718 E313D303B06035504030C34666F756E7461696E2D746573742E6578616D7 1719 06C652E636F6D0A20556E737472756E6720466F756E7461696E20526F6F7 1720 4204341301E170D3139303431363138353431315A170D313930353137303 1721 4353431315A305331123010060A0992268993F22C6401191602636131193 1722 017060A0992268993F22C640119160973616E64656C6D616E31223020060 1723 35504030C19666F756E7461696E2D746573742E6578616D706C652E636F6 1724 D3059301306072A8648CE3D020106082A8648CE3D0301070342000496655 1725 07234BA9FE5DDE65FF6F0816FE9489E810C12073B468F97642B63008D020 1726 F57C97C947F848CB20E61D6C9888D15B4421FD7F26AB7E4CE05F8A74CD38 1727 B3A300A06082A8648CE3D04030203670030640230340F4E6D0F9F702553F 1728 A53BE572ACF0EED858275B6AC75994332FB25FB3A54411E9FA02E6F75FD1 1729 AADB7EA9A61F5409E02303E615E75C8F07432A590C8D48798BEDA1EB49E5 1730 E7D8E0EA118BD17A02D02F0313D144816002F756B528ABD1B0ADB749D584 1731 096B82530AC57650346C2BFFB5A6CC16B28F16FACFE5A2FD1BCF3D5F5D62 1732 733F7F7812D67D43BE1CF9906E356FB0C2BDD36777FD7DBAE22B8CEB07D5 1733 1D8F55AD3', h'EAE868ECC176883766C5DC5BA5B8DCA25DAB3C2E56A551 1734 CE5705B793914348E1F93C2B81E88CCBE28E90800F66945EFBBECE4F741D 1735 0EDE18EB1008EF7E9A279C']) 1737 This is the raw binary, encoded in base64: 1739 0oRBoKBZAq6hGgAPRsKlAWlwcm94aW1pdHkCwRpZ3Tv9ClEwMC1EMC1FNS1G 1740 Mi0wMC0wMwd2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwtZAmbShEGgoFkCHKEa 1741 AA9GwqUBaXByb3hpbWl0eQLBGl0eSZcKUTAwLUQwLUU1LUYyLTAwLTAzB3Zf 1742 cVZ0R3c4VlNCYmxlOU00VXA2NUx3DFkB1DCCAdAwggFXoAMCAQICBCKOzScw 1743 CgYIKoZIzj0EAwIwbjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPy 1744 LGQBGRYJc2FuZGVsbWFuMT0wOwYDVQQDDDRmb3VudGFpbi10ZXN0LmV4YW1w 1745 bGUuY29tCiBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTE5MDQxNjE4 1746 NTQxMVoXDTE5MDUxNzA0NTQxMVowUzESMBAGCgmSJomT8ixkARkWAmNhMRkw 1747 FwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYDVQQDDBlmb3VudGFpbi10 1748 ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAElmVQ 1749 cjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0V 1750 tEIf1/Jqt+TOBfinTNOLOjAKBggqhkjOPQQDAgNnADBkAjA0D05tD59wJVP6 1751 U75XKs8O7YWCdbasdZlDMvsl+zpUQR6foC5vdf0arbfqmmH1QJ4CMD5hXnXI 1752 8HQypZDI1IeYvtoetJ5efY4OoRi9F6AtAvAxPRRIFgAvdWtSir0bCtt0nVhA 1753 lrglMKxXZQNGwr/7WmzBayjxb6z+Wi/RvPPV9dYnM/f3gS1n1Dvhz5kG41b7 1754 DCvdNnd/19uuIrjOsH1R2PVa01hA6uho7MF2iDdmxdxbpbjcol2rPC5WpVHO 1755 VwW3k5FDSOH5PCuB6IzL4o6QgA9mlF77vs5PdB0O3hjrEAjvfponnA== 1757 C.4. COSE signed voucher 1759 The resulting voucher is created by the MASA and returned via the JRC 1760 to the Pledge. It is signed by the MASA's private key Appendix C.1.6 1761 and can be verified by the pledge using the MASA's publie key. 1763 This is the CBOR diagnostic format, folded to 60 characters: 1765 18([h'A0', {}, h'A11A000F468CA505666C6F6767656406C11A5D1E499 1766 A0E7130302D44302D45352D46322D30302D30330B765F715674477738565 1767 342626C65394D34557036354C770C7902744D49494230544343415661674 1768 177494241674942416A414B42676771686B6A4F50515144417A42784D524 1769 9774541594B435A496D695A50794C4751424752594359324578475441584 1770 2676F4A6B69614A6B2F49735A41455A46676C7A5957356B5A57787459573 1771 4785144412B42674E5642414D4D4E794D3855336C7A64475674566D46796 1772 1574669624755364D4867774D4441774D4441774E4759354D5446684D443 1773 4675657357A64484A31626D6367526D3931626E526861573467513045774 1774 868634E4D5463784D5441334D6A4D304E5449345768634E4D546B784D544 1775 1334D6A4D304E544934576A42444D5249774541594B435A496D695A50794 1776 C47514247525943593245784754415842676F4A6B69614A6B2F49735A414 1777 55A46676C7A5957356B5A57787459573478456A415142674E5642414D4D4 1778 3577876593246736147397A6444425A4D424D4742797147534D343941674 1779 54743437147534D34394177454841304941424A5A6C5548493075702F6C3 1780 3655A6639764342622B6C496E6F454D45676337526F2B585A43746A41493 1781 0434431664A664A522F68497979446D48577959694E46625243483966796 1782 172666B7A67583470307A54697A716A4454414C4D416B474131556445775 1783 1434D414177436759494B6F5A497A6A304541774D44615141775A6749784 1784 14C514D4E75726638747635306C524F443544515848454F4A4A4E5733515 1785 632673951456444536B324D592B416F537242536D47534E6A68346F6C454 1786 F6845754C674978414A346E57664E772B426A625A6D4B694969554563547 1787 7484D68475658614D48592F46376E333977774B634242534F6E644E50714 1788 3704F454C6C36627133435A71513D3D', h'7468FB16A4035FDAF510DBF5 1789 A88F67B6FB849CFBA8B094B77AD5248900E4BCD6E892FE74B39AB787637B 1790 121944BED4D1CB4B8DC8F59212EAC2AD20469C71C1F6']) 1792 This is the raw binary, encoded in base64: 1794 0oRBoKBZArmhGgAPRoylBWZsb2dnZWQGwRpdHkmaDnEwMC1EMC1FNS1GMi0w 1795 MC0wMwt2X3FWdEd3OFZTQmJsZTlNNFVwNjVMdwx5AnRNSUlCMFRDQ0FWYWdB 1796 d0lCQWdJQkFqQUtCZ2dxaGtqT1BRUURBekJ4TVJJd0VBWUtDWkltaVpQeUxH 1797 UUJHUllDWTJFeEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0 1798 eFFEQStCZ05WQkFNTU55TThVM2x6ZEdWdFZtRnlhV0ZpYkdVNk1IZ3dNREF3 1799 TURBd05HWTVNVEZoTUQ0Z1ZXNXpkSEoxYm1jZ1JtOTFiblJoYVc0Z1EwRXdI 1800 aGNOTVRjeE1UQTNNak0wTlRJNFdoY05NVGt4TVRBM01qTTBOVEk0V2pCRE1S 1801 SXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFF 1802 WkZnbHpZVzVrWld4dFlXNHhFakFRQmdOVkJBTU1DV3h2WTJGc2FHOXpkREJa 1803 TUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wz 1804 ZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt 1805 SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dBMVVkRXdR 1806 Q01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUwbFJP 1807 RDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP 1808 aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24z 1809 OXd3S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09WEB0aPsWpANf2vUQ2/Wo 1810 j2e2+4Sc+6iwlLd61SSJAOS81uiS/nSzmreHY3sSGUS+1NHLS43I9ZIS6sKt 1811 IEacccH2 1813 Authors' Addresses 1815 Michael Richardson 1816 Sandelman Software Works 1818 Email: mcr+ietf@sandelman.ca 1820 Peter van der Stok 1821 vanderstok consultancy 1823 Email: consultancy@vanderstok.org 1825 Panos Kampanakis 1826 Cisco Systems 1828 Email: pkampana@cisco.com