idnits 2.17.1 draft-ietf-anima-constrained-voucher-12.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 ([BRSKI], [RFC8366]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 797 has weird spacing: '...ndatory false...' == Line 801 has weird spacing: '...ndatory false...' == Line 1046 has weird spacing: '...ndatory false...' == Line 1050 has weird spacing: '...ndatory false...' == Line 1257 has weird spacing: '... brski nee...' -- The document date (11 July 2021) is 1021 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: 'BRSKI' is mentioned on line 22, but not defined == Missing Reference: 'ThisRFC' is mentioned on line 1298, but not defined == Missing Reference: 'This RFC' is mentioned on line 1347, but not defined == Unused Reference: 'ieee802-1AR' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1458, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-16 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-16 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-08 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-03 ** Downref: Normative reference to an Informational draft: draft-selander-ace-ake-authz (ref. 'I-D.selander-ace-ake-authz') -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-08) exists of draft-richardson-anima-masa-considerations-05 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 4 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: 12 January 2022 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 E. Dijk 9 IoTconsultancy.nl 10 11 July 2021 12 Constrained Voucher Artifacts for Bootstrapping Protocols 13 draft-ietf-anima-constrained-voucher-12 15 Abstract 17 This document defines a protocol to securely assign a Pledge to an 18 owner and to enroll it into the owner's network. The protocol uses 19 an artifact that is signed by the Pledge's manufacturer. This 20 artifact is known as a "voucher". 22 This document builds upon the work in [RFC8366] and [BRSKI], but 23 defines an encoding of the voucher in CBOR rather than JSON, and 24 enables the Pledge to perform its transactions using CoAP rather than 25 HTTPS. 27 The use of Raw Public Keys instead of X.509 certificates for security 28 operations is also explained. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 12 January 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 66 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 5 67 5. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Discovery, URIs and Content Formats . . . . . . . . . . . 6 69 5.2. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8 70 5.3. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 9 71 5.3.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 9 72 5.3.2. Registrar Extensions . . . . . . . . . . . . . . . . 10 73 6. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 11 74 7. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 11 75 7.1. Registrar Identity Selection and Encoding . . . . . . . . 12 76 7.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 13 77 7.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 14 78 8. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1. Voucher Request artifact . . . . . . . . . . . . . . . . 15 80 8.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 81 8.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 15 82 8.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 16 83 8.1.4. Example voucher request artifact . . . . . . . . . . 20 84 8.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 20 85 8.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 20 86 8.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 21 87 8.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 21 88 8.2.4. Example voucher artifacts . . . . . . . . . . . . . . 24 89 8.3. Signing voucher and voucher-request artifacts with 90 COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 9. Design Considerations . . . . . . . . . . . . . . . . . . . . 26 92 10. Raw Public Key Use Considerations . . . . . . . . . . . . . . 26 93 10.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 26 94 10.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 27 95 10.3. The Voucher Response . . . . . . . . . . . . . . . . . . 27 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 97 11.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 27 98 11.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 28 99 11.3. Test Domain Certificate Validity when Signing . . . . . 28 100 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 12.1. Resource Type Registry . . . . . . . . . . . . . . . . . 28 102 12.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 28 103 12.3. The YANG Module Names Registry . . . . . . . . . . . . . 28 104 12.4. The RFC SID range assignment sub-registry . . . . . . . 29 105 12.5. Media Types Registry . . . . . . . . . . . . . . . . . . 29 106 12.5.1. application/voucher-cose+cbor . . . . . . . . . . . 29 107 12.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 30 108 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 109 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 15.1. Normative References . . . . . . . . . . . . . . . . . . 31 112 15.2. Informative References . . . . . . . . . . . . . . . . . 33 113 Appendix A. Library support for BRSKI . . . . . . . . . . . . . 34 114 A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 35 115 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 36 116 A.3. wolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . 37 117 Appendix B. Constrained BRSKI-EST messages . . . . . . . . . . . 37 118 B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 37 119 B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 38 120 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 38 121 C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 42 122 C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 42 123 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 42 124 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 43 125 C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 43 126 C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 43 127 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 45 128 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 47 129 C.3. COSE signed voucher request from Pledge to Registrar . . 49 130 C.4. COSE signed voucher request from Registrar to MASA . . . 51 131 C.5. COSE signed voucher from MASA to Pledge via Registrar . . 53 132 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 135 1. Introduction 137 Secure enrollment of new nodes into constrained networks with 138 constrained nodes presents unique challenges. There are network 139 bandwidth and code size issues to contend with. A solution for 140 autonomous enrollment such as BRSKI [RFC8995] may be too large in 141 terms of code size or bandwidth required. 143 Therefore, this document defines a constrained version of the voucher 144 artifact [RFC8366], along with a constrained version of BRSKI 145 [RFC8995] that makes use of the constrained CoAP-based version of 146 EST, EST-coaps [I-D.ietf-ace-coap-est] rather than EST over HTTPS 147 [RFC7030]. 149 While the [RFC8366] voucher is by default serialized to JSON with a 150 signature in CMS, this document defines a new voucher serialization 151 to CBOR ([RFC7049]) with a signature in COSE 152 [I-D.ietf-cose-rfc8152bis-struct]. This COSE-signed CBOR-encoded 153 voucher can be transported using secured CoAP or HTTP. The CoAP 154 connection (between Pledge and Registrar) is to be protected by 155 either OSCORE+EDHOC or DTLS (CoAPS). The HTTP connection (between 156 Registrar and MASA) is to be protected using TLS (HTTPS). 158 This document specifies a constrained voucher-request artifact based 159 on Section 3 of [RFC8995], and voucher(-request) transport over CoAP 160 based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est]. 162 The CBOR definitions for the constrained voucher format are defined 163 using the mechanism described in [I-D.ietf-core-yang-cbor] using the 164 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 165 convert YANG documents into a list of SID keys is still in its 166 infancy, the table of SID values presented here MUST be considered 167 normative rather than the output of the pyang tool. 169 There is additional work when the voucher is integrated into the key- 170 exchange, described in [I-D.selander-ace-ake-authz]. This work is 171 not in scope for this document. 173 2. Terminology 175 The following terms are defined in [RFC8366], and are used 176 identically as in that document: artifact, domain, imprint, Join 177 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 178 Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and 179 Voucher. 181 The following terms from [RFC8995] are used identically as in that 182 document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, 183 manufacturer, nonced, nonceless, PKIX. 185 3. Requirements Language 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in 190 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 4. Overview of Protocol 195 [RFC8366] provides for vouchers that assert proximity, that 196 authenticate the Registrar and that can offer varying levels of anti- 197 replay protection. 199 This document does not make any extensions to the semantic meaning of 200 vouchers, only the encoding has been changed to optimize for 201 constrained devices and networks. The two main parts of the BRSKI 202 protocol are named separately in this document: BRSKI-EST for the 203 protocol between Pledge and Registrar, and BRSKI-MASA for the 204 protocol between the Registrar and the MASA. 206 Time-based vouchers are supported in this definition, but given that 207 constrained devices are extremely unlikely to have accurate time, 208 their use will be uncommon. Most Pledges using these constrained 209 vouchers will be online during enrollment and will use live nonces to 210 provide anti-replay protection rather than expiry times. 212 [RFC8366] defines the voucher artifact, while the Voucher Request 213 artifact was defined in [RFC8995]. This document defines both a 214 constrained voucher and a constrained voucher-request. They are 215 presented in the order "voucher-request", followed by a "voucher" 216 response as this is the order that they occur in the protocol. 218 The constrained voucher request MUST be signed by the Pledge. It 219 signs using the private key associated with its IDevID X.509 220 certificate, or if an IDevID is not available, then the private key 221 associated with its manufacturer-installed raw public key (RPK). 222 Section 10 provides additional details on PKIX-less operations. 224 The constrained voucher MUST be signed by the MASA. 226 For the constrained voucher request this document defines two 227 distinct methods for the Pledge to identify the Registrar: using 228 either the Registrar's X.509 certificate, or using a raw public key 229 (RPK) of the Registrar. 231 For the constrained voucher also these two methods are supported to 232 indicate (pin) a trusted domain identity: using either a pinned 233 domain X.509 certificate, or a pinned raw public key (RPK). 235 The BRSKI architectures mandates that the MASA be aware of the 236 capabilities of the pledge. This is not a hardship as the pledges 237 are constructed by a manufacturer who also arranges for the MASA to 238 be aware of the inventory of devices. 240 The MASA therefore knows if the pledge supports PKIX operations, PKIX 241 format certificates, or if the pledge is limited to Raw Public Keys 242 (RPK). Based upon this, the MASA can select which attributes to use 243 in the voucher for certain operations, like the pinning of the 244 Registrar identity. This is described in more detail in 245 Section 8.2.3, Section 7 and Section 7.3 (for RPK specifically). 247 5. BRSKI-EST Protocol 249 This section describes the constrained BRSKI extensions to EST-coaps 250 [I-D.ietf-ace-coap-est] to transport the voucher between Registrar 251 and Pledge (optionally via a Join Proxy) over CoAP. The extensions 252 are targeting low-resource networks with small packets. 254 The constrained BRSKI-EST protocol described in this section is 255 between the Pledge and the Registrar only. 257 5.1. Discovery, URIs and Content Formats 259 To keep the protocol messages small the EST-coaps and constrained- 260 BRSKI URIs are shorter than the respective EST and BRSKI URIs. 262 The EST-coaps server URIs differ from the EST URIs by replacing the 263 scheme https by coaps and by specifying shorter resource path names. 264 Below are some examples; the first two using a discovered short path 265 name and the last one using the well-known URI of EST which requires 266 no discovery. 268 coaps://server.example.com/est/ 269 coaps://server.example.com/e/ 270 coaps://server.example.com/.well-known/est/ 272 Similarly the constrained BRSKI server URIs differ from the BRSKI 273 URIs by replacing the scheme https by coaps and by specifying shorter 274 resource path names. Below are some examples; the first two using a 275 discovered short path name and the last one using the well-known URI 276 prefix which requires no discovery. This is the same "/.well-known/ 277 brski" prefix as defined in [RFC8995] Section 5. 279 coaps://server.example.com/brski/ 280 coaps://server.example.com/b/ 281 coaps://server.example.com/.well-known/brski/ 283 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations 284 supported by EST, for which Table 1 in Section 5.1 of 285 [I-D.ietf-ace-coap-est] enumerates the corresponding EST-coaps short 286 path names. Similarly, Table 1 provides the mapping from the 287 supported BRSKI extension URI paths to the constrained-BRSKI URI 288 paths. 290 +=================+============================+ 291 | BRSKI resource | constrained-BRSKI resource | 292 +=================+============================+ 293 | /requestvoucher | /rv | 294 +-----------------+----------------------------+ 295 | /voucher_status | /vs | 296 +-----------------+----------------------------+ 297 | /enrollstatus | /es | 298 +-----------------+----------------------------+ 300 Table 1: BRSKI URI paths mapping to 301 constrained BRSKI URI paths 303 Note that /requestvoucher indicated above occurs between the Pledge 304 and Registrar (in scope of the BRSKI-EST protocol), but it also 305 occurs between Registrar and MASA. However, as described in 306 Section 5, this section and above table addresses only the BRSKI-EST 307 protocol. 309 Pledges that wish to discover the available BRSKI bootstrap options/ 310 formats, or reduce the size of the CoAP headers by eliminating the 311 "/.well-known/brski" path, can do a discovery operation using 312 [RFC6690] Section 4 by sending a discovery query to the Registrar. 314 For example, if the Registrar supports a short BRSKI URL (/b) and 315 supports the voucher format "application/voucher-cose+cbor" (TBD3), 316 and status reporting in both CBOR and JSON formats: 318 REQ: GET /.well-known/core?rt=brski* 320 RES: 2.05 Content 321 Content-Format: 40 322 Payload: 323 ;rt=brski, 324 ;rt=brski.rv;ct=TBD3, 325 ;rt=brski.vs;ct="50 60", 326 ;rt=brski.es;ct="50 60" 328 The Registrar is under no obligation to provide shorter URLs, and MAY 329 respond to this query with only the "/.well-known/brski/" 330 end points for the short names as defined in Table 1. 332 Registrars that have implemented shorter URLs MUST also respond in 333 equivalent ways to the corresponding "/.well-known/brski/" URLs, and MUST NOT distinguish between them. In particular, a 335 Pledge MAY use the longer and shorter URLs in combination. 337 When responding to a discovery request for BRSKI resources, the 338 server MAY in addition return the full resource paths and the content 339 types which are supported at those end-points as shown in above 340 example. This is useful when multiple content types are specified 341 for a particular resource on the server. The server responds with 342 only the root path for the BRSKI resource (rt=brski, resource /b in 343 above example) and no others in case the client queries for only 344 rt=brski type resources. (So, a query for rt=brski, without the 345 wildcard character.) 347 The return of multiple content-types in the "ct" attribute allows the 348 Pledge to choose the most appropriate one. Note that Content-Format 349 TBD3 ("application/voucher-cose+cbor") is defined in this document. 351 The Content-Format 50 ("application/json") MAY be supported and 352 Content-Format 60 ("application/cbor") MUST be supported by the 353 Registrar for the /vs and /es resources. Content-Format TBD3 MUST be 354 supported by the Registrar for the /rv resource. If the "ct" 355 attribute is not indicated for the /rv resource in the link format 356 description, this implies that at least TBD3 is supported. 358 The Pledge and MASA need to support one or more formats (at least 359 TBD3) for the voucher and for the voucher request. The MASA needs to 360 support all formats that the Pledge, produced by that manufacturer, 361 supports. 363 5.2. Extensions to BRSKI 365 A Pledge that only supports the BRSKI bootstrap method and already 366 knows the IP address and port of a Registrar or Join Proxy to use 367 SHOULD NOT use discovery. In such case it is more efficient to just 368 try its supported bootstrap method (e.g. /rv) via the well-known 369 BRSKI resource on the known address and port. This avoids the Pledge 370 having to unnecessarily implement CoRE Link Format parsing. The 371 method via which the Pledge learns the address/port of a Registrar or 372 Join Proxy to use is out of scope of this document. 374 A Registrar SHOULD host any discoverable BRSKI resources on the same 375 (UDP) server port that the Pledge's initial DTLS connection is using. 376 This avoids the overhead of the Pledge having to reconnect using 377 DTLS, in order to access discovered resource(s). 379 5.3. Extensions to EST-coaps 381 A Pledge that already is DTLS-connected to either a Join Proxy or 382 Registrar, and which only supports the EST-coaps enrollment method, 383 SHOULD NOT use discovery for EST-coaps resources. This is because it 384 is more efficient to just try its supported enrollment method (e.g. 385 /sen) via the well-known EST resource on the current DTLS connection. 386 This avoids an additional round-trip of packets and avoids the Pledge 387 having to unnecessarily implement CoRE Link Format parsing. 389 A Registrar SHOULD host any discoverable EST-coaps resources on the 390 same (UDP) server port that the Pledge's DTLS initial connection is 391 using. This avoids the Pledge having to reconnect using DTLS, in 392 order to proceed with EST enrollment after the BRSKI bootstrap. [TBD 393 EDNOTE: a Registrar that does host EST resources on another port 394 won't be able to onboard Pledges that skip the discovery, so not 395 interoperable. Should we fix this?] 397 5.3.1. Pledge Extensions 399 A constrained Pledge SHOULD NOT support the optional EST "CSR 400 attributes request" (/att) to minimize network traffic and reduce 401 code size. 403 When creating the CSR, the Pledge selects which attributes to 404 include. One or more Subject Distinguished Name fields MUST be 405 included. If the Pledge has no specific information on what 406 attributes/fields are desired in the CSR, it MUST use the Subject 407 Distinguished Name fields from its IDevID unmodified. The Pledge can 408 receive such information via the voucher (encoded in a vendor- 409 specific way) or some other, out-of-band means. 411 A constrained Pledge MAY use the following optimized EST-coaps 412 procedure to minimize both network traffic and code size: 414 1. if the voucher, that validates the current Registrar, contains a 415 single pinned domain CA certificate, the Pledge provisionally 416 considers this certificate as the EST trust anchor, in other 417 words, it provisionally accepts this CA certificate as if it were 418 the result of "CA certificates request" (/crts) to the Registrar. 420 2. Using this CA certificate as trust anchor it proceeds with EST 421 simple enrollment (/sen) to obtain its provisionally trusted 422 LDevID. 424 3. If the Pledge validates that the trust anchor CA was used to sign 425 its LDevID, the Pledge accepts the pinned domain CA certificate 426 as the legitimate trust anchor CA for the Registrar's domain and 427 accepts the associated LDevID. 429 4. If the trust anchor CA was NOT used to sign its LDevID, the 430 Pledge MUST perform an actual "CA certificates request" (/crts) 431 to the EST server to obtain the EST CA trust anchor(s) since 432 these differ from the (temporary) pinned domain CA. 434 5. When doing this /crts request, the Pledge MAY use a CoAP Accept 435 Option with value TBD287 ("application/pkix-cert") to limit the 436 number of returned EST CA trust anchors to only one. 438 6. If the Pledge cannot obtain the single CA certificate or the 439 finally validated CA certificate cannot be chained to the LDevID, 440 then the Pledge MUST abort the enrollment process and report the 441 error using the enrollment status telemetry (/es). 443 5.3.2. Registrar Extensions 445 The Content-Format 50 MAY be supported and 60 MUST be supported by 446 the Registrar for the /vs and /es resources. Content-Format TBD3 447 MUST be supported by the Registrar for the /rv resource. 449 When a Registrar receives a "CA certificates request" (/crts) request 450 with a CoAP Accept Option with value TBD287 ("application/pkix-cert") 451 it SHOULD return only the single CA certificate that is the 452 envisioned or actual authority for the current, authenticated Pledge 453 making the request. The only exception case is when the Registrar is 454 configured to not support a request for a single CA certificate for 455 operational or security reasons, e.g. because every device enrolled 456 into the domain needs to use multiple CAs. In such exception case 457 the Registrar returns the CoAP response 4.06 Not Acceptable to 458 indicate that only the default Content-Format of 281 "application/ 459 pkcs7-mime;smime-type=certs-only" which supports multiple 460 certificates is available. 462 6. BRSKI-MASA Protocol 464 [RFC8995] section 5.4 describes a connection between the Registrar 465 and the MASA as being a normal TLS connection using HTTPS. This 466 document does not change that. The Registrar MAY use the new format 467 "application/voucher-cose+cbor" in its voucher request to MASA, or 468 the existing BRSKI format "application/voucher-cms+json" defined by 469 [RFC8995]. The MASA MUST support both formats. The Registrar 470 indicates the voucher format it wants to receive from MASA using the 471 HTTP Accept header. 473 At the moment of writing the creation of coaps based MASAs is deemed 474 unrealistic. The use of CoAP for the BRSKI-MASA connection can be 475 the subject of another document. Some consideration was made to 476 specify CoAP support for consistency, but: 478 * the Registrar is not expected to be so constrained that it cannot 479 support HTTPS client connections. 481 * the technology and experience to build Internet-scale HTTPS 482 responders (which the MASA is) is common, while the experience 483 doing the same for CoAP is much less common. 485 * in many Enterprise networks, outgoing UDP connections are often 486 treated as suspicious, and there seems to be no advantage to using 487 CoAP in that environment. 489 * a Registrar is likely to provide onboarding services to both 490 constrained and non-constrained devices. Such a Registrar would 491 need to speak HTTPS anyway. 493 * similarly, a manufacturer is likely to offer both constrained and 494 non-constrained devices, so there may in practice be no situation 495 in which the MASA could be CoAP-only. Additionally, as the MASA 496 is intended to be a function that can easily be oursourced to a 497 third-party service provider, reducing the complexity would also 498 seem to reduce the cost of that function. 500 7. Pinning in Voucher Artifacts 502 The voucher is a statement by the MASA for use by the Pledge that 503 provide the identity of the Pledge's owner. This section describes 504 how the owner's identity is determined and how it is encoded within 505 the voucher. 507 7.1. Registrar Identity Selection and Encoding 509 Section 5.5 of [RFC8995] describes BRSKI policies for selection of 510 the owner identity. It indicates some of the flexibility that is 511 possible for the Registrar. The recommendation made there is for the 512 Registrar to include only certificates in the voucher request (CMS) 513 signing structure which participate in the certificate chain that is 514 to be pinned. 516 The MASA is expected to evaluate the certificates included by the 517 Registrar in its voucher request, forming them into a chain with the 518 Registrar's (signing) identity on one end. Then, it pins a 519 certificate selected from the chain. For instance, for a domain with 520 a two-level certification authority (see Figure 1), where the 521 voucher-request has been signed by "Registrar", its signing structure 522 includes two additional CA certificates: 524 .------------------. 525 | domain CA (1) | 526 | trust anchor | 527 '------------------' 528 | 529 v 530 .------------. 531 | domain (2) | 532 | Sub-CA | 533 '------------' 534 | 535 | 536 v 537 .----------------. 538 | domain | 539 | Registrar (3) | 540 | EE certificate | 541 '----------------' 543 Figure 1: Two-Level CA PKI 545 When the Registrar is using a COSE-signed constrained voucher request 546 towards MASA, instead of a regular CMS-signed voucher request, the 547 COSE_Sign1 object contains a protected and an unprotected header. 548 The Registrar MUST place all the certificates for the chain in an 549 "x5bag" attribute in the unprotected header [I-D.ietf-cose-x509]. 551 7.2. MASA Pinning Policy 553 The MASA, having assembled and verified the chain in the signing 554 structure of the voucher request, will now need to select a 555 certificate to pin. (For the case that only the Registrar's End- 556 Entity certificate is included, only this certificate can be selected 557 and this section does not apply.) The BRSKI policy for pinning by 558 the MASA as described in Section 5.5.2 of [RFC8995] leaves much 559 flexibility to the manufacturer. The present document adds the 560 following rules to the MASA pinning policy to reduce the network 561 load: 563 1. for a voucher containing a nonce, it SHOULD select the most 564 specific (lowest-level) CA certificate in the chain. 566 2. for a nonceless voucher, it SHOULD select the least-specific 567 (highest-level) CA certificate in the chain that is allowed under 568 the MASA's policy for this specific domain. 570 The rationale for 1. is that in case of a voucher with nonce, the 571 voucher is valid only in scope of the present DTLS connection between 572 Pledge and Registrar anyway, so it would have no benefit to pin a 573 higher-level CA. By pinning the most specific CA the constrained 574 Pledge can validate its DTLS connection using less crypto operations. 575 The rationale for pinning a CA instead of the Registrar's End-Entity 576 certificate directly is the following benefit on constrained 577 networks: the pinned certificate in the voucher can in common cases 578 be re-used as a Domain CA trust anchor during the EST enrollment and 579 during the operational phase that follows after EST enrollment, as 580 explained in Section 5.3.1. 582 The rationale for 2. follows from the flexible BRSKI trust model for, 583 and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of 584 [RFC8995]). 586 Using the previous example of a domain with a two-level certification 587 authority, the most specific CA ("Sub-CA") is the identity that is 588 pinned by MASA in a nonced voucher. A Registrar that wished to have 589 only the Registrar's End-Entity certificate pinned would omit the 590 "domain CA" and "Sub-CA" certificates from the voucher-request. 592 In case of a nonceless voucher, the MASA would depending on trust 593 level pin only "Registrar" certificate (low trust in customer), or 594 the "Sub-CA" certificate (in case of medium trust, implying that any 595 Registrar of that sub-domain is acceptable), or even the "domain CA" 596 certificate (in case of high trust in the customer, and possibly a 597 pre-agreed need of the customer to obtain flexible long-lived 598 vouchers). 600 7.3. Pinning of Raw Public Keys 602 Specifically for constrained use cases, the pinning of the raw public 603 key (RPK) of the Registrar is also supported in the constrained 604 voucher, instead of an X.509 certificate. If an RPK is pinned it 605 MUST be the RPK of the Registrar. 607 When the Pledge is known by MASA to support RPK but not X.509 608 certificates, the voucher produced by the MASA pins the RPK of the 609 Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk- 610 sha256" field of a voucher. This is described in more detail in 611 Section 8.2.3. A Pledge that does not support X.509 certificates 612 cannot use EST to enroll; it has to use another method for enrollment 613 without certificates and the Registrar has to support this method 614 also. It is possible that the Pledge will not enroll, but instead 615 only a network join operation will occur, such as described in 616 [I-D.ietf-6tisch-minimal-security]. How the Pledge discovers this 617 method and details of the enrollment method are out of scope of this 618 document. 620 When the Pledge is known by MASA to support PKIX format certificates, 621 the "pinned-domain-cert" field present in a voucher typically pins a 622 domain certificate. That can be either the End-Entity certificate of 623 the Registrar, or the certificate of a domain CA of the Registrar's 624 domain as specified in Section 7.2. However, if the Pledge is known 625 to also support RPK pinning and the MASA intends to pin the 626 Registrar's identity (not a CA), then MASA SHOULD pin the RPK (RPK3 627 in Figure 2) of the Registrar instead of the Registrar's End-Entity 628 certificate to save space in the voucher. 630 .------------. 631 | pub-CA (1) | 632 '------------' 633 | 634 v 635 .------------. 636 | sub-CA (2) | 637 '------------' 638 | 639 v 640 .--------------. 641 | Registrar(3) | 642 | RPK3 | 643 '--------------' 645 Figure 2: Raw Public Key pinning 647 8. Artifacts 649 This section describes for both the voucher request and the voucher 650 first the abstract (tree) definition as explained in 651 [I-D.ietf-netmod-yang-tree-diagrams]. This provides a high-level 652 view of the contents of each artifact. 654 Then the assigned SID values are presented. These have been assigned 655 using the rules in [I-D.ietf-core-sid], with an allocation that was 656 made via the http://comi.space service. 658 8.1. Voucher Request artifact 660 8.1.1. Tree Diagram 662 The following diagram is largely a duplicate of the contents of 663 [RFC8366], with the addition of the fields proximity-registrar-pubk, 664 proximity-registrar-pubk-sha256, proximity-registrar-cert, and prior- 665 signed-voucher-request. 667 prior-signed-voucher-request is only used between the Registrar and 668 the MASA. proximity-registrar-pubk or proximity-registrar-pubk-sha256 669 optionally replaces proximity-registrar-cert for the most constrained 670 cases where RPK is used by the Pledge. 672 module: ietf-constrained-voucher-request 674 grouping voucher-request-constrained-grouping 675 +-- voucher 676 +-- created-on? yang:date-and-time 677 +-- expires-on? yang:date-and-time 678 +-- assertion enumeration 679 +-- serial-number string 680 +-- idevid-issuer? binary 681 +-- pinned-domain-cert? binary 682 +-- domain-cert-revocation-checks? boolean 683 +-- nonce? binary 684 +-- last-renewal-date? yang:date-and-time 685 +-- proximity-registrar-pubk? binary 686 +-- proximity-registrar-pubk-sha256? binary 687 +-- proximity-registrar-cert? binary 688 +-- prior-signed-voucher-request? binary 690 8.1.2. SID values 691 SID Assigned to 692 --------- -------------------------------------------------- 693 2501 data /ietf-constrained-voucher-request:voucher 694 2502 data .../assertion 695 2503 data .../created-on 696 2504 data .../domain-cert-revocation-checks 697 2505 data .../expires-on 698 2506 data .../idevid-issuer 699 2507 data .../last-renewal-date 700 2508 data /ietf-constrained-voucher-request:voucher/nonce 701 2509 data .../pinned-domain-cert 702 2510 data .../prior-signed-voucher-request 703 2511 data .../proximity-registrar-cert 704 2513 data .../proximity-registrar-pubk 705 2512 data .../proximity-registrar-pubk-sha256 706 2514 data .../serial-number 708 WARNING, obsolete definitions 710 8.1.3. YANG Module 712 In the constrained-voucher-request YANG module, the voucher is 713 "augmented" within the "used" grouping statement such that one 714 continuous set of SID values is generated for the constrained- 715 voucher-request module name, all voucher attributes, and the 716 constrained-voucher-request attributes. Two attributes of the 717 voucher are "refined" to be optional. 719 file "ietf-constrained-voucher-request@2021-04-15.yang" 720 module ietf-constrained-voucher-request { 721 yang-version 1.1; 723 namespace 724 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 725 prefix "constrained"; 727 import ietf-restconf { 728 prefix rc; 729 description 730 "This import statement is only present to access 731 the yang-data extension defined in RFC 8040."; 732 reference "RFC 8040: RESTCONF Protocol"; 733 } 735 import ietf-voucher { 736 prefix "v"; 737 } 738 organization 739 "IETF ANIMA Working Group"; 741 contact 742 "WG Web: 743 WG List: 744 Author: Michael Richardson 745 746 Author: Peter van der Stok 747 748 Author: Panos Kampanakis 749 "; 751 description 752 "This module defines the format for a voucher request, 753 which is produced by a pledge to request a voucher. 754 The voucher-request is sent to the potential owner's 755 Registrar, which in turn sends the voucher request to 756 the manufacturer or its delegate (MASA). 758 A voucher is then returned to the pledge, binding the 759 pledge to the owner. This is a constrained version of the 760 voucher-request present in 761 {{I-D.ietf-anima-bootstrap-keyinfra}} 763 This version provides a very restricted subset appropriate 764 for very constrained devices. 765 In particular, it assumes that nonce-ful operation is 766 always required, that expiration dates are rather weak, as no 767 clocks can be assumed, and that the Registrar is identified 768 by either a pinned Raw Public Key of the Registrar, or by a 769 pinned X.509 certificate of the Registrar or domain CA. 771 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 772 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 773 and 'OPTIONAL' in the module text are to be interpreted as 774 described in RFC 2119."; 776 revision "2021-04-15" { 777 description 778 "Initial version"; 779 reference 780 "RFC XXXX: Voucher Profile for Constrained Devices"; 781 } 783 rc:yang-data voucher-request-constrained-artifact { 784 // YANG data template for a voucher. 785 uses voucher-request-constrained-grouping; 787 } 789 // Grouping defined for future usage 790 grouping voucher-request-constrained-grouping { 791 description 792 "Grouping to allow reuse/extensions in future work."; 794 uses v:voucher-artifact-grouping { 796 refine voucher/created-on { 797 mandatory false; 798 } 800 refine voucher/pinned-domain-cert { 801 mandatory false; 802 } 804 augment "voucher" { 805 description "Base the constrained voucher-request upon the 806 regular one"; 808 leaf proximity-registrar-pubk { 809 type binary; 810 description 811 "The proximity-registrar-pubk replaces 812 the proximity-registrar-cert in constrained uses of 813 the voucher-request. 814 The proximity-registrar-pubk is the 815 Raw Public Key of the Registrar. This field is encoded 816 as specified in RFC7250, section 3. 817 The ECDSA algorithm MUST be supported. 818 The EdDSA algorithm as specified in 819 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 820 Support for the DSA algorithm is not recommended. 821 Support for the RSA algorithm is a MAY, but due to 822 size is discouraged."; 823 } 825 leaf proximity-registrar-pubk-sha256 { 826 type binary; 827 description 828 "The proximity-registrar-pubk-sha256 829 is an alternative to both 830 proximity-registrar-pubk and pinned-domain-cert. 831 In many cases the public key of the domain has already 832 been transmitted during the key agreement protocol, 833 and it is wasteful to transmit the public key another 834 two times. 835 The use of a hash of public key info, at 32-bytes for 836 sha256 is a significant savings compared to an RSA 837 public key, but is only a minor savings compared to 838 a 256-bit ECDSA public-key. 839 Algorithm agility is provided by extensions to this 840 specification which may define a new leaf for another 841 hash type."; 842 } 844 leaf proximity-registrar-cert { 845 type binary; 846 description 847 "An X.509 v3 certificate structure as specified by 848 RFC 5280, 849 Section 4 encoded using the ASN.1 distinguished encoding 850 rules (DER), as specified in ITU-T X.690. 852 The first certificate in the Registrar TLS server 853 certificate_list sequence (see [RFC5246]) presented by 854 the Registrar to the Pledge. This field or one of its 855 alternatives MUST be populated in a 856 Pledge's voucher request if the proximity assertion is 857 populated."; 858 } 860 leaf prior-signed-voucher-request { 861 type binary; 862 description 863 "If it is necessary to change a voucher, or re-sign and 864 forward a voucher that was previously provided along a 865 protocol path, then the previously signed voucher 866 SHOULD be included in this field. 868 For example, a pledge might sign a proximity voucher, 869 which an intermediate registrar then re-signs to 870 make its own proximity assertion. This is a simple 871 mechanism for a chain of trusted parties to change a 872 voucher, while maintaining the prior signature 873 information. 875 The pledge MUST ignore all prior voucher information 876 when accepting a voucher for imprinting. Other 877 parties MAY examine the prior signed voucher 878 information for the purposes of policy decisions. 879 For example, this information could be useful to a 880 MASA to determine that both pledge and registrar 881 agree on proximity assertions. The MASA SHOULD 882 remove all prior-signed-voucher-request information when 883 signing a voucher for imprinting so as to minimize the 884 final voucher size."; 885 } 886 } 887 } 888 } 889 } 890 892 8.1.4. Example voucher request artifact 894 Below is a CBOR serialization of an example constrained voucher 895 request from a Pledge to a Registrar, shown in CBOR diagnostic 896 notation. The enum value of the assertion field is calculated to be 897 2 by following the algorithm described in section 9.6.4.2 of 898 [RFC7950]. Four dots ("....") in a CBOR byte string denotes a 899 sequence of bytes that are not shown for brevity. 901 { 902 2501: { 903 +2 : "2016-10-07T19:31:42Z", / SID=2503, created-on / 904 +4 : "2016-10-21T19:31:42Z", / SID=2505, expires-on / 905 +1 : 2, / SID=2502, assertion "proximity" / 906 +13: "JADA123456789", / SID=2514, serial-number / 907 +5 : h'08C2BF36....B3D2B3', / SID=2506, idevid-issuer / 908 +10: h'30820275....82c35f', / SID=2511, proximity-registrar-cert/ 909 +3 : true, / SID=2504, domain-cert 910 -revocation-checks/ 911 +6 : "2017-10-07T19:31:42Z" / SID=2507, last-renewal-date / 912 } 913 } 914 916 8.2. Voucher artifact 918 The voucher's primary purpose is to securely assign a Pledge to an 919 owner. The voucher informs the Pledge which entity it should 920 consider to be its owner. 922 8.2.1. Tree Diagram 924 The following diagram is largely a duplicate of the contents of 925 [RFC8366], with only the addition of the fields pinned-domain-pubk 926 and pinned-domain-pubk-sha256. 928 module: ietf-constrained-voucher 930 grouping voucher-constrained-grouping 931 +-- voucher 932 +-- created-on? yang:date-and-time 933 +-- expires-on? yang:date-and-time 934 +-- assertion enumeration 935 +-- serial-number string 936 +-- idevid-issuer? binary 937 +-- pinned-domain-cert? binary 938 +-- domain-cert-revocation-checks? boolean 939 +-- nonce? binary 940 +-- last-renewal-date? yang:date-and-time 941 +-- pinned-domain-pubk? binary 942 +-- pinned-domain-pubk-sha256? binary 943 945 8.2.2. SID values 947 SID Assigned to 948 --------- -------------------------------------------------- 949 2451 data /ietf-constrained-voucher:voucher 950 2452 data /ietf-constrained-voucher:voucher/assertion 951 2453 data /ietf-constrained-voucher:voucher/created-on 952 2454 data .../domain-cert-revocation-checks 953 2455 data /ietf-constrained-voucher:voucher/expires-on 954 2456 data /ietf-constrained-voucher:voucher/idevid-issuer 955 2457 data .../last-renewal-date 956 2458 data /ietf-constrained-voucher:voucher/nonce 957 2459 data .../pinned-domain-cert 958 2460 data .../pinned-domain-pubk 959 2461 data .../pinned-domain-pubk-sha256 960 2462 data /ietf-constrained-voucher:voucher/serial-number 962 WARNING, obsolete definitions 963 965 8.2.3. YANG Module 967 In the constrained-voucher YANG module, the voucher is "augmented" 968 within the "used" grouping statement such that one continuous set of 969 SID values is generated for the constrained-voucher module name, all 970 voucher attributes, and the constrained-voucher attributes. Two 971 attributes of the voucher are "refined" to be optional. 973 file "ietf-constrained-voucher@2021-04-15.yang" 974 module ietf-constrained-voucher { 975 yang-version 1.1; 977 namespace 978 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 979 prefix "constrained"; 981 import ietf-restconf { 982 prefix rc; 983 description 984 "This import statement is only present to access 985 the yang-data extension defined in RFC 8040."; 986 reference "RFC 8040: RESTCONF Protocol"; 987 } 989 import ietf-voucher { 990 prefix "v"; 991 } 993 organization 994 "IETF ANIMA Working Group"; 996 contact 997 "WG Web: 998 WG List: 999 Author: Michael Richardson 1000 1001 Author: Peter van der Stok 1002 1003 Author: Panos Kampanakis 1004 "; 1006 description 1007 "This module defines the format for a voucher, which 1008 is produced by a pledge's manufacturer or its delegate 1009 (MASA) to securely assign one or more pledges to an 'owner', 1010 so that a pledge may establish a secure connection to the 1011 owner's network infrastructure. 1013 This version provides a very restricted subset appropriate 1014 for very constrained devices. 1015 In particular, it assumes that nonce-ful operation is 1016 always required, that expiration dates are rather weak, as no 1017 clocks can be assumed, and that the Registrar is identified 1018 by either a pinned Raw Public Key of the Registrar, or by a 1019 pinned X.509 certificate of the Registrar or domain CA. 1021 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1022 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1023 and 'OPTIONAL' in the module text are to be interpreted as 1024 described in RFC 2119."; 1026 revision "2021-04-15" { 1027 description 1028 "Initial version"; 1029 reference 1030 "RFC XXXX: Voucher Profile for Constrained Devices"; 1031 } 1033 rc:yang-data voucher-constrained-artifact { 1034 // YANG data template for a voucher. 1035 uses voucher-constrained-grouping; 1036 } 1038 // Grouping defined for future usage 1039 grouping voucher-constrained-grouping { 1040 description 1041 "Grouping to allow reuse/extensions in future work."; 1043 uses v:voucher-artifact-grouping { 1045 refine voucher/created-on { 1046 mandatory false; 1047 } 1049 refine voucher/pinned-domain-cert { 1050 mandatory false; 1051 } 1053 augment "voucher" { 1054 description "Base the constrained voucher 1055 upon the regular one"; 1056 leaf pinned-domain-pubk { 1057 type binary; 1058 description 1059 "The pinned-domain-pubk may replace the 1060 pinned-domain-cert in constrained uses of 1061 the voucher. The pinned-domain-pubk 1062 is the Raw Public Key of the Registrar. 1063 This field is encoded as a Subject Public Key Info block 1064 as specified in RFC7250, in section 3. 1065 The ECDSA algorithm MUST be supported. 1066 The EdDSA algorithm as specified in 1067 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1068 Support for the DSA algorithm is not recommended. 1070 Support for the RSA algorithm is a MAY."; 1071 } 1073 leaf pinned-domain-pubk-sha256 { 1074 type binary; 1075 description 1076 "The pinned-domain-pubk-sha256 is a second 1077 alternative to pinned-domain-cert. In many cases the 1078 public key of the domain has already been transmitted 1079 during the key agreement process, and it is wasteful 1080 to transmit the public key another two times. 1081 The use of a hash of public key info, at 32-bytes for 1082 sha256 is a significant savings compared to an RSA 1083 public key, but is only a minor savings compared to 1084 a 256-bit ECDSA public-key. 1085 Algorithm agility is provided by extensions to this 1086 specification which can define a new leaf for another 1087 hash type."; 1088 } 1089 } 1090 } 1091 } 1092 } 1093 1095 8.2.4. Example voucher artifacts 1097 Below the CBOR serialization of an example constrained voucher is 1098 shown in CBOR diagnostic notation. The enum value of the assertion 1099 field is calculated to be zero by following the algorithm described 1100 in section 9.6.4.2 of [RFC7950]. Four dots ("....") in a CBOR byte 1101 string denotes a sequence of bytes that are not shown for brevity. 1103 { 1104 2451: { 1105 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 1106 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 1107 +1 : 0, / SID = 2452, assertion "verified" / 1108 +11: "JADA123456789", / SID = 2462, serial-number / 1109 +5 : h'E40393B4....68A3', / SID = 2456, idevid-issuer / 1110 +8 : h'30820275....C35F', / SID = 2459, pinned-domain-cert/ 1111 +3 : true, / SID = 2454, domain-cert / 1112 / -revocation-checks / 1113 +6 : "2017-10-07T19:31:42Z" / SID = 2457, last-renewal-date / 1114 } 1115 } 1117 1119 8.3. Signing voucher and voucher-request artifacts with COSE 1121 The COSE-Sign1 structure is discussed in section 4.2 of 1122 [I-D.ietf-cose-rfc8152bis-struct]. The CBOR object that carries the 1123 body, the signature, and the information about the body and signature 1124 is called the COSE_Sign1 structure. It is used when only one 1125 signature is used on the body. Support for ECDSA with sha256 1126 (secp256k1 and prime256v1 curves) is REQUIRED. Support for EdDSA is 1127 encouraged. [TBD EDNOTE: Expand and add a reference why. ] 1129 An example of the supported COSE-sign1 object structure is shown in 1130 Figure 3. 1132 COSE_Sign1( 1133 [ 1134 h'A101382E', # { "alg": EC256K1 } 1135 { 1136 "kid" : h'7890....1234' # hash256(public key) 1137 }, 1138 h'1234....5678', #voucher-request binary content 1139 h'4567....1234', #voucher-request binary public signature 1140 ] 1141 ) 1143 Figure 3: cose-sign1 example in CBOR diagnostic notation 1145 The [COSE-registry] specifies the integers that replace the strings 1146 and the mnemonics in Figure 3. The value of the key identifier "kid" 1147 parameter is an example value. Usually a hash of the public key is 1148 used to identify the public key. The choice of key identifier method 1149 is vendor-specific. The public key and its hash are derived from the 1150 relevant certificate (Pledge, Registrar or MASA certificate). [TBD 1151 EDNOTE: how can MASA know which kid method the Registrar has used/ 1152 supports? Does it matter?] 1154 In Appendix C a binary cose-sign1 object is shown based on the 1155 voucher-request example of Section 8.1.4. 1157 9. Design Considerations 1159 The design considerations for the CBOR encoding of vouchers are much 1160 the same as for JSON vouchers in [RFC8366]. One key difference is 1161 that the names of the leaves in the YANG definition do not affect the 1162 size of the resulting CBOR, as the SID translation process assigns 1163 integers to the names. 1165 Any POST request to the Registrar with resource /vs or /es returns a 1166 2.04 Changed response with empty payload. The client should be aware 1167 that the server may use a piggybacked CoAP response (ACK, 2.04) but 1168 may also respond with a separate CoAP response, i.e. first an (ACK, 1169 0.0) that is an acknowledgement of the request reception followed by 1170 a (CON, 2.04) response in a separate CoAP message. 1172 10. Raw Public Key Use Considerations 1174 This section explains techniques to reduce the number of bytes that 1175 are sent over the wire during the BRSKI bootstrap. The use of a raw 1176 public key (RPK) in the pinning process can significantly reduce the 1177 number of bytes and round trips, but it comes with a few significant 1178 operational limitations. 1180 10.1. The Registrar Trust Anchor 1182 When the Pledge first connects to the Registrar, the connection to 1183 the Registrar is provisional, as explained in section 5.6.2 of 1184 [RFC8995]. The Registrar provides its public key in a 1185 TLSServerCertificate, and the Pledge uses that to validate that 1186 integrity of the (D)TLS connection, but it does not validate the 1187 identity of the provided certificate. 1189 As the TLSServerCertificate object is never verified directly by the 1190 pledge, sending it can be considered superfluous. Instead of using a 1191 (TLSServer)Certificate of type X509 (see section 4.4.2 of [RFC8446]), 1192 a RawPublicKey object is used. 1194 A Registrar operating in a mixed environment can determine whether to 1195 send a Certificate or a Raw Public key: this is determined by the 1196 pledge including the server_certificate_type of RawPublicKey. This 1197 is shown in section 5 of [RFC7250]. 1199 The Pledge continues to send a client_certificate_type of X509, so 1200 that the Registrar can properly identify the pledge and distill the 1201 MASA URI information from its certificate. 1203 10.2. The Pledge Voucher Request 1205 The Pledge puts the Registrar's public key into the proximity- 1206 registrar-pubk field of the voucher-request. (The proximity- 1207 registrar-pubk-sha256 can also be used if the 32-bytes of a SHA256 1208 hash turns out to be smaller than a typical ECDSA key.) 1210 As the format of the pubk field is identical to the TLS Certificate 1211 RawPublicKey, no manipulation at all is needed to insert this into a 1212 voucher-request. 1214 10.3. The Voucher Response 1216 A returned voucher will have a pinned-domain-subk field with the 1217 identical key as was found in the proximity-registrar-pubk field 1218 above, as well as in the TLS connection. Validation of this key by 1219 the pledge is what takes the DTLS connection out of the provisional 1220 state (see [RFC8995] section 5.6.2). 1222 The voucher needs to be validated first. The Pledge needs to have a 1223 public key to validate the signature from the MASA on the voucher. 1225 In certain cases, the MASA's public key counterpart of the (private) 1226 signing key is already installed in the Pledge at manufacturing time. 1227 In other cases, if the MASA signing key is based upon a PKI (see 1228 [I-D.richardson-anima-masa-considerations] Section 2.3), then a 1229 certificate chain may need to be included with the voucher in order 1230 for the pledge to validate the signature. In CMS signed artifacts, 1231 the CMS structure has a place for such certificates. In the COSE- 1232 signed Constrained Vouchers described in this document, the x5bag 1233 attribute from [I-D.ietf-cose-x509] is to be used for this. 1235 11. Security Considerations 1237 11.1. Clock Sensitivity 1239 TBD. 1241 11.2. Protect Voucher PKI in HSM 1243 TBD. 1245 11.3. Test Domain Certificate Validity when Signing 1247 TBD. 1249 12. IANA Considerations 1251 12.1. Resource Type Registry 1253 Additions to the sub-registry "Resource Type Link Target Attribute 1254 Values", within the "CoRE parameters" IANA registry are specified 1255 below. 1257 brski needs registration with IANA 1258 brski.rv needs registration with IANA 1259 brski.vs needs registration with IANA 1260 brski.es needs registration with IANA 1262 12.2. The IETF XML Registry 1264 This document registers two URIs in the IETF XML registry [RFC3688]. 1265 Following the format in [RFC3688], the following registration is 1266 requested: 1268 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 1269 Registrant Contact: The ANIMA WG of the IETF. 1270 XML: N/A, the requested URI is an XML namespace. 1272 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 1273 Registrant Contact: The ANIMA WG of the IETF. 1274 XML: N/A, the requested URI is an XML namespace. 1276 12.3. The YANG Module Names Registry 1278 This document registers two YANG modules in the YANG Module Names 1279 registry [RFC6020]. Following the format defined in [RFC6020], the 1280 the following registration is requested: 1282 name: ietf-constrained-voucher 1283 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 1284 prefix: vch 1285 reference: RFC XXXX 1287 name: ietf-constrained-voucher-request 1288 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 1289 -voucher-request 1290 prefix: vch 1291 reference: RFC XXXX 1293 12.4. The RFC SID range assignment sub-registry 1295 ------------ ------ --------------------------- ------------ 1296 Entry-point | Size | Module name | RFC Number 1297 ------------ ------ --------------------------- ------------ 1298 2450 50 ietf-constrained-voucher [ThisRFC] 1299 2500 50 ietf-constrained-voucher [ThisRFC} 1300 -request 1301 ----------- ------ --------------------------- ------------ 1303 Warning: These SID values are defined in [I-D.ietf-core-sid], not as 1304 an Early Allocation. 1306 12.5. Media Types Registry 1308 This section registers the 'application/voucher-cose+cbor' in the 1309 IANA "Media Types" registry. This media type is used to indicate 1310 that the content is a CBOR voucher or voucher request signed with a 1311 COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct]. 1313 12.5.1. application/voucher-cose+cbor 1314 Type name: application 1315 Subtype name: voucher-cose+cbor 1316 Required parameters: none 1317 Optional parameters: cose-type 1318 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 1319 signed with one signer. 1320 Security considerations: See Security Considerations, Section 1321 Interoperability considerations: The format is designed to be 1322 broadly interoperable. 1323 Published specification: THIS RFC. 1324 Applications that use this media type: ANIMA, 6tisch, and other 1325 zero-touch imprinting systems 1326 Additional information: 1327 Magic number(s): None 1328 File extension(s): .vch 1329 Macintosh file type code(s): none 1330 Person & email address to contact for further information: IETF 1331 ANIMA WG 1332 Intended usage: LIMITED 1333 Restrictions on usage: NONE 1334 Author: ANIMA WG 1335 Change controller: IETF 1336 Provisional registration? (standards tree only): NO 1338 12.6. CoAP Content-Format Registry 1340 Additions to the sub-registry "CoAP Content-Formats", within the 1341 "CoRE Parameters" registry are needed for two media types. These can 1342 be registered either in the Expert Review range (0-255) or IETF 1343 Review range (256-9999). 1345 Media type mime type Encoding ID References 1346 ---------------------------- ----------- --------- ---- ---------- 1347 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 1349 13. Acknowledgements 1351 We are very grateful to Jim Schaad for explaining COSE and CMS 1352 choices. Also thanks to Jim Schaad for correcting earlier version of 1353 the COSE Sign1 objects. 1355 Michel Veillette did extensive work on pyang to extend it to support 1356 the SID allocation process, and this document was among its first 1357 uses. 1359 14. Changelog 1361 -10 Design considerations extended Examples made consistent 1363 -08 Examples for cose_sign1 are completed and improved. 1365 -06 New SID values assigned; regenerated examples 1367 -04 voucher and request-voucher MUST be signed examples for signed 1368 request are added in appendix IANA SID registration is updated SID 1369 values in examples are aligned signed cms examples aligned with new 1370 SIDs 1372 -03 1374 Examples are inverted. 1376 -02 1378 Example of requestvoucher with unsigned appllication/cbor is added 1379 attributes of voucher "refined" to optional 1380 CBOR serialization of vouchers improved 1381 Discovery port numbers are specified 1383 -01 1385 application/json is optional, application/cbor is compulsory 1386 Cms and cose mediatypes are introduced 1388 15. References 1390 15.1. Normative References 1392 [I-D.ietf-6tisch-minimal-security] 1393 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 1394 "Constrained Join Protocol (CoJP) for 6TiSCH", Work in 1395 Progress, Internet-Draft, draft-ietf-6tisch-minimal- 1396 security-15, 10 December 2019, 1397 . 1400 [I-D.ietf-ace-coap-est] 1401 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 1402 Raza, "EST over secure CoAP (EST-coaps)", Work in 1403 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 1404 January 2020, . 1407 [I-D.ietf-core-sid] 1408 Veillette, M., Pelov, A., Petrov, I., and C. Bormann, 1409 "YANG Schema Item iDentifier (YANG SID)", Work in 1410 Progress, Internet-Draft, draft-ietf-core-sid-16, 24 June 1411 2021, . 1414 [I-D.ietf-core-yang-cbor] 1415 Veillette, M., Petrov, I., Pelov, A., and C. Bormann, 1416 "CBOR Encoding of Data Modeled with YANG", Work in 1417 Progress, Internet-Draft, draft-ietf-core-yang-cbor-16, 24 1418 June 2021, . 1421 [I-D.ietf-cose-rfc8152bis-struct] 1422 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1423 Structures and Process", Work in Progress, Internet-Draft, 1424 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 1425 . 1428 [I-D.ietf-cose-x509] 1429 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1430 Header parameters for carrying and referencing X.509 1431 certificates", Work in Progress, Internet-Draft, draft- 1432 ietf-cose-x509-08, 14 December 2020, 1433 . 1436 [I-D.selander-ace-ake-authz] 1437 Selander, G., Mattsson, J. P., Vucinic, M., Richardson, 1438 M., and A. Schellenbaum, "Lightweight Authorization for 1439 Authenticated Key Exchange.", Work in Progress, Internet- 1440 Draft, draft-selander-ace-ake-authz-03, 4 May 2021, 1441 . 1444 [ieee802-1AR] 1445 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1446 2009, . 1449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1450 Requirement Levels", BCP 14, RFC 2119, 1451 DOI 10.17487/RFC2119, March 1997, 1452 . 1454 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1455 DOI 10.17487/RFC3688, January 2004, 1456 . 1458 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1459 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1460 . 1462 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1463 the Network Configuration Protocol (NETCONF)", RFC 6020, 1464 DOI 10.17487/RFC6020, October 2010, 1465 . 1467 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1468 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1469 October 2013, . 1471 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1472 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1473 Transport Layer Security (TLS) and Datagram Transport 1474 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1475 June 2014, . 1477 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1478 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1479 . 1481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1483 May 2017, . 1485 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1486 "A Voucher Artifact for Bootstrapping Protocols", 1487 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1488 . 1490 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1491 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1492 . 1494 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1495 and K. Watsen, "Bootstrapping Remote Secure Key 1496 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 1497 May 2021, . 1499 15.2. Informative References 1501 [COSE-registry] 1502 IANA, ., "CBOR Object Signing and Encryption (COSE) 1503 registry", 2017, 1504 . 1506 [I-D.ietf-netmod-yang-tree-diagrams] 1507 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", Work in 1508 Progress, Internet-Draft, draft-ietf-netmod-yang-tree- 1509 diagrams-06, 8 February 2018, 1510 . 1513 [I-D.richardson-anima-masa-considerations] 1514 Richardson, M. and J. Yang, "Operatonal Considerations for 1515 Voucher infrastructure for BRSKI MASA", Work in Progress, 1516 Internet-Draft, draft-richardson-anima-masa- 1517 considerations-05, 12 March 2021, 1518 . 1521 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1522 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1523 . 1525 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1526 "Enrollment over Secure Transport", RFC 7030, 1527 DOI 10.17487/RFC7030, October 2013, 1528 . 1530 Appendix A. Library support for BRSKI 1532 For the implementation of BRSKI, the use of a software library to 1533 manipulate certificates and use crypto algorithms is often 1534 beneficial. Two C-based examples are OPENSSL and mbedtls. Others 1535 more targeted to specific platforms or languages exist. It is 1536 important to realize that the library interfaces differ significantly 1537 between libraries. 1539 Libraries do not support all known crypto algorithms. Before 1540 deciding on a library, it is important to look at their supported 1541 crypto algorithms and the roadmap for future support. Apart from 1542 availability, the library footprint, and the required execution 1543 cycles should be investigated beforehand. 1545 The handling of certificates usually includes the checking of a 1546 certificate chain. In some libraries, chains are constructed and 1547 verified on the basis of a set of certificates, the trust anchor 1548 (usually self signed root CA), and the target certificate. In other 1549 libraries, the chain must be constructed beforehand and obey order 1550 criteria. Verification always includes the checking of the 1551 signatures. Less frequent is the checking the validity of the dates 1552 or checking the existence of a revoked certificate in the chain 1553 against a set of revoked certificates. Checking the chain on the 1554 consistency of the certificate extensions which specify the use of 1555 the certificate usually needs to be programmed explicitly. 1557 A libary can be used to construct a (D)TLS connection. It is useful 1558 to realize that differences beetween (D)TLS implementations will 1559 occur due to the differences in the certicate checks supported by the 1560 library. On top of that, checks between client and server 1561 certificates enforced by (D)TLS are not always helpful for a BRSKI 1562 implementation. For example, the certificates of Pledge and 1563 Registrar are usually not related when the BRSKI protocol is started. 1564 It must be verified that checks on the relation between client and 1565 server certificates do not hamper a succeful DTLS connection 1566 establishment. 1568 A.1. OpensSSL 1570 from openssl's apps/verify.c 1571 X509 *x = NULL; 1572 int i = 0, ret = 0; 1573 X509_STORE_CTX *csc; 1574 STACK_OF(X509) *chain = NULL; 1575 int num_untrusted; 1577 x = load_cert(file, "certificate file"); 1578 if (x == NULL) 1579 goto end; 1581 csc = X509_STORE_CTX_new(); 1582 if (csc == NULL) { 1583 BIO_printf(bio_err, "error %s: X.509 store context" 1584 "allocation failed\n", 1585 (file == NULL) ? "stdin" : file); 1586 goto end; 1587 } 1589 X509_STORE_set_flags(ctx, vflags); 1590 if (!X509_STORE_CTX_init(csc, ctx, x, uchain)) { 1591 X509_STORE_CTX_free(csc); 1592 BIO_printf(bio_err, 1593 "error %s: X.509 store context" 1594 "initialization failed\n", 1595 (file == NULL) ? "stdin" : file); 1596 goto end; 1597 } 1598 if (tchain != NULL) 1599 X509_STORE_CTX_set0_trusted_stack(csc, tchain); 1600 if (crls != NULL) 1601 X509_STORE_CTX_set0_crls(csc, crls); 1603 i = X509_verify_cert(csc); 1604 X509_STORE_CTX_free(csc); 1605 1607 A.2. mbedTLS 1609 mbedtls_x509_crt cert; 1610 mbedtls_x509_crt caCert; 1611 uint32_t certVerifyResultFlags; 1612 ... 1613 int result = mbedtls_x509_crt_verify(&cert, &caCert, NULL, NULL, 1614 &certVerifyResultFlags, NULL, NULL); 1616 A.3. wolfSSL 1618 To be added (TBD). 1620 Appendix B. Constrained BRSKI-EST messages 1622 This section extends the examples from Appendix A of 1623 [I-D.ietf-ace-coap-est] with the constrained BRSKI requests. The 1624 CoAP headers are only worked out for the enrollstatus example. 1626 B.1. enrollstatus 1628 A coaps enrollstatus message can be : 1630 POST coaps://192.0.2.1:8085/b/es 1632 The corresponding CoAP header fields are shown below. 1634 Ver = 1 1635 T = 0 (CON) 1636 Code = 0x02 (0.02 is POST) 1637 Options 1638 Option (Uri-Path) 1639 Option Delta = 0xb (option nr = 11) 1640 Option Length = 0x1 1641 Option Value = "b" 1642 Option (Uri-Path) 1643 Option Delta = 0x0 (option nr = 11) 1644 Option Length = 0x2 1645 Option Value = "es" 1646 Option (Content-Format) 1647 Option Delta = 0x1 (option nr = 12) 1648 Option Length = 0x1 1649 Option Value = 60 (application/cbor) 1650 Payload Marker = 0xFF 1651 Payload = 1653 The Uri-Host and Uri-Port Options are omitted because they coincide 1654 with the transport protocol destination address and port 1655 respectively. TBD - Show the binary CBOR payload of this example. 1657 A 2.04 Changed response from the Registrar will then be: 1659 2.04 Changed 1661 With CoAP fields: 1663 Ver=1 1664 T=2 (ACK) 1665 Code = 0x44 (2.04 Changed) 1667 B.2. voucher_status 1669 A coaps voucher_status message can be: 1671 POST coaps://[2001:db8::2:1]:61616/b/vs 1672 Content-Format: 60 (application/cbor) 1673 Payload = 1674 a46776657273696f6e0166737461747573f466726561736f6e7828496e66 1675 6f726d61746976652068756d616e2d7265616461626c65206572726f7220 1676 6d6573736167656e726561736f6e2d636f6e74657874a100764164646974 1677 696f6e616c20696e666f726d6174696f6e 1678 1680 The request payload above is binary CBOR but represented here in 1681 hexadecimal for readability. Below is the equivalent CBOR diagnostic 1682 format. 1684 {"version": 1, "status": false, 1685 "reason": "Informative human-readable error message", 1686 "reason-context": { 0: "Additional information" } } 1688 1690 A 2.04 Changed response without payload will then be sent by the 1691 Registrar back to the Pledge. 1693 2.04 Changed 1695 Appendix C. COSE examples 1697 These examples are generated on a Pi 4 and a PC running BASH. Keys 1698 and Certificates have been generated with openssl with the following 1699 shell script: 1701 #!/bin/bash 1702 #try-cert.sh 1703 export dir=./brski/intermediate 1704 export cadir=./brski 1705 export cnfdir=./conf 1706 export format=pem 1707 export default_crl_days=30 1708 sn=8 1710 DevID=pledge.1.2.3.4 1711 serialNumber="serialNumber=$DevID" 1712 export hwType=1.3.6.1.4.1.6715.10.1 1713 export hwSerialNum=01020304 # Some hex 1714 export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" 1715 echo $hwType - $hwSerialNum 1716 echo $serialNumber 1717 OPENSSL_BIN="openssl" 1719 # remove all files 1720 rm -r ./brski/* 1721 # 1722 # initialize file structure 1723 # root level 1724 cd $cadir 1725 mkdir certs crl csr newcerts private 1726 chmod 700 private 1727 touch index.txt 1728 touch serial 1729 echo 11223344556600 >serial 1730 echo 1000 > crlnumber 1731 # intermediate level 1732 mkdir intermediate 1733 cd intermediate 1734 mkdir certs crl csr newcerts private 1735 chmod 700 private 1736 touch index.txt 1737 echo 11223344556600 >serial 1738 echo 1000 > crlnumber 1739 cd ../.. 1741 # file structure is cleaned start filling 1743 echo "#############################" 1744 echo "create registrar keys and certificates " 1745 echo "#############################" 1747 echo "create root registrar certificate using ecdsa with sha 256 key" 1748 $OPENSSL_BIN ecparam -name prime256v1 -genkey \ 1749 -noout -out $cadir/private/ca-regis.key 1751 $OPENSSL_BIN req -new -x509 \ 1752 -config $cnfdir/openssl-regis.cnf \ 1753 -key $cadir/private/ca-regis.key \ 1754 -out $cadir/certs/ca-regis.crt \ 1755 -extensions v3_ca\ 1756 -days 365 \ 1757 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \ 1758 /CN=registrar.stok.nl" 1760 # Combine authority certificate and key 1761 echo "Combine authority certificate and key" 1762 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1763 -inkey $cadir/private/ca-regis.key \ 1764 -in $cadir/certs/ca-regis.crt -export \ 1765 -out $cadir/certs/ca-regis-comb.pfx 1767 # converteer authority pkcs12 file to pem 1768 echo "converteer authority pkcs12 file to pem" 1769 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1770 -in $cadir/certs/ca-regis-comb.pfx \ 1771 -out $cadir/certs/ca-regis-comb.crt -nodes 1773 #show certificate in registrar combined certificate 1774 $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text 1776 # 1777 # Certificate Authority for MASA 1778 # 1779 echo "#############################" 1780 echo "create MASA keys and certificates " 1781 echo "#############################" 1783 echo "create root MASA certificate using ecdsa with sha 256 key" 1784 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 1785 -out $cadir/private/ca-masa.key 1787 $OPENSSL_BIN req -new -x509 \ 1788 -config $cnfdir/openssl-masa.cnf \ 1789 -days 1000 -key $cadir/private/ca-masa.key \ 1790 -out $cadir/certs/ca-masa.crt \ 1791 -extensions v3_ca\ 1792 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\ 1793 /CN=masa.stok.nl" 1795 # Combine authority certificate and key 1796 echo "Combine authority certificate and key for masa" 1797 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1798 -inkey $cadir/private/ca-masa.key \ 1799 -in $cadir/certs/ca-masa.crt -export \ 1800 -out $cadir/certs/ca-masa-comb.pfx 1802 # converteer authority pkcs12 file to pem for masa 1803 echo "converteer authority pkcs12 file to pem for masa" 1804 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1805 -in $cadir/certs/ca-masa-comb.pfx \ 1806 -out $cadir/certs/ca-masa-comb.crt -nodes 1808 #show certificate in pledge combined certificate 1809 $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text 1811 # 1812 # Certificate for Pledge derived from MASA certificate 1813 # 1814 echo "#############################" 1815 echo "create pledge keys and certificates " 1816 echo "#############################" 1818 # Pledge derived Certificate 1820 echo "create pledge derived certificate using ecdsa with sha 256 key" 1821 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 1822 -out $dir/private/pledge.key 1824 echo "create pledge certificate request" 1825 $OPENSSL_BIN req -nodes -new -sha256 \ 1826 -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ 1827 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ 1828 /CN=uuid:$DevID/$serialNumber" 1830 # Sign pledge derived Certificate 1831 echo "sign pledge derived certificate " 1832 $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \ 1833 -extensions 8021ar_idevid\ 1834 -days 365 -in $dir/csr/pledge.csr \ 1835 -out $dir/certs/pledge.crt 1837 # Add pledge key and pledge certificate to pkcs12 file 1838 echo "Add derived pledge key and derived pledge \ 1839 certificate to pkcs12 file" 1840 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1841 -inkey $dir/private/pledge.key \ 1842 -in $dir/certs/pledge.crt -export \ 1843 -out $dir/certs/pledge-comb.pfx 1845 # converteer pledge pkcs12 file to pem 1846 echo "converteer pledge pkcs12 file to pem" 1847 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1848 -in $dir/certs/pledge-comb.pfx \ 1849 -out $dir/certs/pledge-comb.crt -nodes 1851 #show certificate in pledge-comb.crt 1852 $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text 1854 #show private key in pledge-comb.crt 1855 $OPENSSL_BIN ecparam -name prime256v1\ 1856 -in $dir/certs/pledge-comb.crt -text 1857 1859 The xxxx-comb certificates have been generated as required by libcoap 1860 for the DTLS connection generation. 1862 C.1. Pledge, Registrar and MASA keys 1864 This first section documents the public and private keys used in the 1865 subsequent test vectors below. These keys come from test code and 1866 are not used in any production system, and should only be used only 1867 to validate implementations. 1869 C.1.1. Pledge private key 1871 Private-Key: (256 bit) 1872 priv: 1873 9b:4d:43:b6:a9:e1:7c:04:93:45:c3:13:d9:b5:f0: 1874 41:a9:6a:9c:45:79:73:b8:62:f1:77:03:3a:fc:c2: 1875 9c:9a 1876 pub: 1877 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 1878 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 1879 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 1880 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 1881 60:eb:95:5c:54 1882 ASN1 OID: prime256v1 1883 NIST CURVE: P-256 1884 1886 C.1.2. Registrar private key 1887 Private-Key: (256 bit) 1888 priv: 1889 81:df:bb:50:a3:45:58:06:b5:56:3b:46:de:f3:e9: 1890 e9:00:ae:98:13:9e:2f:36:68:81:fc:d9:65:24:fb: 1891 21:7e 1892 pub: 1893 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 1894 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 1895 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 1896 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 1897 3e:d0:2d:c7:b7 1898 ASN1 OID: prime256v1 1899 NIST CURVE: P-256 1900 1902 C.1.3. MASA private key 1904 Private-Key: (256 bit) 1905 priv: 1906 c6:bb:a5:8f:b6:d3:c4:75:28:d8:d3:d9:46:c3:31: 1907 83:6d:00:0a:9a:38:ce:22:5c:e9:d9:ea:3b:98:32: 1908 ec:31 1909 pub: 1910 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 1911 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 1912 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 1913 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 1914 ed:f3:17:5c:f1 1915 ASN1 OID: prime256v1 1916 NIST CURVE: P-256 1917 1919 C.2. Pledge, Registrar and MASA certificates 1921 Below the certificates that accompany the keys. The certificate 1922 description is followed by the hexadecimal DER of the certificate 1924 C.2.1. Pledge IDevID certificate 1925 Certificate: 1926 Data: 1927 Version: 3 (0x2) 1928 Serial Number: 4822678189204992 (0x11223344556600) 1929 Signature Algorithm: ecdsa-with-SHA256 1930 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturer, 1931 CN=masa.stok.nl 1932 Validity 1933 Not Before: Dec 9 10:02:36 2020 GMT 1934 Not After : Dec 31 23:59:59 9999 GMT 1935 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturing, 1936 CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4 1937 Subject Public Key Info: 1938 Public Key Algorithm: id-ecPublicKey 1939 Public-Key: (256 bit) 1940 pub: 1941 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 1942 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 1943 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 1944 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 1945 60:eb:95:5c:54 1946 ASN1 OID: prime256v1 1947 NIST CURVE: P-256 1948 X509v3 extensions: 1949 X509v3 Basic Constraints: 1950 CA:FALSE 1951 X509v3 Authority Key Identifier: 1952 keyid: 1953 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 1955 Signature Algorithm: ecdsa-with-SHA256 1956 30:46:02:21:00:d2:e6:45:3b:b0:c3:00:b3:25:8d:f1:83:fe: 1957 d9:37:c1:a2:49:65:69:7f:6b:b9:ef:2c:05:07:06:31:ac:17: 1958 bd:02:21:00:e2:ce:9e:7b:7f:74:50:33:ad:9e:ff:12:4e:e9: 1959 a6:f3:b8:36:65:ab:7d:80:bb:56:88:bc:03:1d:e5:1e:31:6f 1961 1963 This is the hexadecimal representation in (request-)voucher examples 1964 referred to as pledge-cert-hex. 1966 30820226308201cba003020102020711223344556600300a06082a8648ce3d04 1967 0302306f310b3009060355040613024e4c310b300906035504080c024e423110 1968 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 1969 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 1970 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323031323039313030 1971 3233365a180f39393939313233313233353935395a308190310b300906035504 1972 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 1973 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 1974 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 1975 3a706c656467652e312e322e332e34311730150603550405130e706c65646765 1976 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 1977 420004d6b76f7488bd80ae5f28412c7202ef5f98b481e1d9104cf81b66d43e5c 1978 eada73e6a838a9f1351185b6cde20410befed50b3b14692ee1b06abc554060eb 1979 955c54a32e302c30090603551d1304023000301f0603551d23041830168014e4 1980 0393b4c3d3f42a80a47718f6964903011768a3300a06082a8648ce3d04030203 1981 49003046022100d2e6453bb0c300b3258df183fed937c1a24965697f6bb9ef2c 1982 05070631ac17bd022100e2ce9e7b7f745033ad9eff124ee9a6f3b83665ab7d80 1983 bb5688bc031de51e316f 1985 C.2.2. Registrar Certificate 1986 Certificate: 1987 Data: 1988 Version: 3 (0x2) 1989 Serial Number: 1990 70:56:ea:aa:30:66:d8:82:6a:55:5b:90:88:d4:62:bf:9c:f2:8c:fd 1991 Signature Algorithm: ecdsa-with-SHA256 1992 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 1993 CN=registrar.stok.nl 1994 Validity 1995 Not Before: Dec 9 10:02:36 2020 GMT 1996 Not After : Dec 9 10:02:36 2021 GMT 1997 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 1998 CN=registrar.stok.nl 1999 Subject Public Key Info: 2000 Public Key Algorithm: id-ecPublicKey 2001 Public-Key: (256 bit) 2002 pub: 2003 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2004 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2005 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2006 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2007 3e:d0:2d:c7:b7 2008 ASN1 OID: prime256v1 2009 NIST CURVE: P-256 2010 X509v3 extensions: 2011 X509v3 Subject Key Identifier: 2012 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2013 X509v3 Authority Key Identifier: 2014 keyid: 2015 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2017 X509v3 Basic Constraints: critical 2018 CA:TRUE 2019 X509v3 Extended Key Usage: 2020 CMC Registration Authority, TLS Web Server 2021 Authentication, TLS Web Client Authentication 2022 X509v3 Key Usage: critical 2023 Digital Signature, Non Repudiation, Key Encipherment, 2024 Data Encipherment, Certificate Sign, CRL Sign 2025 Signature Algorithm: ecdsa-with-SHA256 2026 30:44:02:20:74:4c:99:00:85:13:b2:f1:bc:fd:f9:02:1a:46: 2027 fb:17:4c:f8:83:a2:7c:a1:d9:3f:ae:ac:f3:1e:4e:dd:12:c6: 2028 02:20:11:47:14:db:f5:1a:5e:78:f5:81:b9:42:1c:6e:47:02: 2029 ab:53:72:70:c5:ba:fb:2d:16:c3:de:9a:a1:82:c3:5f 2031 2032 This the hexadecimal representation, in (request-)voucher examples 2033 referred to as regis-cert-hex 2035 308202753082021ca00302010202147056eaaa3066d8826a555b9088d462bf9c 2036 f28cfd300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 2037 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2038 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 2039 73756c74616e6379311a301806035504030c117265676973747261722e73746f 2040 6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030 2041 3233365a3073310b3009060355040613024e4c310b300906035504080c024e42 2042 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 2043 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 2044 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 2045 8648ce3d020106082a8648ce3d03010703420004507ac8491a8c69c7b5c31d03 2046 09ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b8934021898d 2047 a789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d 2048 0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d23 2049 04183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d 2050 130101ff040530030101ff30270603551d250420301e06082b0601050507031c 2051 06082b0601050507030106082b06010505070302300e0603551d0f0101ff0404 2052 030201f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 2053 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf51a5e 2054 78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f 2056 C.2.3. MASA Certificate 2058 Certificate: 2059 Data: 2060 Version: 3 (0x2) 2061 Serial Number: 2062 14:26:b8:1c:ce:d8:c3:e8:14:05:cb:87:67:0d:be:ef:d5:81:25:b4 2063 Signature Algorithm: ecdsa-with-SHA256 2064 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 2065 OU=manufacturer, CN=masa.stok.nl 2067 Validity 2068 Not Before: Dec 9 10:02:36 2020 GMT 2069 Not After : Sep 5 10:02:36 2023 GMT 2070 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 2071 OU=manufacturer, CN=masa.stok.nl 2072 Subject Public Key Info: 2073 Public Key Algorithm: id-ecPublicKey 2074 Public-Key: (256 bit) 2075 pub: 2076 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2077 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2078 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2079 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2081 ed:f3:17:5c:f1 2082 ASN1 OID: prime256v1 2083 NIST CURVE: P-256 2084 X509v3 extensions: 2085 X509v3 Subject Key Identifier: 2086 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2087 X509v3 Authority Key Identifier: 2088 keyid: 2089 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2091 X509v3 Basic Constraints: critical 2092 CA:TRUE 2093 X509v3 Extended Key Usage: 2094 CMC Registration Authority, 2095 TLS Web Server Authentication, 2096 TLS Web Client Authentication 2097 X509v3 Key Usage: critical 2098 Digital Signature, Non Repudiation, Key Encipherment, 2099 Data Encipherment, Certificate Sign, CRL Sign 2100 Signature Algorithm: ecdsa-with-SHA256 2101 30:44:02:20:2e:c5:f2:24:72:70:20:ea:6e:74:8b:13:93:67: 2102 8a:e6:fe:fb:8d:56:7f:f5:34:18:a9:ef:a5:0f:c3:99:ca:53: 2103 02:20:3d:dc:91:d0:e9:6a:69:20:01:fb:e4:20:40:de:7c:7d: 2104 98:ed:d8:84:53:61:84:a7:f9:13:06:4c:a9:b2:8f:5c 2106 2108 This is the hexadecimal representation, in (request-)voucher examples 2109 referred to as masa-cert-hex. 2111 3082026d30820214a00302010202141426b81cced8c3e81405cb87670dbeefd5 2112 8125b4300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 2113 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2114 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 2115 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 2116 301e170d3230313230393130303233365a170d3233303930353130303233365a 2117 306f310b3009060355040613024e4c310b300906035504080c024e423110300e 2118 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 2119 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 2120 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 2121 2a8648ce3d0301070342000459809466149420303c6608855586dbe7d4d1d77a 2122 d2a31a0c736b010d021215d61ff36ec8d48460433b21c583801efce237857797 2123 94d4aa34b5b6c6edf3175cf1a3818d30818a301d0603551d0e04160414e40393 2124 b4c3d3f42a80a47718f6964903011768a3301f0603551d23041830168014e403 2125 93b4c3d3f42a80a47718f6964903011768a3300f0603551d130101ff04053003 2126 0101ff30270603551d250420301e06082b0601050507031c06082b0601050507 2127 030106082b06010505070302300e0603551d0f0101ff0404030201f6300a0608 2128 2a8648ce3d040302034700304402202ec5f224727020ea6e748b1393678ae6fe 2129 fb8d567ff53418a9efa50fc399ca5302203ddc91d0e96a692001fbe42040de7c 2130 7d98edd884536184a7f913064ca9b28f5c 2132 C.3. COSE signed voucher request from Pledge to Registrar 2134 In this example the voucher request has been signed by the Pledge, 2135 and has been sent to the JRC over CoAPS. The Pledge uses the 2136 proximity assertion together with an included proximity-registrar- 2137 cert field to inform MASA about its proximity to the specific 2138 Registrar. 2140 POST coaps://registrar.example.com/b/rv 2141 (Content-Format: application/voucher-cose+cbor) 2142 signed_request_voucher 2144 The payload signed_request_voucher is shown as hexadecimal dump (with 2145 lf added): 2147 d28444a101382ea104582097113db094eee8eae48683e7337875c0372164 2148 be89d023a5f3df52699c0fbfb55902d2a11909c5a60274323032302d3132 2149 2d32335431323a30353a32325a0474323032322d31322d32335431323a30 2150 353a32325a01020750684ca83e27230aff97630cf2c1ec409a0d6e706c65 2151 6467652e312e322e332e340a590279308202753082021ca0030201020214 2152 7056eaaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d04 2153 03023073310b3009060355040613024e4c310b300906035504080c024e42 2154 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76 2155 616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e63 2156 79311a301806035504030c117265676973747261722e73746f6b2e6e6c30 2157 1e170d3230313230393130303233365a170d323131323039313030323336 2158 5a3073310b3009060355040613024e4c310b300906035504080c024e4231 2159 10300e06035504070c0748656c6d6f6e6431133011060355040a0c0a7661 2160 6e64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379 2161 311a301806035504030c117265676973747261722e73746f6b2e6e6c3059 2162 301306072a8648ce3d020106082a8648ce3d03010703420004507ac8491a 2163 8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6beb 2164 b94e02b8934021898da789c711cea71339f50e348edf0d923ed02dc7b7a3 2165 818d30818a301d0603551d0e0416041408c2bf36887f79412185872f16a7 2166 aca6efb3d2b3301f0603551d2304183016801408c2bf36887f7941218587 2167 2f16a7aca6efb3d2b3300f0603551d130101ff040530030101ff30270603 2168 551d250420301e06082b0601050507031c06082b0601050507030106082b 2169 06010505070302300e0603551d0f0101ff0404030201f6300a06082a8648 2170 ce3d04030203470030440220744c99008513b2f1bcfdf9021a46fb174cf8 2171 83a27ca1d93faeacf31e4edd12c60220114714dbf51a5e78f581b9421c6e 2172 4702ab537270c5bafb2d16c3de9aa182c35f58473045022063766c7bbd1b 2173 339dbc398e764af3563e93b25a69104befe9aac2b3336b8f56e1022100cd 2174 0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f2991484 2175 e9 2176 2178 The representiation of signed_voucher_request in CBOR diagnostic 2179 format is: 2181 Diagnose(signed_request_voucher) = 2182 18([ 2183 h'A101382E', // {"alg": -47} 2184 {4: h'97113DB094EEE8EAE48683E7337875C0372164B 2185 E89D023A5F3DF52699C0FBFB5'}, 2186 h'1234', // request_voucher 2187 h'3045022063766C7BBD1B339DBC398E764AF3563E93B 2188 25A69104BEFE9AAC2B3336B8F56E1022100CD0419559A 2189 D960CCAED4DEE3F436ECA40B7570B25A52EB60332BC1F 2190 2991484E9' 2191 ]) 2193 Diagnose(request_voucher) = 2194 {2501: {2: "2020-12-23T12:05:22Z", 2195 4: "2022-12-23T12:05:22Z", 2196 1: 2, 2197 7: h'684CA83E27230AFF97630CF2C1EC409A', 2198 13: "pledge.1.2.3.4", 2199 10: h'1234' // regis-cert-hex 2200 }} 2201 2203 C.4. COSE signed voucher request from Registrar to MASA 2205 TBD - modify example to use full paths to MASA, not short-names. 2206 Also not use CoAP but HTTP protocol. 2208 In this example the voucher request has been signed by the JRC using 2209 the private key from Appendix C.1.2. Contained within this voucher 2210 request is the voucher request from the Pledge to JRC. 2212 POST coaps://masa.example.com/b/rv 2213 (Content-Format: application/voucher-cose+cbor) 2214 signed_masa_request_voucher 2216 The payload signed_masa_voucher_request is shown as hexadecimal dump 2217 (with lf added): 2219 d28444a101382ea1045820e8735bc4b470c3aa6a7aa9aa8ee584c09c1113 2220 1b205efec5d0313bad84c5cd05590414a11909c5a60274323032302d3132 2221 2d32385431303a30333a33355a0474323032322d31322d32385431303a30 2222 333a33355a07501551631f6e0416bd162ba53ea00c2a050d6e706c656467 2223 652e312e322e332e3405587131322d32385431303a30333a33355a075015 2224 51631f6e0416bd162ba53ea00c2a050d6e706c656467652e312e322e332e 2225 3405587131322d32385431303a300000000000000000000000000416bd16 2226 2ba53ea00c2a050d6e706c656467652e312e322e332e3405587131322d32 2227 385431303a09590349d28444a101382ea104582097113db094eee8eae486 2228 83e7337875c0372164be89d023a5f3df52699c0fbfb55902d2a11909c5a6 2229 0274323032302d31322d32385431303a30333a33355a0474323032322d31 2230 322d32385431303a30333a33355a010207501551631f6e0416bd162ba53e 2231 a00c2a050d6e706c656467652e312e322e332e340a590279308202753082 2232 021ca00302010202147056eaaa3066d8826a555b9088d462bf9cf28cfd30 2233 0a06082a8648ce3d0403023073310b3009060355040613024e4c310b3009 2234 06035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2235 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b63 2236 6f6e73756c74616e6379311a301806035504030c11726567697374726172 2237 2e73746f6b2e6e6c301e170d3230313230393130303233365a170d323131 2238 3230393130303233365a3073310b3009060355040613024e4c310b300906 2239 035504080c024e423110300e06035504070c0748656c6d6f6e6431133011 2240 060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f 2241 6e73756c74616e6379311a301806035504030c117265676973747261722e 2242 73746f6b2e6e6c3059301306072a8648ce3d020106082a8648ce3d030107 2243 03420004507ac8491a8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018 2244 154fa059b020ec6bebb94e02b8934021898da789c711cea71339f50e348e 2245 df0d923ed02dc7b7a3818d30818a301d0603551d0e0416041408c2bf3688 2246 7f79412185872f16a7aca6efb3d2b3301f0603551d2304183016801408c2 2247 bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff0405 2248 30030101ff30270603551d250420301e06082b0601050507031c06082b06 2249 01050507030106082b06010505070302300e0603551d0f0101ff04040302 2250 01f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 2251 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf5 2252 1a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f584730 2253 45022063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3 2254 336b8f56e1022100cd0419559ad960ccaed4dee3f436eca40b7570b25a52 2255 eb60332bc1f2991484e958473045022100e6b45558c1b806bba23f4ac626 2256 c9bdb6fd354ef4330d8dfb7c529f29cca934c802203c1f2ccbbac89733d1 2257 7ee7775bc2654c5f1cc96afba2741cc31532444aa8fed8 2259 2261 The representiation of signed_masa_voucher_request in CBOR diagnostic 2262 format is: 2264 Diagnose(signed_registrar_request-voucher) 2265 18([ 2266 h'A101382E', // {"alg": -47} 2267 h'E8735BC4B470C3AA6A7AA9AA8EE584C09C11131B205EFEC5D0313BAD84 2268 C5CD05'}, 2269 h'1234', // registrar_request_voucher', 2270 h'3045022100E6B45558C1B806BBA23F4AC626C9BDB6FD354EF4330D8DFB 2271 7C529F29CCA934C802203C1F2CCBBAC89733D17EE7775BC2654C5F1CC96A 2272 FBA2741CC31532444AA8FED8' 2273 ]) 2275 Diagnose(registrar_request_voucher) 2276 {2501: 2277 {2: "2020-12-28T10:03:35Z", 2278 4: "2022-12-28T10:03:35Z", 2279 7: h'1551631F6E0416BD162BA53EA00C2A05', 2280 13: "pledge.1.2.3.4", 2281 5: h'31322D32385431303A30333A33355A07501551631F6E0416BD 2282 162BA53EA00C2A050D6E706C656467652E312E322E332E3405 2283 587131322D32385431303A3000000000000000000000000004 2284 16BD162BA53EA00C2A050D6E706C656467652E312E322E332E 2285 3405587131322D32385431303A', 2286 9: h'1234' // signature 2287 }} 2288 2290 C.5. COSE signed voucher from MASA to Pledge via Registrar 2292 The resulting voucher is created by the MASA and returned via the JRC 2293 to the Pledge. It is signed by the MASA's private key Appendix C.1.3 2294 and can be verified by the Pledge using the MASA's public key 2295 contained within the MASA certificate. 2297 This is the raw binary signed_voucher, encoded in hexadecimal (with 2298 lf added): 2300 d28444a101382ea104582039920a34ee92d3148ab3a729f58611193270c9 2301 029f7784daf112614b19445d5158cfa1190993a70274323032302d31322d 2302 32335431353a30333a31325a0474323032302d31322d32335431353a3233 2303 3a31325a010007506508e06b2959d5089d7a3169ea889a490b6e706c6564 2304 67652e312e322e332e340858753073310b3009060355040613024e4c310b 2305 300906035504080c024e423110300e06035504070c0748656c6d6f6e6431 2306 133011060355040a0c0a76616e64657273746f6b31143012060355040b0c 2307 0b636f6e73756c74616e6379311a301806035504030c1172656769737472 2308 61722e73746f6b2e6e6c03f458473045022022515d96cd12224ee5d3ac67 2309 3237163bba24ad84815699285d9618f463ee73fa022100a6bff9d8585c1c 2310 9256371ece94da3d26264a5dfec0a354fe7b3aef58344c512f 2312 2314 The representiation of signed_voucher in CBOR diagnostic format is: 2316 Diagnose(signed_voucher) = 2317 18([ 2318 h'A101382E', # {"alg": -47} 2319 {4: h'39920A34EE92D3148AB3A729F58611193270C9029F7784DAF112614B194 2320 45D51'}, 2321 h'voucher', 2322 h'3045022022515D96CD12224EE5D3AC673237163BBA24AD84815699285D9618F 2323 463EE73FA022100A6BFF9D8585C1C9256371ECE94DA3D26264A5DFEC0A354FE7B 2324 3AEF58344C512F' 2325 ]) 2327 Diagnose(voucher) = 2328 {2451: 2329 {2: "2020-12-23T15:03:12Z", 2330 4: "2020-12-23T15:23:12Z", 2331 1: 0, 2332 7: h'6508E06B2959D5089D7A3169EA889A49', 2333 11: "pledge.1.2.3.4", 2334 8: h'regis-cert-hex', 2335 3: false}} 2336 2338 Contributors 2340 Russ Housley 2342 Email: housley@vigilsec.com 2344 Authors' Addresses 2345 Michael Richardson 2346 Sandelman Software Works 2348 Email: mcr+ietf@sandelman.ca 2350 Peter van der Stok 2351 vanderstok consultancy 2353 Email: consultancy@vanderstok.org 2355 Panos Kampanakis 2356 Cisco Systems 2358 Email: pkampana@cisco.com 2360 Esko Dijk 2361 IoTconsultancy.nl 2363 Email: esko.dijk@iotconsultancy.nl