idnits 2.17.1 draft-ietf-anima-constrained-voucher-10.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 : ---------------------------------------------------------------------------- ** There are 66 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([BRSKI], [RFC8366]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 796 has weird spacing: '...ndatory false...' == Line 800 has weird spacing: '...ndatory false...' == Line 1050 has weird spacing: '...ndatory false...' == Line 1054 has weird spacing: '...ndatory false...' -- The document date (February 20, 2021) is 1161 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 608, but not defined == Missing Reference: 'ThisRFC' is mentioned on line 1236, but not defined == Missing Reference: 'This RFC' is mentioned on line 1285, but not defined == Missing Reference: 'Empty' is mentioned on line 1462, but not defined == Unused Reference: 'RFC5652' is defined on line 1383, 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-02 ** Downref: Normative reference to an Informational draft: draft-selander-ace-ake-authz (ref. 'I-D.selander-ace-ake-authz') ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-15) exists of draft-ietf-anima-constrained-join-proxy-02 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: August 24, 2021 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 E. Dijk 9 IoTconsultancy.nl 10 February 20, 2021 12 Constrained Voucher Artifacts for Bootstrapping Protocols 13 draft-ietf-anima-constrained-voucher-10 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 August 24, 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 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 5 68 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 6 69 6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Discovery, URIs and Content Formats . . . . . . . . . . . 7 71 6.2. Discovery, URIs and Content Formats . . . . . . . . . . . 7 72 6.3. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8 73 6.4. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 8 74 6.4.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 8 75 6.4.2. Registrar Extensions . . . . . . . . . . . . . . . . 10 76 7. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 10 77 8. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 11 78 8.1. Registrar Identity Selection and Encoding . . . . . . . . 11 79 8.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 12 80 8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 13 81 9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 15 83 9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 15 84 9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 16 85 9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 17 86 9.1.4. Example voucher request artifact . . . . . . . . . . 21 87 9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 21 88 9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 21 89 9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 22 90 9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 22 91 9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 25 92 9.3. Signing voucher and voucher-request artifacts with COSE . 26 93 10. Design Considerations . . . . . . . . . . . . . . . . . . . . 26 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 95 11.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . 27 96 11.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 27 97 11.3. Test Domain Certificate Validity when Signing . . . . . 27 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 12.1. Resource Type Registry . . . . . . . . . . . . . . . . . 27 100 12.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 27 101 12.3. The YANG Module Names Registry . . . . . . . . . . . . . 28 102 12.4. The RFC SID range assignment sub-registry . . . . . . . 28 103 12.5. Media-Type Registry . . . . . . . . . . . . . . . . . . 28 104 12.5.1. application/voucher-cose+cbor . . . . . . . . . . . 28 105 12.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 29 106 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 107 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 15.1. Normative References . . . . . . . . . . . . . . . . . . 30 110 15.2. Informative References . . . . . . . . . . . . . . . . . 32 111 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 33 112 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 33 113 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 34 114 Appendix B. COSE examples . . . . . . . . . . . . . . . . . . . 35 115 B.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 38 116 B.1.1. Pledge private key . . . . . . . . . . . . . . . . . 38 117 B.1.2. Registrar private key . . . . . . . . . . . . . . . . 39 118 B.1.3. MASA private key . . . . . . . . . . . . . . . . . . 39 119 B.2. Pledge, Registrar and MASA certificates . . . . . . . . . 40 120 B.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 40 121 B.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 41 122 B.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 43 123 B.3. COSE signed voucher request from Pledge to Registrar . . 45 124 B.4. COSE signed voucher request from Registrar to MASA . . . 47 125 B.5. COSE signed voucher from MASA to Pledge via Registrar . . 48 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 128 1. Introduction 130 Secure enrollment of new nodes into constrained networks with 131 constrained nodes presents unique challenges. There are network 132 bandwidth and code size issues to contend with. A solution for 133 autonomous enrollment such as [I-D.ietf-anima-bootstrapping-keyinfra] 134 may be too large in terms of code size or bandwidth required. 136 Therefore, this document defines a constrained version of the voucher 137 artifact [RFC8366], along with a constrained version of BRSKI 138 [I-D.ietf-anima-bootstrapping-keyinfra] that makes use of the 139 constrained CoAP-based version of EST, EST-coaps 140 [I-D.ietf-ace-coap-est] rather than EST over HTTPS [RFC7030]. 142 While the [RFC8366] voucher is by default serialized to JSON with a 143 signature in CMS, this document defines a new voucher serialization 144 to CBOR ([RFC7049]) with a signature in COSE 145 [I-D.ietf-cose-rfc8152bis-struct]. This COSE-signed CBOR-encoded 146 voucher can be transported using secured CoAP or HTTP. The CoAP 147 connection (between Pledge and Registrar) is to be protected by 148 either OSCORE+EDHOC, or DTLS (CoAPS). The HTTP connection (between 149 Registrar and MASA) is to be protected using TLS (HTTPS). 151 This document has a similar structure to [RFC8366] but adds sections 152 concerning: 154 1. Voucher-request artifact specification based on Section 3 of 155 [I-D.ietf-anima-bootstrapping-keyinfra], 157 2. Voucher(-request) transport over CoAP based on Section 3 of 158 [I-D.ietf-anima-bootstrapping-keyinfra] and on 159 [I-D.ietf-ace-coap-est]. 161 The CBOR definitions for the constrained voucher format are defined 162 using the mechanism described in [I-D.ietf-core-yang-cbor] using the 163 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 164 convert YANG documents into a list of SID keys is still in its 165 infancy, the table of SID values presented here should be considered 166 normative rather than the output of the pyang tool. 168 There is additional work when the voucher is integrated into the key- 169 exchange, described in [I-D.selander-ace-ake-authz]. This work is 170 not in scope for this document. 172 2. Terminology 174 The following terms are defined in [RFC8366], and are used 175 identically as in that document: artifact, domain, imprint, Join 176 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 177 Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and 178 Voucher. 180 The following terms from [I-D.ietf-anima-bootstrapping-keyinfra] are 181 used identically as in that document: Domain CA, enrollment, IDevID, 182 Join Proxy, LDevID, manufacturer, nonced, nonceless, PKIX. 184 3. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in 189 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 4. Survey of Voucher Types 194 [RFC8366] provides for vouchers that assert proximity, that 195 authenticate the Registrar and that can offer varying levels of anti- 196 replay protection. 198 This document does not make any extensions to the semantic meanings 199 of vouchers, only the encoding has been changed to optimize for 200 constrained devices and networks. 202 Time-based vouchers are supported in this definition, but given that 203 constrained devices are extremely unlikely to have accurate time, 204 their use is very unlikely. Most Pledges using these constrained 205 vouchers will be online during enrollment and will use live nonces to 206 provide anti-replay protection. 208 [RFC8366] defined only the voucher artifact, and not the Voucher 209 Request artifact, which was defined in 210 [I-D.ietf-anima-bootstrapping-keyinfra]. This document defines both 211 a constrained voucher and a constrained voucher-request. They are 212 presented in the order "voucher-request", followed by a "voucher" 213 response as this is the order that they occur in the protocol. 215 The constrained voucher request MUST be signed by the Pledge. It can 216 sign using its IDevID X.509 certificate, or if an IDevID is not 217 available its manufacturer-installed raw public key (RPK). The 218 constrained voucher MUST be signed by the MASA. 220 For the constrained voucher request this document defines two 221 distinct methods for the Pledge to identify the Registrar: using 222 either the Registrar's X.509 certificate, or using a raw public key 223 (RPK) of the Registrar. For the constrained voucher also these two 224 methods are supported to indicate (pin) a trusted domain identity: 225 using either a pinned domain X.509 certificate, or a pinned raw 226 public key (RPK). 228 When the Pledge is known by MASA to support RPK but not X.509 229 certificates, the voucher produced by the MASA pins the raw public 230 key of the Registrar in the "pinned-domain-subject-public-key-info" 231 field of a voucher. This is described in more detail in the YANG 232 definition for the constrained voucher and in section Section 8. 234 When the Pledge is known by MASA to support PKIX format certificates, 235 the "pinned-domain-cert" field present in a voucher typically pins a 236 domain certificate. That can be either the End-Entity certificate of 237 the Registrar, or the certificate of a domain CA of the Registrar's 238 domain. However, if the Pledge is known to also support RPK pinning 239 and the MASA intends to pin the Registrar's identity (not a CA), then 240 MASA MAY pin the RPK of the Registrar instead of the Registrar's End- 241 Entity certificate in order to save space in the voucher. 243 5. Discovery and URI 245 This section describes the BRSKI extensions to EST-coaps 246 [I-D.ietf-ace-coap-est] to transport the voucher between Registrar, 247 join proxy and Pledge over CoAP. The extensions are targeted to low- 248 resource networks with small packets. Saving header space is 249 important and the EST-coaps URI is shorter than the EST URI. 251 The presence and location of (path to) the management data are 252 discovered by sending a GET request to "/.well-known/core" including 253 a resource type (RT) parameter with the value "ace.est" [RFC6690]. 254 Upon success, the return payload will contain the root resource of 255 the EST resources. It is up to the implementation to choose its root 256 resource; throughout this document the example root resource /est is 257 used. 259 The EST-coaps server URIs differ from the EST URI by replacing the 260 scheme https by coaps and by specifying shorter resource path names: 262 coaps://www.example.com/est/short-name 264 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 265 corresponding paths which are supported by EST. Table 1 provides the 266 mapping from the BRSKI extension URI path to the EST-coaps URI path. 268 +-----------------+-----------+ 269 | BRSKI | EST-coaps | 270 +-----------------+-----------+ 271 | /requestvoucher | /rv | 272 | | | 273 | /voucher_status | /vs | 274 | | | 275 | /enrollstatus | /es | 276 +-----------------+-----------+ 278 Table 1: BRSKI path to EST-coaps path 280 /requestvoucher, /voucher_status and /enrollstatus occur between the 281 Pledge and Registrar (the BRSKI-EST protocol) and also between 282 Registrar and MASA, but, as described in Section 7, this document 283 addresses only the BRSKI-EST portion of the protocol. 285 When discovering the root path for the EST resources, the server MAY 286 return the full resource paths and the used content types. This is 287 useful when multiple content types are specified for EST-coaps 288 server. For example, the following more complete response is 289 possible. 291 6. BRSKI-EST Protocol 293 The constrained BRSKI-EST protocol described in this section is 294 between the Pledge and the Registrar only. (probably via a join 295 proxy, such as described in [I-D.ietf-anima-constrained-join-proxy]) 296 It extends both the BRSKI and EST-coaps protocols. 298 6.1. Discovery, URIs and Content Formats 300 The constrained BRSKI-EST protocol described in this section is 301 between the Pledge and the Registrar only. (probably via a join 302 proxy, such as described in [I-D.ietf-anima-constrained-join-proxy]) 303 It extends both the BRSKI and EST-coaps protocols. 305 6.2. Discovery, URIs and Content Formats 307 TBD: content overlaps with Section 5, to be fixed - issue #79 309 The Pledge MAY perform a discovery operation on the "/.well-known/ 310 core?rt=brski*" resource of the Registrar if it wishes to discover 311 possibly shorter URLs for the functions, or if it has the possibility 312 to use a variety of onboarding protocols or certificate enrollment 313 protocols and it wants to discover which of these protocols are 314 available. 316 For example, if the Registrar supports a short BRSKI URL (/b) and 317 supports the voucher format "application/voucher-cose+cbor" (TBD3), 318 and status reporting in both CBOR and JSON formats: 320 REQ: GET /.well-known/core?rt=brski* 322 RES: 2.05 Content 323 Content-Format: 40 324 Payload: 325 ;rt=brski, 326 ;rt=brski.rv;ct=TBD3, 327 ;rt=brski.vs;ct="50 60", 328 ;rt=brski.es;ct="50 60" 330 The Registrar is under no obligation to provide shorter URLs, and MAY 331 respond to this query with only the "/.well-known/brski" end points 332 defined in [I-D.ietf-anima-bootstrapping-keyinfra] section 5. 334 Registrars that have implemented shorter URLs MUST also respond in 335 equivalent ways to the "/.well-known/brski" URLs, and MUST NOT 336 distinguish between them. In particular, a Pledge MAY use the longer 337 and shorter URLs in combination. 339 The return of multiple content-types in the "ct" attribute allows the 340 Pledge to choose the most appropriate one. Note that Content-Format 341 TBD3 is defined in this document. 343 The Content-Format ("application/json") 50 MAY be supported and 60 344 MUST be supported by the Registrar for the /vs and /es resources. 345 Content-Format TBD3 MUST be supported by the Registrar for the /rv 346 resource. If the "ct" attribute is not indicated for this resource, 347 this implies that at least TBD3 is supported. 349 The Pledge and MASA need to support one or more formats (at least 350 TBD3) for the voucher and for the voucher request. The MASA needs to 351 support all formats that the Pledge, produced by that manufacturer, 352 supports. 354 6.3. Extensions to BRSKI 356 A Pledge that only supports the EST-coaps enrollment method SHOULD 357 NOT use discovery for BRSKI resources, since it is more efficient to 358 just try the supported enrollment method via the well-known BRSKI/ 359 EST-coaps resources, and it avoids the Pledge having to do complex 360 CoRE Link Format parsing. A Registrar SHOULD host any discoverable 361 BRSKI resources on the same (UDP) server port that the Pledge's DTLS 362 connection is using. This avoids the Pledge having to reconnect 363 using DTLS, in order to access these resources. 365 6.4. Extensions to EST-coaps 367 A Pledge that only supports the EST-coaps enrollment method SHOULD 368 NOT use discovery for EST-coaps resources, for similar reasons as 369 stated in the previous section. A Registrar SHOULD host any 370 discoverable EST-coaps resources on the same (UDP) server port that 371 the Pledge's DTLS connection is using. This avoids the Pledge having 372 to reconnect using DTLS, in order to access these resources. 374 6.4.1. Pledge Extensions 376 A constrained Pledge SHOULD NOT perform the optional "CSR attributes 377 request" (/att) to minimize network traffic and reduce code size 378 (i.e. by not implementing the complex CSR attributes parsing code). 380 When creating the CSR, the Pledge selects itself which attributes to 381 include. One or more Subject Distinguished Name fields MUST be 382 included. If the Pledge has no specific information on what 383 attributes/fields are desired in the CSR, it MUST use the Subject 384 Distinguished Name fields from its IDevID unmodified. The Pledge may 385 receive such information via the voucher (encoded in a vendor- 386 specific way) or some other, out-of-band means. 388 A constrained Pledge MAY use the following optimized EST-coaps 389 procedure to minimize both network traffic and code size: 391 1. if the BRSKI-received voucher, validating the current EST server, 392 contains a pinned domain CA certificate, the Pledge provisionally 393 considers this single certificate as the sole EST trust anchor, 394 in other words, the single result of "CA certificates request" 395 (/crts) to the EST server. 397 2. Using this trust anchor it proceeds with EST simple enrollment 398 (/sen) to obtain its provisionally trusted LDevID. 400 3. Then, the Pledge attempts to validate that the trust anchor CA is 401 the signer of the LDevID. If this is the case, the Pledge 402 finally accepts the pinned domain CA certificate as the 403 legitimate trust anchor CA for its domain and it also accepts its 404 LDevID. 406 4. If this is not the case, the Pledge MUST perform an actual "CA 407 certificates request" (/crts) to the EST server to obtain the EST 408 CA trust anchors since these obviously differ from the 409 (temporary) pinned domain CA. 411 5. When doing this request, the Pledge MAY use a CoAP Accept Option 412 with value TBD287 ("application/pkix-cert") to limit the number 413 of returned EST CA trust anchors to only one. Such limiting to 414 only one has the advantages that storage requirements for CA 415 certificates are reduced, network traffic can be reduced, and 416 code size can be reduced (by not having to parse the alternative 417 format 281 "application/pkcs7-mime;smime-type=certs-only" and not 418 having to support CoAP block-wise transfer). 420 6. If the Pledge cannot obtain the single CA certificate or the 421 finally validated CA certificate cannot be chained to the LDevID, 422 then the Pledge MUST abort the enrollment process and report the 423 error using the enrollment status telemetry (/es). 425 The Content-Format ("application/json") 50 MAY be supported and 60 426 MUST be supported by the Registrar for the /vs and /es resources. 427 Content-Format TBD3 MUST be supported by the Registrar for the /rv 428 resource. If the "ct" attribute is not indicated for this resource, 429 this implies that at least TBD3 is supported. 431 When a Registrar receives a "CA certificates request" (/crts) request 432 with a CoAP Accept Option with value TBD287 it SHOULD return only the 433 single CA certificate that is the envisioned or actual authority for 434 the current, authenticated Pledge making the request. The only 435 exception case is when the Registrar is configured to not support a 436 request for a single CA certificate for operational or security 437 reasons, e.g. because every device enrolled into the domain needs to 438 use at least multiple CAs. In such exception case the Registrar 439 returns the CoAP response 4.06 Not Acceptable to indicate that only 440 the default Content-Format of 281 "application/pkcs7-mime;smime- 441 type=certs-only" is available. 443 6.4.2. Registrar Extensions 445 When a Registrar receives a "CA certificates request" (/crts) request 446 with a CoAP Accept Option with value TBD287 it SHOULD return only the 447 single CA certificate that is the envisioned or actual authority for 448 the current, authenticated Pledge making the request. The only 449 exception case is when the Registrar is configured to not support a 450 request for a single CA certificate for operational or security 451 reasons, e.g. because every device enrolled into the domain needs to 452 use at least multiple CAs. In such exception case the Registrar 453 returns the CoAP response 4.06 Not Acceptable to indicate that only 454 the default Content-Format of 281 "application/pkcs7-mime;smime- 455 type=certs-only" is available. 457 7. BRSKI-MASA Protocol 459 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 describes a 460 connection between the Registrar and the MASA as being a normal TLS 461 connection using HTTPS. This document does not change that. The use 462 of CoAP for the BRSKI-MASA connection is NOT supported. 464 Some consideration was made to specify CoAP support for consistency 465 but: 467 o the Registrar is not expected to be so constrained that it cannot 468 support HTTPS client connections. 470 o the technology and experience to build Internet-scale HTTPS 471 responders (which the MASA is) is common, while the experience 472 doing the same for CoAP is much less common. 474 o in many Enterprise networks, outgoing UDP connections are often 475 treated as suspicious, and there seems to be no advantage to using 476 CoAP in that environment. 478 o a Registrar is likely to provide onboarding services to both 479 constrained and non-constrained devices. Such a Registrar would 480 need to speak HTTPS anyway. 482 o similarly, a manufacturer is likely to offer both constrained and 483 non-constrained devices, so there may in practice be no situation 484 in which the MASA could be CoAP-only. Additionally, as the MASA 485 is intended to be a function that can easily be oursourced to a 486 third-party service provider, reducing the complexity would also 487 seem to reduce the cost of that function. 489 8. Pinning in Voucher Artifacts 491 The voucher is a statement from the MASA to the Pledge indicating who 492 the Pledge's owner is. This section deals with the question of how 493 that owner's identity is determined and how it is encoded within the 494 voucher. 496 8.1. Registrar Identity Selection and Encoding 498 Section 5.5 of [I-D.ietf-anima-bootstrapping-keyinfra] describes 499 BRSKI policies for selection of the owner identity. It indicates 500 some of the flexibility that is possible for the Registrar. The 501 recommendation made there is for the Registrar to include only 502 certificates in the (CMS) signing structure which participate in the 503 certificate chain that is to be pinned. 505 The MASA is expected to evaluate the certificates included by the 506 Registrar in its voucher request, forming them into a chain with the 507 Registrar's (signing) identity on one end. Then, it pins a 508 certificate selected from the chain. For instance, for a domain with 509 a two-level certification authority, where the voucher-request has 510 been signed by "Registrar" its signing structure includes two 511 additional CA certificates: 513 .-------------. 514 | priv-CA (1) | 515 '-------------' 516 | 517 v 518 .------------. 519 | Int-CA (2) | 520 '------------' 521 | 522 v 523 .--------------. 524 | Registrar(3) | 525 '--------------' 527 Figure 1: Two Level PKI 529 When the Registrar is using a COSE-signed constrained format voucher 530 request towards MASA, instead of a regular CMS-signed voucher 531 request, the COSE_Sign1 object contains a protected and an 532 unprotected header, and according to [I-D.ietf-cose-x509], would 533 carry all the certificates of the chain in an "x5bag" attribute 534 placed in the unprotected header. 536 8.2. MASA Pinning Policy 538 The MASA, having assembled and verified the chain in the signing 539 structure, will now need to select a certificate to pin in the 540 voucher in case there are multiple available. (For the case that 541 only the Registrar's End-Entity certificate is included, only this 542 certificate can be selected and this section does not apply.) The 543 BRSKI policy for pinning by the MASA as described in Section 5.5.2 of 544 [I-D.ietf-anima-bootstrapping-keyinfra] leaves much flexibility to 545 the manufacturer. The present document adds the following rules to 546 the MASA pinning policy, in order to reduce on average the duration 547 of BRSKI/EST on constrained, low-bandwidth networks: 549 1. for a voucher containing a nonce, it SHOULD select the most 550 specific (lowest-level) CA certificate in the chain. 552 2. for a nonceless voucher, it SHOULD select the least-specific 553 (highest-level) CA certificate in the chain that is allowed under 554 the MASA's policy for this specific customer (domain). 556 The rationale for 1. is that in case of a voucher with nonce, the 557 voucher is valid only in scope of the present DTLS connection between 558 Pledge and Registrar anyway, so it would have no benefit to pin a 559 higher-level CA. By pinning the most specific CA the constrained 560 Pledge can validate its DTLS connection using less crypto operations. 562 The rationale for pinning a CA instead of the Registrar's End-Entity 563 certificate directly is the following benefit on constrained 564 networks: the pinned certificate in the voucher can in common cases 565 be re-used as a Domain CA trust anchor during the EST enrollment and 566 during the operational phase that follows after EST enrollment, as 567 explained elsewhere in this document. Doing so avoids an additional 568 transmission of this trust anchor over the network during the EST 569 enrollment, saving potentially 100s of bytes and a CoAP transaction. 571 The rationale for 2. follows from the flexible BRSKI trust model for, 572 and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of 573 [I-D.ietf-anima-bootstrapping-keyinfra]). 575 Using the previous example of a domain with a two-level certification 576 authority, the most specific CA ("Sub-CA") is the identity that is 577 pinned by MASA in a nonced voucher. A Registrar that wished to have 578 only the Registrar's End-Entity certificate pinned would omit the 579 "priv-CA" and "Sub-CA" certificates from the voucher-request. 581 In case of a nonceless voucher, the MASA would depending on trust 582 level pin only "Registrar" certificate (low trust in customer), or 583 the "Sub-CA" certificate (in case of medium trust, implying that any 584 Registrar of that sub-domain is acceptable), or even the "priv-CA" 585 certificate (in case of high trust in the customer, and possibly a 586 pre-agreed need of the customer to obtain flexible long-lived 587 vouchers). 589 8.3. Pinning of Raw Public Keys 591 Specifically for constrained use cases, the pinning of the raw public 592 key (RPK) of the Registrar is also supported in the constrained 593 voucher, instead of an X.509 certificate. If an RPK is pinned it 594 MUST be the RPK of the Registrar. 596 .------------. 597 | pub-CA (1) | 598 '------------' 599 | 600 v 601 .------------. 602 | sub-CA (2) | 603 '------------' 604 | 605 v 606 .--------------. 607 | Registrar(3) | 608 | [RPK3] | 609 '--------------' 611 Figure 2: Raw Public Key pinning 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 the "pinned-domain-subject-public-key-info" field of a 616 voucher. This is described in more detail in the YANG definition for 617 the constrained voucher. A Pledge that does not support X.509 618 certificates cannot use EST to enroll; it has to use another method 619 for 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. However, if the Pledge is known to also support RPK pinning 631 and the MASA intends to pin the Registrar's identity (not a CA), then 632 MASA SHOULD pin the RPK (RPK3 in figure Figure 2) of the Registrar 633 instead of the Registrar's End-Entity certificate in order to save 634 space in the voucher. 636 To Be Completed further (TBD): Note, the above paragraphs are 637 duplicated from the section Section 4 so we may have to resolve this 638 duplication. 640 9. Artifacts 642 This section describes the abstract (tree) definition as explained in 643 [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- 644 level view of the contents of each artifact. 646 Then the assigned SID values are presented. These have been assigned 647 using the rules in [I-D.ietf-core-sid], with an allocation that was 648 made via the http://comi.space service. 650 9.1. Voucher Request artifact 652 9.1.1. Tree Diagram 654 The following diagram is largely a duplicate of the contents of 655 [RFC8366], with the addition of proximity-registrar-subject-public- 656 key-info, proximity-registrar-cert, and prior-signed-voucher-request. 658 prior-signed-voucher-request is only used between the Registrar and 659 the MASA. proximity-registrar-subject-public-key-info replaces 660 proximity-registrar-cert for the extremely constrained cases. 662 module: ietf-constrained-voucher-request 664 grouping voucher-request-constrained-grouping 665 +-- voucher 666 +-- created-on? 667 | yang:date-and-time 668 +-- expires-on? 669 | yang:date-and-time 670 +-- assertion 671 | enumeration 672 +-- serial-number 673 | string 674 +-- idevid-issuer? 675 | binary 676 +-- pinned-domain-cert? 677 | binary 678 +-- domain-cert-revocation-checks? 679 | boolean 680 +-- nonce? 681 | binary 682 +-- last-renewal-date? 683 | yang:date-and-time 684 +-- proximity-registrar-subject-public-key-info? 685 | binary 686 +-- proximity-registrar-sha256-of-subject-public-key-info? 687 | binary 688 +-- proximity-registrar-cert? 689 | binary 690 +-- prior-signed-voucher-request? 691 binary 693 9.1.2. SID values 694 SID Assigned to 695 --------- -------------------------------------------------- 696 2501 data /ietf-constrained-voucher-request:voucher 697 2502 data .../assertion 698 2503 data .../created-on 699 2504 data .../domain-cert-revocation-checks 700 2505 data .../expires-on 701 2506 data .../idevid-issuer 702 2507 data .../last-renewal-date 703 2508 data /ietf-constrained-voucher-request:voucher/nonce 704 2509 data .../pinned-domain-cert 705 2510 data .../prior-signed-voucher-request 706 2511 data .../proximity-registrar-cert 707 2512 data mity-registrar-sha256-of-subject-public-key-info 708 2513 data .../proximity-registrar-subject-public-key-info 709 2514 data .../serial-number 711 WARNING, obsolete definitions 713 9.1.3. YANG Module 715 In the constrained-voucher-request YANG module, the voucher is 716 "augmented" within the "used" grouping statement such that one 717 continuous set of SID values is generated for the constrained- 718 voucher-request module name, all voucher attributes, and the 719 constrained-voucher-request attribute. Two attributes of the voucher 720 are "refined" to be optional. 722 file "ietf-constrained-voucher-request@2019-09-01.yang" 723 module ietf-constrained-voucher-request { 724 yang-version 1.1; 726 namespace 727 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 728 prefix "constrained"; 730 import ietf-restconf { 731 prefix rc; 732 description 733 "This import statement is only present to access 734 the yang-data extension defined in RFC 8040."; 735 reference "RFC 8040: RESTCONF Protocol"; 736 } 738 import ietf-voucher { 739 prefix "v"; 740 } 741 organization 742 "IETF ANIMA Working Group"; 744 contact 745 "WG Web: 746 WG List: 747 Author: Michael Richardson 748 749 Author: Peter van der Stok 750 751 Author: Panos Kampanakis 752 "; 753 description 754 "This module defines the format for a voucher request, 755 which is produced by a pledge to request a voucher. 756 The voucher-request is sent to the potential owner's 757 Registrar, which in turn sends the voucher request to 758 the manufacturer or delegate (MASA). 760 A voucher is then returned to the pledge, binding the 761 pledge to the owner. This is a constrained version of the 762 voucher-request present in 763 draft-ietf-anima-bootstrap-keyinfra.txt. 765 This version provides a very restricted subset appropriate 766 for very constrained devices. 767 In particular, it assumes that nonce-ful operation is 768 always required, that expiration dates are rather weak, as no 769 clocks can be assumed, and that the Registrar is identified 770 by a pinned Raw Public Key. 772 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 773 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 774 and 'OPTIONAL' in the module text are to be interpreted as 775 described in RFC 2119."; 777 revision "2019-09-01" { 778 description 779 "Initial version"; 780 reference 781 "RFC XXXX: Voucher Profile for Constrained Devices"; 782 } 784 rc:yang-data voucher-request-constrained-artifact { 785 // YANG data template for a voucher. 786 uses voucher-request-constrained-grouping; 787 } 788 // Grouping defined for future usage 789 grouping voucher-request-constrained-grouping { 790 description 791 "Grouping to allow reuse/extensions in future work."; 793 uses v:voucher-artifact-grouping { 795 refine voucher/created-on { 796 mandatory false; 797 } 799 refine voucher/pinned-domain-cert { 800 mandatory false; 801 } 803 augment "voucher" { 804 description "Base the constrained voucher-request upon the 805 regular one"; 807 leaf proximity-registrar-subject-public-key-info { 808 type binary; 809 description 810 "The proximity-registrar-subject-public-key-info replaces 811 the proximit-registrar-cert in constrained uses of 812 the voucher-request. 813 The proximity-registrar-subject-public-key-info is the 814 Raw Public Key of the Registrar. This field is encoded 815 as specified in RFC7250, section 3. 816 The ECDSA algorithm MUST be supported. 817 The EdDSA algorithm as specified in 818 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 819 Support for the DSA algorithm is not recommended. 820 Support for the RSA algorithm is MAY, but due to 821 size is discouraged."; 822 } 824 leaf proximity-registrar-sha256-of-subject-public-key-info { 825 type binary; 826 description 827 "The proximity-registrar-sha256-of-subject-public-key-info 828 is an alternative to 829 proximity-registrar-subject-public-key-info. 830 and pinned-domain-cert. In many cases the 831 public key of the domain has already been transmitted 832 during the key agreement protocol, and it is wasteful 833 to transmit the public key another two times. 834 The use of a hash of public key info, at 32-bytes for 835 sha256 is a significant savings compared to an RSA 836 public key, but is only a minor savings compared to 837 a 256-bit ECDSA public-key. 838 Algorithm agility is provided by extensions to this 839 specifications which define new leaf for other hash 840 types."; 841 } 843 leaf proximity-registrar-cert { 844 type binary; 845 description 846 "An X.509 v3 certificate structure as specified by 847 RFC 5280, 848 Section 4 encoded using the ASN.1 distinguished encoding 849 rules (DER), as specified in ITU-T X.690. 851 The first certificate in the Registrar TLS server 852 certificate_list sequence (see [RFC5246]) presented by 853 the Registrar to the Pledge. This MUST be populated in a 854 Pledge's voucher request if the proximity assertion is 855 populated."; 856 } 858 leaf prior-signed-voucher-request { 859 type binary; 860 description 861 "If it is necessary to change a voucher, or re-sign and 862 forward a voucher that was previously provided along a 863 protocol path, then the previously signed voucher 864 SHOULD be included in this field. 866 For example, a pledge might sign a proximity voucher, 867 which an intermediate registrar then re-signs to 868 make its own proximity assertion. This is a simple 869 mechanism for a chain of trusted parties to change a 870 voucher, while maintaining the prior signature 871 information. 873 The pledge MUST ignore all prior voucher information 874 when accepting a voucher for imprinting. Other 875 parties MAY examine the prior signed voucher 876 information for the purposes of policy decisions. 877 For example this information could be useful to a 878 MASA to determine that both pledge and registrar 879 agree on proximity assertions. The MASA SHOULD 880 remove all prior-signed-voucher-request information when 881 signing a voucher for imprinting so as to minimize the 882 final voucher size."; 884 } 885 } 886 } 887 } 888 } 889 891 9.1.4. Example voucher request artifact 893 Below is a CBOR serialization of an example constrained voucher 894 request from a Pledge to a Registrar, shown in CBOR diagnostic 895 notation. The enum value of the assertion field is calculated to be 896 2 by following the algorithm described in section 9.6.4.2 of 897 [RFC7950]. Four dots ("....") in a CBOR byte string denotes a 898 sequence of bytes that are not shown for brevity. 900 { 901 2501: { 902 +2 : "2016-10-07T19:31:42Z", / SID= 2503, created-on / 903 +4 : "2016-10-21T19:31:42Z", / SID= 2505, expires-on / 904 +1 : 2, / SID= 2502, assertion / 905 / "proximity" / 906 +13: "JADA123456789", / SID= 2514, serial-number / 907 +5 : h'01020D0F', / SID= 2506, idevid-issuer / 908 +10: h'cert.der', / SID=2511, proximity-registrar-cert/ 909 +3 : true, / SID= 2504, domain-cert 910 -revocation-checks/ 911 +6 : "2017-10-07T19:31:42Z", / SID= 2507, last-renewal-date / 912 +12: h'key_info' / SID= 2513, proximity-registrar 913 -subject-public-key-info / 914 } 915 } 917 919 9.2. Voucher artifact 921 The voucher's primary purpose is to securely assign a Pledge to an 922 owner. The voucher informs the Pledge which entity it should 923 consider to be its owner. 925 9.2.1. Tree Diagram 927 The following diagram is largely a duplicate of the contents of 928 [RFC8366], with only the addition of pinned-domain-subject-public- 929 key-info. 931 module: ietf-constrained-voucher 933 grouping voucher-constrained-grouping 934 +-- voucher 935 +-- created-on? 936 | yang:date-and-time 937 +-- expires-on? 938 | yang:date-and-time 939 +-- assertion enumeration 940 +-- serial-number string 941 +-- idevid-issuer? binary 942 +-- pinned-domain-cert? binary 943 +-- domain-cert-revocation-checks? boolean 944 +-- nonce? binary 945 +-- last-renewal-date? 946 | yang:date-and-time 947 +-- pinned-domain-subject-public-key-info? binary 948 +-- pinned-sha256-of-subject-public-key-info? binary 949 951 9.2.2. SID values 953 SID Assigned to 954 --------- -------------------------------------------------- 955 2451 data /ietf-constrained-voucher:voucher 956 2452 data /ietf-constrained-voucher:voucher/assertion 957 2453 data /ietf-constrained-voucher:voucher/created-on 958 2454 data .../domain-cert-revocation-checks 959 2455 data /ietf-constrained-voucher:voucher/expires-on 960 2456 data /ietf-constrained-voucher:voucher/idevid-issuer 961 2457 data .../last-renewal-date 962 2458 data /ietf-constrained-voucher:voucher/nonce 963 2459 data .../pinned-domain-cert 964 2460 data .../pinned-domain-subject-public-key-info 965 2461 data .../pinned-sha256-of-subject-public-key-info 966 2462 data /ietf-constrained-voucher:voucher/serial-number 968 WARNING, obsolete definitions 969 971 9.2.3. YANG Module 973 In the constrained-voucher YANG module, the voucher is "augmented" 974 within the "used" grouping statement such that one continuous set of 975 SID values is generated for the constrained-voucher module name, all 976 voucher attributes, and the constrained-voucher attribute. Two 977 attributes of the voucher are "refined" to be optional. 979 file "ietf-constrained-voucher@2019-09-01.yang" 980 module ietf-constrained-voucher { 981 yang-version 1.1; 983 namespace 984 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 985 prefix "constrained"; 987 import ietf-restconf { 988 prefix rc; 989 description 990 "This import statement is only present to access 991 the yang-data extension defined in RFC 8040."; 992 reference "RFC 8040: RESTCONF Protocol"; 993 } 995 import ietf-voucher { 996 prefix "v"; 997 } 999 organization 1000 "IETF ANIMA Working Group"; 1002 contact 1003 "WG Web: 1004 WG List: 1005 Author: Michael Richardson 1006 1007 Author: Peter van der Stok 1008 1009 Author: Panos Kampanakis 1010 "; 1011 description 1012 "This module defines the format for a voucher, which is produced 1013 by a pledge's manufacturer or delegate (MASA) to securely assign 1014 one or more pledges to an 'owner', so that the pledges may 1015 establis a secure connection to the owner's network 1016 infrastructure. 1018 This version provides a very restricted subset appropriate 1019 for very constrained devices. 1020 In particular, it assumes that nonce-ful operation is 1021 always required, that expiration dates are rather weak, as no 1022 clocks can be assumed, and that the Registrar is identified 1023 by a pinned Raw Public Key. 1025 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1026 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1027 and 'OPTIONAL' in the module text are to be interpreted as 1028 described in RFC 2119."; 1030 revision "2019-09-01" { 1031 description 1032 "Initial version"; 1033 reference 1034 "RFC XXXX: Voucher Profile for Constrained Devices"; 1035 } 1037 rc:yang-data voucher-constrained-artifact { 1038 // YANG data template for a voucher. 1039 uses voucher-constrained-grouping; 1040 } 1042 // Grouping defined for future usage 1043 grouping voucher-constrained-grouping { 1044 description 1045 "Grouping to allow reuse/extensions in future work."; 1047 uses v:voucher-artifact-grouping { 1049 refine voucher/created-on { 1050 mandatory false; 1051 } 1053 refine voucher/pinned-domain-cert { 1054 mandatory false; 1055 } 1057 augment "voucher" { 1058 description "Base the constrained voucher 1059 upon the regular one"; 1060 leaf pinned-domain-subject-public-key-info { 1061 type binary; 1062 description 1063 "The pinned-domain-subject-public-key-info replaces the 1064 pinned-domain-cert in constrained uses of 1065 the voucher. The pinned-domain-subject-public-key-info 1066 is the Raw Public Key of the Registrar. 1067 This field is encoded as specified in RFC7250, 1068 section 3. 1069 The ECDSA algorithm MUST be supported. 1070 The EdDSA algorithm as specified in 1071 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1072 Support for the DSA algorithm is not recommended. 1073 Support for the RSA algorithm is a MAY."; 1074 } 1075 leaf pinned-sha256-of-subject-public-key-info { 1076 type binary; 1077 description 1078 "The pinned-hash-subject-public-key-info is a second 1079 alternative to pinned-domain-cert. In many cases the 1080 public key of the domain has already been transmitted 1081 during the key agreement process, and it is wasteful 1082 to transmit the public key another two times. 1083 The use of a hash of public key info, at 32-bytes for 1084 sha256 is a significant savings compared to an RSA 1085 public key, but is only a minor savings compared to 1086 a 256-bit ECDSA public-key. 1087 Algorithm agility is provided by extensions to this 1088 specifications which define new leaf for other hash types"; 1089 } 1090 } 1091 } 1092 } 1093 } 1094 1096 9.2.4. Example voucher artifacts 1098 Below the CBOR serialization of an example constrained voucher is 1099 shown in CBOR diagnostic notation. The enum value of the assertion 1100 field is calculated to be zero by following the algorithm described 1101 in section 9.6.4.2 of [RFC7950]. Four dots ("....") in a CBOR byte 1102 string denotes a sequence of bytes that are not shown for brevity. 1104 { 1105 2451: { 1106 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 1107 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 1108 +1 : 0, / SID = 2452, assertion "verified" / 1109 +11: "JADA123456789", / SID = 2462, serial-number / 1110 +5 : h'E40393B4....68A3', / SID = 2456, idevid-issuer / 1111 +8 : h'30820275....C35F', / SID = 2459, pinned-domain-cert/ 1112 +3 : true, / SID = 2454, domain-cert / 1113 / -revocation-checks / 1114 +6 : "2017-10-07T19:31:42Z" / SID = 2457, last-renewal-date / 1115 } 1116 } 1118 1120 9.3. Signing voucher and voucher-request artifacts with COSE 1122 The COSE-Sign1 structure is discussed in section 4.2 of 1123 [I-D.ietf-cose-rfc8152bis-struct]. The CBOR object that carries the 1124 body, the signature, and the information about the body and signature 1125 is called the COSE_Sign1 structure. It is used when only one 1126 signature is used on the body. Support for ECDSA with sha256 1127 (secp256k1 and prime256v1 curves) is compulsory. 1129 The supported COSE-sign1 object stucture is shown in Figure 3. 1130 Support for EdDSA is encouraged. [EDNOTE: Expand and add a reference 1131 why. ] 1133 COSE_Sign1( 1134 [ 1135 h'A101382E', # { "alg": EC256K1 } 1136 { 1137 "kid" : h'789' # hash256(public key) 1138 }, 1139 h'123', #voucher-request binary content 1140 h'456', #voucher-request binary public signature 1141 ] 1142 ) 1144 Figure 3: cose-sign1 example 1146 The [COSE-registry] specifies the integers that replace the strings 1147 and the mnemonics in Figure 3. The value of the "kid" parameter is 1148 an example value. Usually a hash of the public key is used to 1149 idientify the public key. The public key and its hash are derived 1150 from the relevant certificate (Pledge, Registrar or MASA 1151 certificate). 1153 In Appendix B a binary cose-sign1 object is shown based on the 1154 voucher-request example of Section 9.1.4. 1156 10. Design Considerations 1158 The design considerations for the CBOR encoding of vouchers is much 1159 the same as for [RFC8366]. 1161 One key difference is that the names of the leaves in the YANG does 1162 not have a material effect on the size of the resulting CBOR, as the 1163 SID translation process assigns integers to the names. 1165 Any POST request to the Registrar with resource /est/vs or /est/es 1166 returns a 2.05 response with empty payload. The client should be 1167 aware that the server may use a piggybacked CoAP response (ACK, 2.05) 1168 but may also respond with a separate CoAP response, i.e. first an 1169 (ACK, 0.0) that is an acknowledgement of the request reception 1170 followed by a (CON, 2.05) response in a separate CoAP message. 1172 11. Security Considerations 1174 11.1. Clock Sensitivity 1176 TBD. 1178 11.2. Protect Voucher PKI in HSM 1180 TBD. 1182 11.3. Test Domain Certificate Validity when Signing 1184 TBD. 1186 12. IANA Considerations 1188 12.1. Resource Type Registry 1190 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 1191 parameters" registry are specified below. These can be registered 1192 either in the Expert Review range (0-255) or IETF Review range 1193 (256-9999). 1195 ace.rt.rv needs registration with IANA 1196 ace.rt.vs needs registration with IANA 1197 ace.rt.es needs registration with IANA 1198 ace.rt.ra needs registration with IANA 1200 12.2. The IETF XML Registry 1202 This document registers two URIs in the IETF XML registry [RFC3688]. 1203 Following the format in [RFC3688], the following registration is 1204 requested: 1206 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 1207 Registrant Contact: The ANIMA WG of the IETF. 1208 XML: N/A, the requested URI is an XML namespace. 1210 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 1211 Registrant Contact: The ANIMA WG of the IETF. 1212 XML: N/A, the requested URI is an XML namespace. 1214 12.3. The YANG Module Names Registry 1216 This document registers two YANG modules in the YANG Module Names 1217 registry [RFC6020]. Following the format defined in [RFC6020], the 1218 the following registration is requested: 1220 name: ietf-constrained-voucher 1221 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 1222 prefix: vch 1223 reference: RFC XXXX 1225 name: ietf-constrained-voucher-request 1226 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 1227 -voucher-request 1228 prefix: vch 1229 reference: RFC XXXX 1231 12.4. The RFC SID range assignment sub-registry 1233 ------------ ------ --------------------------- ------------ 1234 Entry-point | Size | Module name | RFC Number 1235 ------------ ------ --------------------------- ------------ 1236 2450 50 ietf-constrained-voucher [ThisRFC] 1237 2500 50 ietf-constrained-voucher [ThisRFC} 1238 -request 1239 ----------- ------ --------------------------- ------------ 1241 Warning: These SID values are defined in [I-D.ietf-core-sid], not as 1242 an Early Allocation. 1244 12.5. Media-Type Registry 1246 This section registers the the 'application/voucher-cose+cbor' in the 1247 "Media Types" registry. These media types are used to indicate that 1248 the content is a CBOR voucher either signed with a COSE_Sign1 1249 structure [I-D.ietf-cose-rfc8152bis-struct]. 1251 12.5.1. application/voucher-cose+cbor 1252 Type name: application 1253 Subtype name: voucher-cose+cbor 1254 Required parameters: none 1255 Optional parameters: cose-type 1256 Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects 1257 signed with one signer. 1258 Security considerations: See Security Considerations, Section 1259 Interoperability considerations: The format is designed to be 1260 broadly interoperable. 1261 Published specification: THIS RFC. 1262 Applications that use this media type: ANIMA, 6tisch, and other 1263 zero-touch imprinting systems 1264 Additional information: 1265 Magic number(s): None 1266 File extension(s): .vch 1267 Macintosh file type code(s): none 1268 Person & email address to contact for further information: IETF 1269 ANIMA WG 1270 Intended usage: LIMITED 1271 Restrictions on usage: NONE 1272 Author: ANIMA WG 1273 Change controller: IETF 1274 Provisional registration? (standards tree only): NO 1276 12.6. CoAP Content-Format Registry 1278 Additions to the sub-registry "CoAP Content-Formats", within the 1279 "CoRE Parameters" registry are needed for two media types. These can 1280 be registered either in the Expert Review range (0-255) or IETF 1281 Review range (256-9999). 1283 Media type mime type Encoding ID References 1284 ---------------------------- ----------- --------- ---- ---------- 1285 application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] 1287 13. Acknowledgements 1289 We are very grateful to Jim Schaad for explaining COSE and CMS 1290 choices. Also thanks to Jim Schaad for correctinging earlier version 1291 of the COSE Sign1 objects. 1293 Michel Veillette did extensive work on pyang to extend it to support 1294 the SID allocation process, and this document was among the first 1295 users. 1297 14. Changelog 1299 -10 Design considerations extended Examples made consistent 1301 -08 Examples for cose_sign1 are completed and improved. 1303 -06 New SID values assigned; regenerated examples 1305 -04 voucher and request-voucher MUST be signed examples for signed 1306 request are added in appendix IANA SID registration is updated SID 1307 values in examples are aligned signed cms examples aligned with new 1308 SIDs 1310 -03 1312 Examples are inverted. 1314 -02 1316 Example of requestvoucher with unsigned appllication/cbor is added 1317 attributes of voucher "refined" to optional 1318 CBOR serialization of vouchers improved 1319 Discovery port numbers are specified 1321 -01 1323 application/json is optional, application/cbor is compulsory 1324 Cms and cose mediatypes are introduced 1326 15. References 1328 15.1. Normative References 1330 [I-D.ietf-6tisch-minimal-security] 1331 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 1332 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 1333 6tisch-minimal-security-15 (work in progress), December 1334 2019. 1336 [I-D.ietf-ace-coap-est] 1337 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 1338 Raza, "EST over secure CoAP (EST-coaps)", draft-ietf-ace- 1339 coap-est-18 (work in progress), January 2020. 1341 [I-D.ietf-anima-bootstrapping-keyinfra] 1342 Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. 1343 H., and K. Watsen, "Bootstrapping Remote Secure Key 1344 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1345 keyinfra-45 (work in progress), November 2020. 1347 [I-D.ietf-core-sid] 1348 Veillette, M., Pelov, A., and I. Petrov, "YANG Schema Item 1349 iDentifier (YANG SID)", draft-ietf-core-sid-15 (work in 1350 progress), January 2021. 1352 [I-D.ietf-core-yang-cbor] 1353 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 1354 Data Modeled with YANG", draft-ietf-core-yang-cbor-15 1355 (work in progress), January 2021. 1357 [I-D.ietf-cose-rfc8152bis-struct] 1358 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1359 Structures and Process", draft-ietf-cose-rfc8152bis- 1360 struct-15 (work in progress), February 2021. 1362 [I-D.ietf-cose-x509] 1363 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1364 Header parameters for carrying and referencing X.509 1365 certificates", draft-ietf-cose-x509-08 (work in progress), 1366 December 2020. 1368 [I-D.selander-ace-ake-authz] 1369 Selander, G., Mattsson, J. P., Vucinic, M., Richardson, 1370 M., and A. Schellenbaum, "Lightweight Authorization for 1371 Authenticated Key Exchange.", draft-selander-ace-ake- 1372 authz-02 (work in progress), November 2020. 1374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1375 Requirement Levels", BCP 14, RFC 2119, 1376 DOI 10.17487/RFC2119, March 1997, 1377 . 1379 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1380 DOI 10.17487/RFC3688, January 2004, 1381 . 1383 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1384 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1385 . 1387 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1388 the Network Configuration Protocol (NETCONF)", RFC 6020, 1389 DOI 10.17487/RFC6020, October 2010, 1390 . 1392 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1393 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1394 October 2013, . 1396 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1397 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1398 . 1400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1402 May 2017, . 1404 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1405 "A Voucher Artifact for Bootstrapping Protocols", 1406 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1407 . 1409 15.2. Informative References 1411 [COSE-registry] 1412 IANA, ., "CBOR Object Signing and Encryption (COSE) 1413 registry", 2017, 1414 . 1416 [I-D.ietf-anima-constrained-join-proxy] 1417 Richardson, M., Stok, P. V. D., and P. Kampanakis, 1418 "Constrained Join Proxy for Bootstrapping Protocols", 1419 draft-ietf-anima-constrained-join-proxy-02 (work in 1420 progress), February 2021. 1422 [I-D.ietf-netmod-yang-tree-diagrams] 1423 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1424 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1425 February 2018. 1427 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1428 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1429 . 1431 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1432 "Enrollment over Secure Transport", RFC 7030, 1433 DOI 10.17487/RFC7030, October 2013, 1434 . 1436 Appendix A. EST messages to EST-coaps 1438 This section extends the examples from Appendix A of 1439 [I-D.ietf-ace-coap-est]. The CoAP headers are only worked out for 1440 the enrollstatus example. 1442 A.1. enrollstatus 1444 A coaps enrollstatus message can be : 1446 POST coaps://192.0.2.1:8085/est/es 1448 The corresponding coap header fields are shown below. 1450 Ver = 1 1451 T = 0 (CON) 1452 Code = 0x02 (0.02 is POST) 1453 Options 1454 Option (Uri-Path) 1455 Option Delta = 0xb (option nr = 11) 1456 Option Length = 0x3 1457 Option Value = "est" 1458 Option (Uri-Path) 1459 Option Delta = 0x0 (option nr = 11) 1460 Option Length = 0x2 1461 Option Value = "es" 1462 Payload = [Empty] 1464 The Uri-Host and Uri-Port Options are omitted because they coincide 1465 with the transport protocol destination address and port 1466 respectively. 1468 A 2.05 Content response with an unsigned voucher status (ct=60) will 1469 then be: 1471 2.05 Content (Content-Format: application/cbor) 1473 With CoAP fields and payload: 1475 Ver=1 1476 T=2 (ACK) 1477 Code = 0x45 (2.05 Content) 1478 Options 1479 Option1 (Content-Format) 1480 Option Delta = 0xC (option nr 12) 1481 Option Length = 0x2 1482 Option Value = 60 (application/cbor) 1484 Payload (CBOR diagnostic) = 1485 { 1486 "version":"1", 1487 "Status": 1, / 1 = Success, 0 = Fail / 1488 "Reason":"Informative human readable message", 1489 "reason-context": "Additional information" 1490 } 1492 The binary payload is: 1494 A46776657273696F6E6131665374617475730166526561736F6E7822 1495 496E666F726D61746976652068756D616E207265616461626C65206D 1496 6573736167656e726561736F6E2D636F6E74657874 1497 764164646974696F6E616C20696E666F726D6174696F6E 1499 The binary payload disassembles to the above CBOR diagnostic code. 1501 A.2. voucher_status 1503 A coaps voucher_status message can be: 1505 POST coaps://[2001:db8::2:1]:61616/est/vs 1507 A 2.05 Content response with a non signed CBOR voucher status (ct=60) 1508 will then be: 1510 2.05 Content (Content-Format: application/cbor) 1511 Payload = 1512 a46776657273696f6e6131665374617475730166526561736f6e7822496e666f7 1513 26d61746976652068756d616e207265616461626c65206d6573736167656e7265 1514 61736f6e2d636f6e74657874764164646974696f6e616c20696e666f726d61746 1515 96f6e 1517 The payload above is represented in hexadecimal. 1519 {"version": "1", "Status": 1, "Reason": "Informative human 1520 readable message", "reason-context": "Additional information"} 1521 Appendix B. COSE examples 1523 These examples are generated on a pie 4 and a PC running BASH. Keys 1524 and Certificates have been generated with openssl with the following 1525 shell script: 1527 #!/bin/bash 1528 #try-cert.sh 1529 export dir=./brski/intermediate 1530 export cadir=./brski 1531 export cnfdir=./conf 1532 export format=pem 1533 export default_crl_days=30 1534 sn=8 1536 DevID=pledge.1.2.3.4 1537 serialNumber="serialNumber=$DevID" 1538 export hwType=1.3.6.1.4.1.6715.10.1 1539 export hwSerialNum=01020304 # Some hex 1540 export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" 1541 echo $hwType - $hwSerialNum 1542 echo $serialNumber 1543 OPENSSL_BIN="openssl" 1545 # remove all files 1546 rm -r ./brski/* 1547 # 1548 # initialize file structure 1549 # root level 1550 cd $cadir 1551 mkdir certs crl csr newcerts private 1552 chmod 700 private 1553 touch index.txt 1554 touch serial 1555 echo 11223344556600 >serial 1556 echo 1000 > crlnumber 1557 # intermediate level 1558 mkdir intermediate 1559 cd intermediate 1560 mkdir certs crl csr newcerts private 1561 chmod 700 private 1562 touch index.txt 1563 echo 11223344556600 >serial 1564 echo 1000 > crlnumber 1565 cd ../.. 1567 # file structure is cleaned start filling 1569 echo "#############################" 1570 echo "create registrar keys and certificates " 1571 echo "#############################" 1573 echo "create root registrar certificate using ecdsa with sha 256 key" 1574 $OPENSSL_BIN ecparam -name prime256v1 -genkey \ 1575 -noout -out $cadir/private/ca-regis.key 1577 $OPENSSL_BIN req -new -x509 \ 1578 -config $cnfdir/openssl-regis.cnf \ 1579 -key $cadir/private/ca-regis.key \ 1580 -out $cadir/certs/ca-regis.crt \ 1581 -extensions v3_ca\ 1582 -days 365 \ 1583 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \ 1584 /CN=registrar.stok.nl" 1586 # Combine authority certificate and key 1587 echo "Combine authority certificate and key" 1588 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1589 -inkey $cadir/private/ca-regis.key \ 1590 -in $cadir/certs/ca-regis.crt -export \ 1591 -out $cadir/certs/ca-regis-comb.pfx 1593 # converteer authority pkcs12 file to pem 1594 echo "converteer authority pkcs12 file to pem" 1595 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1596 -in $cadir/certs/ca-regis-comb.pfx \ 1597 -out $cadir/certs/ca-regis-comb.crt -nodes 1599 #show certificate in registrar combined certificate 1600 $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text 1602 # 1603 # Certificate Authority for MASA 1604 # 1605 echo "#############################" 1606 echo "create MASA keys and certificates " 1607 echo "#############################" 1609 echo "create root MASA certificate using ecdsa with sha 256 key" 1610 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 1611 -out $cadir/private/ca-masa.key 1613 $OPENSSL_BIN req -new -x509 \ 1614 -config $cnfdir/openssl-masa.cnf \ 1615 -days 1000 -key $cadir/private/ca-masa.key \ 1616 -out $cadir/certs/ca-masa.crt \ 1617 -extensions v3_ca\ 1618 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\ 1619 /CN=masa.stok.nl" 1621 # Combine authority certificate and key 1622 echo "Combine authority certificate and key for masa" 1623 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1624 -inkey $cadir/private/ca-masa.key \ 1625 -in $cadir/certs/ca-masa.crt -export \ 1626 -out $cadir/certs/ca-masa-comb.pfx 1628 # converteer authority pkcs12 file to pem for masa 1629 echo "converteer authority pkcs12 file to pem for masa" 1630 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1631 -in $cadir/certs/ca-masa-comb.pfx \ 1632 -out $cadir/certs/ca-masa-comb.crt -nodes 1634 #show certificate in pledge combined certificate 1635 $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text 1637 # 1638 # Certificate for Pledge derived from MASA certificate 1639 # 1640 echo "#############################" 1641 echo "create pledge keys and certificates " 1642 echo "#############################" 1644 # Pledge derived Certificate 1646 echo "create pledge derived certificate using ecdsa with sha 256 key" 1647 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 1648 -out $dir/private/pledge.key 1650 echo "create pledge certificate request" 1651 $OPENSSL_BIN req -nodes -new -sha256 \ 1652 -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ 1653 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ 1654 /CN=uuid:$DevID/$serialNumber" 1656 # Sign pledge derived Certificate 1657 echo "sign pledge derived certificate " 1658 $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \ 1659 -extensions 8021ar_idevid\ 1660 -days 365 -in $dir/csr/pledge.csr \ 1661 -out $dir/certs/pledge.crt 1663 # Add pledge key and pledge certificate to pkcs12 file 1664 echo "Add derived pledge key and derived pledge \ 1665 certificate to pkcs12 file" 1666 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1667 -inkey $dir/private/pledge.key \ 1668 -in $dir/certs/pledge.crt -export \ 1669 -out $dir/certs/pledge-comb.pfx 1671 # converteer pledge pkcs12 file to pem 1672 echo "converteer pledge pkcs12 file to pem" 1673 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 1674 -in $dir/certs/pledge-comb.pfx \ 1675 -out $dir/certs/pledge-comb.crt -nodes 1677 #show certificate in pledge-comb.crt 1678 $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text 1680 #show private key in pledge-comb.crt 1681 $OPENSSL_BIN ecparam -name prime256v1\ 1682 -in $dir/certs/pledge-comb.crt -text 1683 1685 The xxxx-comb certificates have been generated as required by libcoap 1686 for the DTLS connection generation. 1688 B.1. Pledge, Registrar and MASA keys 1690 This first section documents the public and private keys used in the 1691 subsequent test vectors below. These keys come from test code and 1692 are not used in any production system, and should only be used only 1693 to validate implementations. 1695 B.1.1. Pledge private key 1696 Private-Key: (256 bit) 1697 priv: 1698 9b:4d:43:b6:a9:e1:7c:04:93:45:c3:13:d9:b5:f0: 1699 41:a9:6a:9c:45:79:73:b8:62:f1:77:03:3a:fc:c2: 1700 9c:9a 1701 pub: 1702 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 1703 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 1704 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 1705 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 1706 60:eb:95:5c:54 1707 ASN1 OID: prime256v1 1708 NIST CURVE: P-256 1709 1711 B.1.2. Registrar private key 1713 Private-Key: (256 bit) 1714 priv: 1715 81:df:bb:50:a3:45:58:06:b5:56:3b:46:de:f3:e9: 1716 e9:00:ae:98:13:9e:2f:36:68:81:fc:d9:65:24:fb: 1717 21:7e 1718 pub: 1719 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 1720 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 1721 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 1722 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 1723 3e:d0:2d:c7:b7 1724 ASN1 OID: prime256v1 1725 NIST CURVE: P-256 1726 1728 B.1.3. MASA private key 1730 Private-Key: (256 bit) 1731 priv: 1732 c6:bb:a5:8f:b6:d3:c4:75:28:d8:d3:d9:46:c3:31: 1733 83:6d:00:0a:9a:38:ce:22:5c:e9:d9:ea:3b:98:32: 1734 ec:31 1735 pub: 1736 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 1737 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 1738 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 1739 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 1740 ed:f3:17:5c:f1 1741 ASN1 OID: prime256v1 1742 NIST CURVE: P-256 1743 1745 B.2. Pledge, Registrar and MASA certificates 1747 Below the certificates that accompany the keys. The certificate 1748 description is followed by the hexadecimal DER of the certificate 1750 B.2.1. Pledge IDevID certificate 1752 Certificate: 1753 Data: 1754 Version: 3 (0x2) 1755 Serial Number: 4822678189204992 (0x11223344556600) 1756 Signature Algorithm: ecdsa-with-SHA256 1757 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturer, 1758 CN=masa.stok.nl 1759 Validity 1760 Not Before: Dec 9 10:02:36 2020 GMT 1761 Not After : Dec 31 23:59:59 9999 GMT 1762 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturing, 1763 CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4 1764 Subject Public Key Info: 1765 Public Key Algorithm: id-ecPublicKey 1766 Public-Key: (256 bit) 1767 pub: 1768 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 1769 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 1770 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 1771 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 1772 60:eb:95:5c:54 1773 ASN1 OID: prime256v1 1774 NIST CURVE: P-256 1775 X509v3 extensions: 1776 X509v3 Basic Constraints: 1777 CA:FALSE 1778 X509v3 Authority Key Identifier: 1779 keyid: 1780 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 1782 Signature Algorithm: ecdsa-with-SHA256 1783 30:46:02:21:00:d2:e6:45:3b:b0:c3:00:b3:25:8d:f1:83:fe: 1784 d9:37:c1:a2:49:65:69:7f:6b:b9:ef:2c:05:07:06:31:ac:17: 1785 bd:02:21:00:e2:ce:9e:7b:7f:74:50:33:ad:9e:ff:12:4e:e9: 1786 a6:f3:b8:36:65:ab:7d:80:bb:56:88:bc:03:1d:e5:1e:31:6f 1788 1790 This is the hexadecimal representation in (request-)voucher examples 1791 referred to as pledge-cert-hex. 1793 30820226308201cba003020102020711223344556600300a06082a8648ce3d04 1794 0302306f310b3009060355040613024e4c310b300906035504080c024e423110 1795 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 1796 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 1797 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323031323039313030 1798 3233365a180f39393939313233313233353935395a308190310b300906035504 1799 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 1800 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 1801 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 1802 3a706c656467652e312e322e332e34311730150603550405130e706c65646765 1803 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 1804 420004d6b76f7488bd80ae5f28412c7202ef5f98b481e1d9104cf81b66d43e5c 1805 eada73e6a838a9f1351185b6cde20410befed50b3b14692ee1b06abc554060eb 1806 955c54a32e302c30090603551d1304023000301f0603551d23041830168014e4 1807 0393b4c3d3f42a80a47718f6964903011768a3300a06082a8648ce3d04030203 1808 49003046022100d2e6453bb0c300b3258df183fed937c1a24965697f6bb9ef2c 1809 05070631ac17bd022100e2ce9e7b7f745033ad9eff124ee9a6f3b83665ab7d80 1810 bb5688bc031de51e316f 1812 B.2.2. Registrar Certificate 1813 Certificate: 1814 Data: 1815 Version: 3 (0x2) 1816 Serial Number: 1817 70:56:ea:aa:30:66:d8:82:6a:55:5b:90:88:d4:62:bf:9c:f2:8c:fd 1818 Signature Algorithm: ecdsa-with-SHA256 1819 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 1820 CN=registrar.stok.nl 1821 Validity 1822 Not Before: Dec 9 10:02:36 2020 GMT 1823 Not After : Dec 9 10:02:36 2021 GMT 1824 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 1825 CN=registrar.stok.nl 1826 Subject Public Key Info: 1827 Public Key Algorithm: id-ecPublicKey 1828 Public-Key: (256 bit) 1829 pub: 1830 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 1831 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 1832 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 1833 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 1834 3e:d0:2d:c7:b7 1835 ASN1 OID: prime256v1 1836 NIST CURVE: P-256 1837 X509v3 extensions: 1838 X509v3 Subject Key Identifier: 1839 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 1840 X509v3 Authority Key Identifier: 1841 keyid: 1842 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 1844 X509v3 Basic Constraints: critical 1845 CA:TRUE 1846 X509v3 Extended Key Usage: 1847 CMC Registration Authority, TLS Web Server 1848 Authentication, TLS Web Client Authentication 1849 X509v3 Key Usage: critical 1850 Digital Signature, Non Repudiation, Key Encipherment, 1851 Data Encipherment, Certificate Sign, CRL Sign 1852 Signature Algorithm: ecdsa-with-SHA256 1853 30:44:02:20:74:4c:99:00:85:13:b2:f1:bc:fd:f9:02:1a:46: 1854 fb:17:4c:f8:83:a2:7c:a1:d9:3f:ae:ac:f3:1e:4e:dd:12:c6: 1855 02:20:11:47:14:db:f5:1a:5e:78:f5:81:b9:42:1c:6e:47:02: 1856 ab:53:72:70:c5:ba:fb:2d:16:c3:de:9a:a1:82:c3:5f 1858 1859 This the hexadecimal representation, in (request-)voucher examples 1860 referred to as regis-cert-hex 1862 308202753082021ca00302010202147056eaaa3066d8826a555b9088d462bf9c 1863 f28cfd300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 1864 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 1865 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 1866 73756c74616e6379311a301806035504030c117265676973747261722e73746f 1867 6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030 1868 3233365a3073310b3009060355040613024e4c310b300906035504080c024e42 1869 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 1870 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 1871 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 1872 8648ce3d020106082a8648ce3d03010703420004507ac8491a8c69c7b5c31d03 1873 09ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b8934021898d 1874 a789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d 1875 0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d23 1876 04183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d 1877 130101ff040530030101ff30270603551d250420301e06082b0601050507031c 1878 06082b0601050507030106082b06010505070302300e0603551d0f0101ff0404 1879 030201f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 1880 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf51a5e 1881 78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f 1883 B.2.3. MASA Certificate 1885 Certificate: 1886 Data: 1887 Version: 3 (0x2) 1888 Serial Number: 1889 14:26:b8:1c:ce:d8:c3:e8:14:05:cb:87:67:0d:be:ef:d5:81:25:b4 1890 Signature Algorithm: ecdsa-with-SHA256 1891 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 1892 OU=manufacturer, CN=masa.stok.nl 1894 Validity 1895 Not Before: Dec 9 10:02:36 2020 GMT 1896 Not After : Sep 5 10:02:36 2023 GMT 1897 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 1898 OU=manufacturer, CN=masa.stok.nl 1899 Subject Public Key Info: 1900 Public Key Algorithm: id-ecPublicKey 1901 Public-Key: (256 bit) 1902 pub: 1903 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 1904 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 1905 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 1906 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 1908 ed:f3:17:5c:f1 1909 ASN1 OID: prime256v1 1910 NIST CURVE: P-256 1911 X509v3 extensions: 1912 X509v3 Subject Key Identifier: 1913 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 1914 X509v3 Authority Key Identifier: 1915 keyid: 1916 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 1918 X509v3 Basic Constraints: critical 1919 CA:TRUE 1920 X509v3 Extended Key Usage: 1921 CMC Registration Authority, 1922 TLS Web Server Authentication, 1923 TLS Web Client Authentication 1924 X509v3 Key Usage: critical 1925 Digital Signature, Non Repudiation, Key Encipherment, 1926 Data Encipherment, Certificate Sign, CRL Sign 1927 Signature Algorithm: ecdsa-with-SHA256 1928 30:44:02:20:2e:c5:f2:24:72:70:20:ea:6e:74:8b:13:93:67: 1929 8a:e6:fe:fb:8d:56:7f:f5:34:18:a9:ef:a5:0f:c3:99:ca:53: 1930 02:20:3d:dc:91:d0:e9:6a:69:20:01:fb:e4:20:40:de:7c:7d: 1931 98:ed:d8:84:53:61:84:a7:f9:13:06:4c:a9:b2:8f:5c 1933 1935 This is the hexadecimal representation, in (request-)voucher examples 1936 referred to as masa-cert-hex. 1938 3082026d30820214a00302010202141426b81cced8c3e81405cb87670dbeefd5 1939 8125b4300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 1940 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 1941 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 1942 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 1943 301e170d3230313230393130303233365a170d3233303930353130303233365a 1944 306f310b3009060355040613024e4c310b300906035504080c024e423110300e 1945 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 1946 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 1947 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 1948 2a8648ce3d0301070342000459809466149420303c6608855586dbe7d4d1d77a 1949 d2a31a0c736b010d021215d61ff36ec8d48460433b21c583801efce237857797 1950 94d4aa34b5b6c6edf3175cf1a3818d30818a301d0603551d0e04160414e40393 1951 b4c3d3f42a80a47718f6964903011768a3301f0603551d23041830168014e403 1952 93b4c3d3f42a80a47718f6964903011768a3300f0603551d130101ff04053003 1953 0101ff30270603551d250420301e06082b0601050507031c06082b0601050507 1954 030106082b06010505070302300e0603551d0f0101ff0404030201f6300a0608 1955 2a8648ce3d040302034700304402202ec5f224727020ea6e748b1393678ae6fe 1956 fb8d567ff53418a9efa50fc399ca5302203ddc91d0e96a692001fbe42040de7c 1957 7d98edd884536184a7f913064ca9b28f5c 1959 B.3. COSE signed voucher request from Pledge to Registrar 1961 In this example the voucher request has been signed by the Pledge, 1962 and has been sent to the JRC over CoAPS. The Pledge uses the 1963 proximity assertion together with an included proximity-registrar- 1964 cert field to inform MASA about its proximity to the specific 1965 Registrar. 1967 POST coaps://registrar.example.com/est/rv 1968 (Content-Format: application/voucher-cose+cbor) 1969 signed_request_voucher 1971 The payload signed_request_voucher is shown as hexadecimal dump (with 1972 lf added): 1974 d28444a101382ea104582097113db094eee8eae48683e7337875c0372164be89d023a5f3d 1975 f52699c0fbfb55902d2a11909c5a60274323032302d31322d32335431323a30353a32325a 1976 0474323032322d31322d32335431323a30353a32325a01020750684ca83e27230aff97630 1977 cf2c1ec409a0d6e706c656467652e312e322e332e340a590279308202753082021ca00302 1978 010202147056eaaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d0403023 1979 073310b3009060355040613024e4c310b300906035504080c024e423110300e0603550407 1980 0c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b3114301206035 1981 5040b0c0b636f6e73756c74616e6379311a301806035504030c117265676973747261722e 1982 73746f6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030323 1983 3365a3073310b3009060355040613024e4c310b300906035504080c024e423110300e0603 1984 5504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273746f6b3114301 1985 2060355040b0c0b636f6e73756c74616e6379311a301806035504030c1172656769737472 1986 61722e73746f6b2e6e6c3059301306072a8648ce3d020106082a8648ce3d0301070342000 1987 4507ac8491a8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb9 1988 4e02b8934021898da789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0 1989 603551d0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d2304 1990 183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff040 1991 530030101ff30270603551d250420301e06082b0601050507031c06082b06010505070301 1992 06082b06010505070302300e0603551d0f0101ff0404030201f6300a06082a8648ce3d040 1993 30203470030440220744c99008513b2f1bcfdf9021a46fb174cf883a27ca1d93faeacf31e 1994 4edd12c60220114714dbf51a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c 1995 35f58473045022063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3336b 1996 8f56e1022100cd0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f299148 1997 4e9 1998 2000 The representiation of signed_voucher_request in CBOR diagnostic 2001 format is: 2003 Diagnose(signed_request_voucher) = 2004 18([ 2005 h'A101382E', # {"alg": -47} 2006 {4: h'97113DB094EEE8EAE48683E7337875C0372164BE89D023A5F3DF52699C0FBFB5'}, 2007 h'request_voucher', 2008 h'3045022063766C7BBD1B339DBC398E764AF3563E93B25A69104BEFE9AAC2B3336B8F56E 2009 1022100CD0419559AD960CCAED4DEE3F436ECA40B7570B25A52EB60332BC1F2991484E9' 2010 ]) 2012 Diagnose(request_voucher) = 2013 {2501: {2: "2020-12-23T12:05:22Z", 2014 4: "2022-12-23T12:05:22Z", 2015 1: 2, 2016 7: h'684CA83E27230AFF97630CF2C1EC409A', 2017 13: "pledge.1.2.3.4", 2018 10: h'regis-cert-hex'}} 2019 2020 B.4. COSE signed voucher request from Registrar to MASA 2022 In this example the voucher request has been signed by the JRC using 2023 the private key from Appendix B.1.2. Contained within this voucher 2024 request is the voucher request from the Pledge to JRC. 2026 POST coaps://masa.example.com/est/rv 2027 (Content-Format: application/voucher-cose+cbor) 2028 signed_masa_request_voucher 2030 The payload signed_masa_voucher_request is shown as hexadecimal dump 2031 (with lf added): 2033 d28444a101382ea1045820e8735bc4b470c3aa6a7aa9aa8ee584c09c11131b205efec5d03 2034 13bad84c5cd05590414a11909c5a60274323032302d31322d32385431303a30333a33355a 2035 0474323032322d31322d32385431303a30333a33355a07501551631f6e0416bd162ba53ea 2036 00c2a050d6e706c656467652e312e322e332e3405587131322d32385431303a30333a3335 2037 5a07501551631f6e0416bd162ba53ea00c2a050d6e706c656467652e312e322e332e34055 2038 87131322d32385431303a300000000000000000000000000416bd162ba53ea00c2a050d6e 2039 706c656467652e312e322e332e3405587131322d32385431303a09590349d28444a101382 2040 ea104582097113db094eee8eae48683e7337875c0372164be89d023a5f3df52699c0fbfb5 2041 5902d2a11909c5a60274323032302d31322d32385431303a30333a33355a0474323032322 2042 d31322d32385431303a30333a33355a010207501551631f6e0416bd162ba53ea00c2a050d 2043 6e706c656467652e312e322e332e340a590279308202753082021ca00302010202147056e 2044 aaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d0403023073310b300906 2045 0355040613024e4c310b300906035504080c024e423110300e06035504070c0748656c6d6 2046 f6e6431133011060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f 2047 6e73756c74616e6379311a301806035504030c117265676973747261722e73746f6b2e6e6 2048 c301e170d3230313230393130303233365a170d3231313230393130303233365a3073310b 2049 3009060355040613024e4c310b300906035504080c024e423110300e06035504070c07486 2050 56c6d6f6e6431133011060355040a0c0a76616e64657273746f6b31143012060355040b0c 2051 0b636f6e73756c74616e6379311a301806035504030c117265676973747261722e73746f6 2052 b2e6e6c3059301306072a8648ce3d020106082a8648ce3d03010703420004507ac8491a8c 2053 69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b89340218 2054 98da789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d0e0416 2055 041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d2304183016801408c 2056 2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff040530030101ff30 2057 270603551d250420301e06082b0601050507031c06082b0601050507030106082b0601050 2058 5070302300e0603551d0f0101ff0404030201f6300a06082a8648ce3d0403020347003044 2059 0220744c99008513b2f1bcfdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c602201 2060 14714dbf51a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f5847304502 2061 2063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3336b8f56e1022100c 2062 d0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f2991484e95847304502 2063 2100e6b45558c1b806bba23f4ac626c9bdb6fd354ef4330d8dfb7c529f29cca934c802203 2064 c1f2ccbbac89733d17ee7775bc2654c5f1cc96afba2741cc31532444aa8fed8 2066 2067 The representiation of signed_masa_voucher_request in CBOR diagnostic 2068 format is: 2070 Diagnose(signed_registrar_request-voucher) 2071 18([ 2072 h'A101382E', # {"alg": -47} 2073 h'E8735BC4B470C3AA6A7AA9AA8EE584C09C11131B205EFEC5D0313BAD84C5CD0 2074 5'}, 2075 h'registrar_request_voucher', 2076 h'3045022100E6B45558C1B806BBA23F4AC626C9BDB6FD354EF4330D8DFB7C529 2077 F29CCA934C802203C1F2CCBBAC89733D17EE7775BC2654C5F1CC96AFBA2741CC3 2078 1532444AA8FED8' 2079 ]) 2081 Diagnose(registrar_request_voucher) 2082 {2501: 2083 {2: "2020-12-28T10:03:35Z", 2084 4: "2022-12-28T10:03:35Z", 2085 7: h'1551631F6E0416BD162BA53EA00C2A05', 2086 13: "pledge.1.2.3.4", 2087 5: h'31322D32385431303A30333A33355A07501551631F6E0416BD162BA53EA00C2 2088 A050D6E706C656467652E312E322E332E3405587131322D32385431303A300000 2089 000000000000000000000416BD162BA53EA00C2A050D6E706C656467652E312E3 2090 22E332E3405587131322D32385431303A', 2091 9: h'signed_request_voucher'}} 2092 2094 B.5. COSE signed voucher from MASA to Pledge via Registrar 2096 The resulting voucher is created by the MASA and returned via the JRC 2097 to the Pledge. It is signed by the MASA's private key Appendix B.1.3 2098 and can be verified by the Pledge using the MASA's public key 2099 contained within the MASA certificate. 2101 This is the raw binary signed_voucher, encoded in hexadecimal (with 2102 lf added): 2104 d28444a101382ea104582039920a34ee92d3148ab3a729f58611193270c9029f7784daf11 2105 2614b19445d5158cfa1190993a70274323032302d31322d32335431353a30333a31325a04 2106 74323032302d31322d32335431353a32333a31325a010007506508e06b2959d5089d7a316 2107 9ea889a490b6e706c656467652e312e322e332e340858753073310b300906035504061302 2108 4e4c310b300906035504080c024e423110300e06035504070c0748656c6d6f6e643113301 2109 1060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e73756c7461 2110 6e6379311a301806035504030c117265676973747261722e73746f6b2e6e6c03f45847304 2111 5022022515d96cd12224ee5d3ac673237163bba24ad84815699285d9618f463ee73fa0221 2112 00a6bff9d8585c1c9256371ece94da3d26264a5dfec0a354fe7b3aef58344c512f 2114 2115 The representiation of signed_voucher in CBOR diagnostic format is: 2117 Diagnose(signed_voucher) = 2118 18([ 2119 h'A101382E', # {"alg": -47} 2120 {4: h'39920A34EE92D3148AB3A729F58611193270C9029F7784DAF112614B194 2121 45D51'}, 2122 h'voucher', 2123 h'3045022022515D96CD12224EE5D3AC673237163BBA24AD84815699285D9618F 2124 463EE73FA022100A6BFF9D8585C1C9256371ECE94DA3D26264A5DFEC0A354FE7B 2125 3AEF58344C512F' 2126 ]) 2128 Diagnose(voucher) = 2129 {2451: 2130 {2: "2020-12-23T15:03:12Z", 2131 4: "2020-12-23T15:23:12Z", 2132 1: 0, 2133 7: h'6508E06B2959D5089D7A3169EA889A49', 2134 11: "pledge.1.2.3.4", 2135 8: h'regis-cert-hex', 2136 3: false}} 2137 2139 Authors' Addresses 2141 Michael Richardson 2142 Sandelman Software Works 2144 Email: mcr+ietf@sandelman.ca 2146 Peter van der Stok 2147 vanderstok consultancy 2149 Email: consultancy@vanderstok.org 2151 Panos Kampanakis 2152 Cisco Systems 2154 Email: pkampana@cisco.com 2155 Esko Dijk 2156 IoTconsultancy.nl 2158 Email: esko.dijk@iotconsultancy.nl