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