idnits 2.17.00 (12 Aug 2021) /tmp/idnits49573/draft-ietf-anima-constrained-voucher-14.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 27 characters 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. -- The draft header indicates that this document updates RFC8366, but the abstract doesn't seem to directly say this. It does mention RFC8366 though, so this could be OK. -- The draft header indicates that this document updates RFC8995, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1285 has weird spacing: '...ndatory false...' == Line 1289 has weird spacing: '...ndatory false...' == Line 1547 has weird spacing: '...ndatory false...' == Line 1551 has weird spacing: '...ndatory false...' == Line 1904 has weird spacing: '... brski nee...' -- The document date (25 October 2021) is 208 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BRSKI' is mentioned on line 22, but not defined == Missing Reference: 'ThisRFC' is mentioned on line 1945, but not defined == Missing Reference: 'This RFC' is mentioned on line 2002, but not defined == Outdated reference: draft-ietf-ace-coap-est has been published as RFC 9148 == Outdated reference: A later version (-18) exists of draft-ietf-core-sid-16 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-16 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-04 ** 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' == Outdated reference: A later version (-10) exists of draft-ietf-anima-constrained-join-proxy-05 == Outdated reference: A later version (-14) exists of draft-ietf-lake-edhoc-12 == Outdated reference: A later version (-06) exists of draft-richardson-anima-masa-considerations-05 Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 6 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 Updates: 8366, 8995 (if approved) P. van der Stok 5 Intended status: Standards Track vanderstok consultancy 6 Expires: 28 April 2022 P. Kampanakis 7 Cisco Systems 8 E. Dijk 9 IoTconsultancy.nl 10 25 October 2021 12 Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) 13 draft-ietf-anima-constrained-voucher-14 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 28 April 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 66 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 6 67 5. Updates to RFC8366 and RFC8995 . . . . . . . . . . . . . . . 7 68 6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Registrar and the Server Name Indicator (SNI) . . . . . . 8 70 6.2. TLS Client Certificates: IDevID authentication . . . . . 9 71 6.3. Discovery, URIs and Content Formats . . . . . . . . . . . 9 72 6.3.1. RFC8995 Telemetry Returns . . . . . . . . . . . . . . 12 73 6.4. Join Proxy options . . . . . . . . . . . . . . . . . . . 12 74 6.5. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 12 75 6.5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 12 76 6.5.2. CoAP responses . . . . . . . . . . . . . . . . . . . 13 77 6.6. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 13 78 6.6.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 14 79 6.6.2. EST-client Extensions . . . . . . . . . . . . . . . . 15 80 6.6.3. Registrar Extensions . . . . . . . . . . . . . . . . 17 81 6.7. DTLS handshake fragmentation Considerations . . . . . . . 18 82 7. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 18 83 7.1. Protocol and Formats . . . . . . . . . . . . . . . . . . 18 84 7.2. Registrar Voucher Request . . . . . . . . . . . . . . . . 19 85 7.3. MASA and the Server Name Indicator (SNI) . . . . . . . . 19 86 7.3.1. Registrar Certificate Requirement . . . . . . . . . . 20 87 8. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 20 88 8.1. Registrar Identity Selection and Encoding . . . . . . . . 20 89 8.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 22 90 8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 23 91 8.4. Considerations for use of IDevID-Issuer . . . . . . . . . 24 92 9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 25 94 9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 25 95 9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 26 96 9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 27 97 9.1.4. Example voucher request artifact . . . . . . . . . . 31 98 9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 32 99 9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32 100 9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 32 101 9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 33 102 9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 36 103 9.3. Signing voucher and voucher-request artifacts with 104 COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 37 105 10. Deployment specific Discovery Considerations . . . . . . . . 38 106 10.1. 6TSCH Deployments . . . . . . . . . . . . . . . . . . . 39 107 10.2. Generic networks using GRASP . . . . . . . . . . . . . . 39 108 10.3. Generic networks using mDNS . . . . . . . . . . . . . . 39 109 10.4. Thread networks using Mesh Link Establishment (MLE) . . 39 110 10.5. Non-mesh networks using CoAP Discovery . . . . . . . . . 39 111 11. Design Considerations . . . . . . . . . . . . . . . . . . . . 39 112 12. Raw Public Key Use Considerations . . . . . . . . . . . . . . 40 113 12.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 40 114 12.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 40 115 12.3. The Voucher Response . . . . . . . . . . . . . . . . . . 40 116 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 117 13.1. Duplicate serial-numbers . . . . . . . . . . . . . . . . 41 118 13.2. IDevID security in Pledge . . . . . . . . . . . . . . . 42 119 13.3. Security of CoAP and UDP protocols . . . . . . . . . . . 42 120 13.4. Registrar Certificate may be self-signed . . . . . . . . 42 121 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 122 14.1. Resource Type Registry . . . . . . . . . . . . . . . . . 42 123 14.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 43 124 14.3. The YANG Module Names Registry . . . . . . . . . . . . . 43 125 14.4. The RFC SID range assignment sub-registry . . . . . . . 43 126 14.5. Media Types Registry . . . . . . . . . . . . . . . . . . 44 127 14.5.1. application/voucher-cose+cbor . . . . . . . . . . . 44 128 14.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 44 129 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 130 16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 45 131 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 132 17.1. Normative References . . . . . . . . . . . . . . . . . . 45 133 17.2. Informative References . . . . . . . . . . . . . . . . . 49 134 Appendix A. Library support for BRSKI . . . . . . . . . . . . . 51 135 A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 51 136 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 52 137 A.3. wolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . 53 138 Appendix B. Constrained BRSKI-EST messages . . . . . . . . . . . 53 139 B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 53 140 B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 54 141 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 54 142 C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 58 143 C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 58 144 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 58 145 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 59 146 C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 59 147 C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 59 148 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 61 149 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 63 150 C.3. COSE signed voucher request from Pledge to Registrar . . 65 151 C.4. COSE signed voucher request from Registrar to MASA . . . 67 152 C.5. COSE signed voucher from MASA to Pledge via Registrar . . 69 153 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 70 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 156 1. Introduction 158 Secure enrollment of new nodes into constrained networks with 159 constrained nodes presents unique challenges. As explained in 160 [RFC7228], the networks are challenged and the nodes are constrained 161 by energy, memory space, and code size. 163 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 164 described in [RFC8995] provides a solution for secure zero-touch 165 (automated) bootstrap of new (unconfigured) devices. In it, new 166 devices, such as IoT devices, are called "pledges", and equipped with 167 a factory-installed Initial Device Identifier (IDevID) (see 168 [ieee802-1AR]), they are enrolled into a network. 170 The BRSKI solution described in [RFC8995] was designed to be modular, 171 and this document describes a version scaled to the constraints of 172 IoT deployments. 174 Therefore, this document defines a constrained version of the voucher 175 artifact (described in [RFC8366]), along with a constrained version 176 of BRSKI. This constrained-BRSKI protocol makes use of the 177 constrained CoAP-based version of EST (EST-coaps from 178 [I-D.ietf-ace-coap-est]) rather than the EST over HTTPS [RFC7030]. 180 In BRSKI, the the [RFC8366] voucher is by default serialized to JSON 181 with a signature in CMS [RFC5652]. This document defines a new 182 voucher serialization to CBOR [RFC8949] with a signature in COSE 183 [I-D.ietf-cose-rfc8152bis-struct]. 185 This COSE-signed CBOR-encoded voucher is transported using secured 186 CoAP and HTTPS. 188 The CoAP connection (between Pledge and Registrar) is to be protected 189 by either OSCORE+EDHOC [I-D.ietf-lake-edhoc] or DTLS (CoAPS). The 190 HTTP connection (between Registrar and MASA) is to be protected using 191 TLS (HTTPS). 193 This document specifies a constrained voucher-request artifact based 194 on Section 3 of [RFC8995], and voucher(-request) transport over CoAP 195 based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est]. 197 The CBOR definitions for the constrained voucher format are defined 198 using the mechanism described in [I-D.ietf-core-yang-cbor] using the 199 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 200 convert YANG documents into a list of SID keys is still in its 201 infancy, the table of SID values presented here MUST be considered 202 normative rather than the output of the pyang tool. 204 There is additional work when the voucher is integrated into the key- 205 exchange, described in [I-D.selander-ace-ake-authz]. This work is 206 not in scope for this document. 208 2. Terminology 210 The following terms are defined in [RFC8366], and are used 211 identically as in that document: artifact, domain, imprint, Join 212 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 213 Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and 214 Voucher. 216 The following terms from [RFC8995] are used identically as in that 217 document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, 218 manufacturer, nonced, nonceless, PKIX. 220 The term Pledge Voucher Request, or acronym PVR, is introduced to 221 refer to the voucher request between the pledge and the Registrar. 223 The term Registrar Voucher Request, or acronym RVR, is introduced to 224 refer to the voucher request between the Registrar and the MASA. 226 3. Requirements Language 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 230 "OPTIONAL" in this document are to be interpreted as described in 231 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 232 capitals, as shown here. 234 4. Overview of Protocol 236 [RFC8366] provides for vouchers that assert proximity, that 237 authenticate the Registrar and that can offer varying levels of anti- 238 replay protection. 240 The proximity proof provided for in [RFC8366], is an assertion that 241 the Pledge and the Registrar are believed to be in close together, 242 from a network topology point of view. Like in [RFC8995], proximity 243 shown by making TLS connections between the Pledge and Registrar 244 using IPv6 Link-Local addresses. 246 The TLS connection is used to make a Voucher Request. This request 247 is verified by the an agent of the Pledge's manufacturer, which then 248 issues a voucher. The voucher provides an authorization statement 249 from the manufacturer indicating that the Registrar is the intended 250 owner of the device. The voucher refers to the Registrar through 251 pinning of the Registrar's identity. 253 This document does not make any extensions to the semantic meaning of 254 vouchers, only the encoding has been changed to optimize for 255 constrained devices and networks. The two main parts of the BRSKI 256 protocol are named separately in this document: BRSKI-EST for the 257 protocol between Pledge and Registrar, and BRSKI-MASA for the 258 protocol between the Registrar and the MASA. 260 Time-based vouchers are supported in this definition, but given that 261 constrained devices are extremely unlikely to have accurate time, 262 their use will be uncommon. Most Pledges using constrained vouchers 263 will be online during enrollment and will use live nonces to provide 264 anti-replay protection rather than expiry times. 266 [RFC8366] defines the voucher artifact, while the Voucher Request 267 artifact was defined in [RFC8995]. This document defines both a 268 constrained voucher and a constrained voucher-request. They are 269 presented in the order "voucher-request", followed by a "voucher" 270 response as this is the order that they occur in the protocol. 272 The constrained voucher request MUST be signed by the Pledge. It 273 signs using the private key associated with its IDevID X.509 274 certificate, or if an IDevID is not available, then the private key 275 associated with its manufacturer-installed raw public key (RPK). 276 Section 12 provides additional details on PKIX-less operations. 278 The constrained voucher MUST be signed by the MASA. 280 For the constrained voucher request this document defines two 281 distinct methods for the Pledge to identify the Registrar: using 282 either the Registrar's X.509 certificate, or using a raw public key 283 (RPK) of the Registrar. 285 For the constrained voucher also these two methods are supported to 286 indicate (pin) a trusted domain identity: using either a pinned 287 domain X.509 certificate, or a pinned raw public key (RPK). 289 The BRSKI architectures mandates that the MASA be aware of the 290 capabilities of the pledge. This is not a hardship as the pledges 291 are constructed by a manufacturer who also arranges for the MASA to 292 be aware of the inventory of devices. 294 The MASA therefore knows if the pledge supports PKIX operations, PKIX 295 format certificates, or if the pledge is limited to Raw Public Keys 296 (RPK). Based upon this, the MASA can select which attributes to use 297 in the voucher for certain operations, like the pinning of the 298 Registrar identity. This is described in more detail in 299 Section 9.2.3, Section 8 and Section 8.3 (for RPK specifically). 301 5. Updates to RFC8366 and RFC8995 303 This section details the ways in which this document Updates. The 304 terminology for Updates is taken from [I-D.kuehlewind-update-tag]. 306 This document Updates [RFC8366]. It Extends [RFC8366] by creating a 307 new serialization format. 309 This document Updates [RFC8995]. It Amends [RFC8995] by clarifying 310 how pinning is done, and ???. 312 6. BRSKI-EST Protocol 314 This section describes the constrained BRSKI extensions to EST-coaps 315 [I-D.ietf-ace-coap-est] to transport the voucher between Registrar 316 and Pledge (optionally via a Join Proxy) over CoAP. The extensions 317 are targeting low-resource networks with small packets. 319 The constrained BRSKI-EST protocol described in this section is 320 between the Pledge and the Registrar only. 322 6.1. Registrar and the Server Name Indicator (SNI) 324 A DTLS connection is established between the pledge and the 325 Registrar. As described in Section 5.1 of [RFC8995] the pledge 326 establishes a TLS connection to the Registrar. This occurs via a 327 variety of Join Proxy mechanisms described in Section 6.4. 328 Regardless of the mechanism, the DTLS connection should operate 329 identically. 331 This issue affects [RFC8995] as well, and is reported in errata: 332 https://www.rfc-editor.org/errata/eid6648 334 As the Registrar is discovered by IP address, and connected via the 335 Join proxy, the name of the Registrar is not known to the Pledge. 336 The Pledge will not know what the hostname for the Registrar is, so 337 the pledge can not do RFC6125 DNS-ID validation on the Registrar's 338 certificate. That is the purpose of the RFC8366 voucher. 340 As the Pledge does not know the name of the Registrar, the Pledge 341 cannot put any reasonable value into the [RFC6066] Server Name 342 Indicator (SNI). The pledge SHOULD omit the SNI extension as per 343 Section 9.2 of [RFC8446]. 345 In some cases, particularly when debugging and doing interoperability 346 testing, a Pledge may be given the hostname of a particular Registrar 347 to connect to. Such a bypass of the discovery process may result in 348 the Pledge taking a different path to DTLS connection, and may result 349 in the SNI being inserted by a library. The Registrar MUST ignore 350 any SNI seen. 352 A primary motivation for making the SNI ubiquitous in the public web 353 is because it allows for multi-tenant hosting of HTTPS sites on a 354 single (scarce) IPv4 address. This consideration does not apply to 355 the Registrar because: 357 * it uses DTLS and CoAP, not HTTPS 359 * it uses IPv6, often [RFC4193] Unique Local Address, which are 360 plentiful 362 * the port number number is discovered, so multiple tenants can be 363 accomodate via unique port numbers. 365 As per Section 3.6.1 of [RFC7030], the Registrar certificate MUST 366 have the Extended Key Usage (EKU) id-kp-cmcRA. This certificate is 367 also used as a TLS Server Certificate, so it must also have the EKU 368 id-kp-serverAuth. 370 6.2. TLS Client Certificates: IDevID authentication 372 As described in Section 5.1 of [RFC8995], the Pledge makes a 373 connection to the Registrar using TLS Client Certificate for 374 authentication. 376 Subsequently the pledge will send a Pledge Voucher Request (PVR). 378 As explained below in Section 8.1, the "x5bag" may be used in the RVR 379 to communicate identity of the Registrar to MASA. The Pledge SHOULD 380 NOT use the x5bag attribute in this way in the PVR. A Registrar that 381 processes a PVR with an x5bag attribute MUST ignore it, and MUST use 382 only the TLS Client Certificate extension for authentication of the 383 Pledge. 385 A situation where the pledge MAY use the x5bag is for communications 386 of certificate chains to the MASA. This would arise in some vendor 387 specific situations involving outsourcing of MASA functionality, or 388 rekey of IDevID certification authority. 390 6.3. Discovery, URIs and Content Formats 392 To keep the protocol messages small the EST-coaps and constrained- 393 BRSKI URIs are shorter than the respective EST and BRSKI URIs. 395 The EST-coaps server URIs differ from the EST URIs by replacing the 396 scheme https by coaps and by specifying shorter resource path names. 397 Below are some examples; the first two using a discovered short path 398 name and the last one using the well-known URI of EST which requires 399 no discovery. 401 coaps://server.example.com/est/ 402 coaps://server.example.com/e/ 403 coaps://server.example.com/.well-known/est/ 405 Similarly the constrained BRSKI server URIs differ from the BRSKI 406 URIs by replacing the scheme https by coaps and by specifying shorter 407 resource path names. Below are some examples; the first two using a 408 discovered short path name and the last one using the well-known URI 409 prefix which requires no discovery. This is the same "/.well-known/ 410 brski" prefix as defined in Section 5 of [RFC8995]. 412 coaps://server.example.com/brski/ 413 coaps://server.example.com/b/ 414 coaps://server.example.com/.well-known/brski/ 416 Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations 417 supported by EST, for which Table 1 in Section 5.1 of 418 [I-D.ietf-ace-coap-est] enumerates the corresponding EST-coaps short 419 path names. Similarly, Table 1 provides the mapping from the 420 supported BRSKI extension URI paths to the constrained-BRSKI URI 421 paths. 423 +=================+============================+ 424 | BRSKI resource | constrained-BRSKI resource | 425 +=================+============================+ 426 | /requestvoucher | /rv | 427 +-----------------+----------------------------+ 428 | /voucher_status | /vs | 429 +-----------------+----------------------------+ 430 | /enrollstatus | /es | 431 +-----------------+----------------------------+ 433 Table 1: BRSKI URI paths mapping to 434 constrained BRSKI URI paths 436 Note that /requestvoucher indicated above occurs between the Pledge 437 and Registrar (in scope of the BRSKI-EST protocol), but it also 438 occurs between Registrar and MASA. However, as described in 439 Section 6, this section and above table addresses only the BRSKI-EST 440 protocol. 442 Pledges that wish to discover the available BRSKI bootstrap options/ 443 formats, or reduce the size of the CoAP headers by eliminating the 444 "/.well-known/brski" path, can do a discovery operation using 445 [RFC6690] Section 4 by sending a discovery query to the Registrar. 447 For example, if the Registrar supports a short BRSKI URL (/b) and 448 supports the voucher format "application/voucher-cose+cbor" (TBD3), 449 and status reporting in both CBOR and JSON formats: 451 REQ: GET /.well-known/core?rt=brski* 453 RES: 2.05 Content 454 Content-Format: 40 455 Payload: 456 ;rt=brski, 457 ;rt=brski.rv;ct=TBD3, 458 ;rt=brski.vs;ct="50 60", 459 ;rt=brski.es;ct="50 60" 461 The Registrar is under no obligation to provide shorter URLs, and MAY 462 respond to this query with only the "/.well-known/brski/" 463 end points for the short names as defined in Table 1. 465 Registrars that have implemented shorter URLs MUST also respond in 466 equivalent ways to the corresponding "/.well-known/brski/" URLs, and MUST NOT distinguish between them. In particular, a 468 Pledge MAY use the longer and shorter URLs in any combination. 470 When responding to a discovery request for BRSKI resources, the 471 server MAY in addition return the full resource paths and the content 472 types which are supported at those end-points as shown in above 473 example. This is useful when multiple content types are specified 474 for a particular resource on the server. The server responds with 475 only the root path for the BRSKI resource (rt=brski, resource /b in 476 above example) and no others in case the client queries for only 477 rt=brski type resources. (So, a query for rt=brski, without the 478 wildcard character.) 480 Without discovery, a longer well-known URL can only be used, such as: 482 REQ: GET /.well-known/brski/rv 484 while with discovery of shorter URLs, a request such as: 486 REQ: GET /b/rv 488 is possible. 490 The return of multiple content-types in the "ct" attribute allows the 491 Pledge to choose the most appropriate one. Note that Content-Format 492 TBD3 ("application/voucher-cose+cbor") is defined in this document. 494 Content-Format TBD3 MUST be supported by the Registrar for the /rv 495 resource. If the "ct" attribute is not indicated for the /rv 496 resource in the link format description, this implies that at least 497 TBD3 is supported. 499 Note that this specification allows for voucher-cose+cbor format 500 requests and vouchers to be transmitted over HTTPS, as well as for 501 voucher-cms+json and other formats yet to be defined over CoAP. The 502 burden for this flexibility is places upon the Registrar. The pledge 503 is expected to support a single format only. 505 The Pledge and MASA need to support one or more formats (at least 506 TBD3) for the voucher and for the voucher request. The MASA needs to 507 support all formats that the Pledge, produced by that manufacturer, 508 supports. 510 Section 10 details how the Pledge discovers the Registrar and Join 511 Proxy in different deployment scenarios. 513 6.3.1. RFC8995 Telemetry Returns 515 [RFC8995] defines two telemetry returns from the Pledge which are 516 sent to the Registrar. These are the BRSKI Status Telemetry 517 [RFC8995], Section 5.7 and the Enrollment Status Telemetry [RFC8995], 518 Section 5.9.4. These are two POST operations made the by Pledge at 519 two key steps in the process. 521 [RFC8995] defines the content of these POST operations in CDDL, which 522 are serialized as JSON. This document extends the list of acceptable 523 formats to CBOR as well as JSON, using the rules from [RFC8610]. 525 The existing JSON format is described as CoAP Content-Format 50 526 ("application/json"), and it MAY be supported. The new CBOR format 527 is described using CoAP Content-Format 60 ("application/cbor") MUST 528 be supported by the Registrar for both the /vs and /es resources. 530 6.4. Join Proxy options 532 TBD; reference other documents. 534 6.5. Extensions to BRSKI 536 6.5.1. Discovery 538 The Pledge discovers an IP address and port number that connects to 539 the Registrar (possibly via a Join Proxy), and it establishes a DTLS 540 connection. 542 No further discovery of hosts or port numbers is required, but a 543 pledge that can do more than one kind of enrollment (future work 544 offers protocols other than [I-D.ietf-ace-coap-est]), then a pledge 545 may need to use CoAP Discovery to determine what other protocols are 546 available. 548 A Pledge that only supports the EST-coaps enrollment method SHOULD 549 NOT use discovery for BRSKI resources. It is more efficient to just 550 try the supported enrollment method via the well-known BRSKI/EST- 551 coaps resources. This also avoids the Pledge doing any CoRE Link 552 Format parsing, which is specified in [I-D.ietf-ace-coap-est], 553 Section 4.1. 555 In order to support this, the Registrar MUST support all of the EST 556 resources at their default ".well-known" locations (on the port 557 number discovered) as well as any server-specific shorter form that 558 might also be supported. 560 However, when discovery is being done by the Pledge, it is possible 561 for the Registrar to return references to resources which are on 562 different port numbers. The Registrar SHOULD NOT use different ports 563 numbers by default, because a Pledge that is connected via a Join 564 Proxy can only access a single UDP port. A Registrar configured to 565 never use Join Proxies MAY be configured to use multiple port 566 numbers. Therefore a Registrar MUST host all discoverable BRSKI 567 resources on the same (UDP) server port that the Pledge's DTLS 568 connection is using. In addition to avoiding the problem of being 569 unable to connect to other ports, using the same UDP server port 570 allows the Pledge to continue to use the same DTLS connection which 571 is more efficient. 573 6.5.2. CoAP responses 575 [RFC8995], Section 5 defines a number of HTTP response codes that the 576 Registrar is to return when certain conditions occur. 578 The 401, 403, 404, 406 and 415 response codes map directly to CoAP 579 codes 4.01, 4.03, 4.04, 4.06 and 4.15. 581 The 202 Retry process which occurs in the voucher request, is to be 582 handled in the same way as Section 5.7 of [I-D.ietf-ace-coap-est] 583 process for Delayed Responses. 585 6.6. Extensions to EST-coaps 587 This document extends [I-D.ietf-ace-coap-est], and it inherits the 588 functions described in that document: specifically, the mandatory 589 Simple (Re-)Enrollment (/sen and /sren) and Certification Authority 590 certificates request (/crts). Support for CSR Attributes Request 591 (/att) and server-side key generation (/skg, /skc) remains optional 592 for the EST server. 594 Collecting both [RFC8995] and [RFC7030], [I-D.ietf-ace-coap-est] and 595 this document results in the following shorter forms of URI paths for 596 the commonly used resources: 598 +------------------+-------------------+----------------+ 599 | EST + BRSKI | Constrained-BRSKI | Well-known URI + 600 | | | namespace + 601 +------------------+-------------------+----------------+ 602 | /requestvoucher | /rv | brski + 603 | /voucher_status | /vs | brski + 604 | /csrattrs | /att | est + 605 | /simpleenroll | /sen | est + 606 | /cacerts | /crts | est + 607 | /enrollstatus | /es | brski + 608 | /simplereenroll | /sren | est + 609 +------------------+-------------------+----------------+ 611 6.6.1. Pledge Extensions 613 This section defines extensions to the BRSKI Pledge, which are 614 applicable during the BRSKI bootstrap procedure. A Pledge that 615 already is DTLS-connected to either a Join Proxy or Registrar, and 616 which only supports the EST-coaps enrollment method, SHOULD NOT use 617 discovery for EST-coaps resources. This is because it is more 618 efficient to just try its supported enrollment method (e.g. /sen) via 619 the well-known EST resource on the current DTLS connection. This 620 avoids an additional round-trip of packets and avoids the Pledge 621 having to unnecessarily implement CoRE Link Format parsing. 623 A constrained Pledge SHOULD NOT perform the optional EST "CSR 624 attributes request" (/att) to minimize network traffic and reduce 625 code size. 627 When creating the CSR, the Pledge selects which attributes to 628 include. One or more Subject Distinguished Name fields MUST be 629 included. If the Pledge has no specific information on what 630 attributes/fields are desired in the CSR, it MUST use the Subject 631 Distinguished Name fields from its IDevID unmodified. The Pledge can 632 receive such information via the voucher (encoded in a vendor- 633 specific way) or some other, out-of-band means. 635 A constrained Pledge MAY use the following optimized EST-coaps 636 procedure to minimize both network traffic and code size: 638 1. if the voucher, that validates the current Registrar, contains a 639 single pinned domain CA certificate, the Pledge provisionally 640 considers this certificate as the EST trust anchor, in other 641 words, it provisionally accepts this CA certificate as if it were 642 the result of "CA certificates request" (/crts) to the Registrar. 644 2. Using this CA certificate as trust anchor it proceeds with EST 645 simple enrollment (/sen) to obtain its provisionally trusted 646 LDevID. 648 3. If the Pledge validates that the trust anchor CA was used to sign 649 its LDevID, the Pledge accepts the pinned domain CA certificate 650 as the legitimate trust anchor CA for the Registrar's domain and 651 accepts the associated LDevID. 653 4. If the trust anchor CA was NOT used to sign its LDevID, the 654 Pledge MUST perform an actual "CA certificates request" (/crts) 655 to the EST server to obtain the EST CA trust anchor(s) since 656 these differ from the (temporary) pinned domain CA. 658 5. When doing this /crts request, the Pledge MAY use a CoAP Accept 659 Option with value TBD287 ("application/pkix-cert") to limit the 660 number of returned EST CA trust anchors to only one. A 661 constrained Pledge MAY support only this format in a /crts 662 response, per Section 5.3 of [I-D.ietf-ace-coap-est]. 664 6. If the Pledge cannot obtain the single CA certificate or the 665 finally validated CA certificate cannot be chained to the LDevID, 666 then the Pledge MUST abort the enrollment process and report the 667 error using the enrollment status telemetry (/es). 669 Note that even though the Pledge may avoid the initial /crts request, 670 it SHOULD support retrieval of the trust anchor CA periodically. A 671 pledge that has an idea of the current time (internally, or via NTP) 672 SHOULD consider the validity time of the trust anchor CA, and MAY 673 begin requesting a new trust anchor CA when the CA has 50% of it's 674 validity time (notAfter - notBefore) left. A pledge that has no idea 675 of the current time will have no idea if the trust anchor CA has 676 expired. Such a device SHOULD poll periodically for a new trust 677 anchor at an interval of approximately 1 month. The Pledge SHOULD 678 use GET-with-ETag, and servers SHOULD support it. 680 6.6.2. EST-client Extensions 682 This section defines extensions to EST-coaps clients, used after the 683 BRSKI bootstrap procedure is completed. (Note that such client is 684 not called "Pledge" in this section, since it is already enrolled 685 into the domain.) A constrained EST-coaps client MAY support only 686 the Content-Format TBD287 ("application/pkix-cert") in a /crts 687 response, per Section 5.3 of [I-D.ietf-ace-coap-est]. 689 In this case, it can only store one trust anchor of the domain. 690 Although this is not an issue in case the domain trust anchor remains 691 stable, special consideration is needed for cases where the domain 692 trust anchor can change over time. Such a change may happen due to 693 relocation of the client device to a new domain, or due to key update 694 of the trust anchor as described in [RFC4210], Section 4.4. 696 The trust anchor change may happen during EST re-enrollment: 697 typically, a change of domain CA requires all devices operating under 698 the old domain CA to acquire a new LDevID issued by the new domain 699 CA. A client's re-enrollment may be triggered by various events, 700 such as imminent expiry of its LDevID. How the re-enrollment is 701 explicitly triggered on the client by a domain entity, such as a 702 commissioner or a Registrar, is out of scope of this specification. 704 The mechanism described in [RFC4210], Section 4.4 for Root CA key 705 update requires four certificates: OldWithOld, OldWithNew, 706 NewWithOld, and NewWithNew. The OldWithOld certificate is already 707 stored in the EST client's trust store. The NewWithNew certificate 708 will be distributed as the single certificate in a /crts response, 709 during EST re-enrollment. Since the EST client can only accept a 710 single certificate in a /crts response it implies that the EST client 711 cannot obtain the certificates OldWithNew and NewWithOld in this way, 712 to perform the complete verification of the new domain CA. Instead, 713 the client only verifies the EST server (Registrar) using its old 714 domain CA certificate in its trust store as detailed below, and based 715 on this trust in the active and valid DTLS connection it 716 automatically trusts the new (NewWithNew) domain CA certificate that 717 the EST server provides in the /crts response. 719 In this manner, even during rollover of trust anchors, it is possible 720 to have only a single trust anchor provided in a /crts response. 722 During the period of the certificate renewal, it is not possible to 723 create new communication channels between devices with NewCA 724 certificates devices with OldCA certificates. One option is that 725 devices should avoid restarting existing DTLS or OSCORE connections 726 during this interval that new certificates are being deployed. The 727 recommended period for certificate renewal is 24 hours. For re- 728 enrollment, the constrained EST-coaps client MUST support the 729 following EST-coaps procedure, where optional re-enrollment to a new 730 domain is under control of the Registrar: 732 1. The client connects with DTLS to the Registrar, and authenticates 733 with its present domain certificate (LDevID) as usual. The 734 Registrar authenticates itself with its domain certificate that 735 is trusted by the client, i.e. it chains to the single trust 736 anchor that the client has stored. This is the "old" trust 737 anchor, the one that will be eventually replaced in case the 738 Registrar decides to re-enroll the client into a new domain. 740 2. The client performs the simple re-enrollment request (/sren) and 741 upon success it obtains a new LDevID. 743 3. The client verifies the new LDevID against its (single) existing 744 domain trust anchor. If it chains successfully, this means the 745 trust anchor did not change and the client MAY skip retrieving 746 the current CA certificate using the "CA certificates request" 747 (/crts). If it does not chain successfully, this means the trust 748 anchor was changed/updated and the client then MUST retrieve the 749 new domain trust anchor using the "CA certificates request" 750 (/crts). 752 4. If the client retrieved a new trust anchor in step 3, then it 753 MUST verify that the new trust anchor chains with the new LDevID 754 it obtained in step 2. If it chains successfully, the client 755 stores both, accepts the new LDevID and stops using it prior 756 LDevID. If it does not chain successfully, the client MUST NOT 757 update its LDevID, it MUST NOT update its (single) domain trust 758 anchor, and the client MUST abort the enrollment process and 759 report the error to the Registrar using enrollment status 760 telemetry (/es). 762 6.6.3. Registrar Extensions 764 A Registrar SHOULD host any discoverable EST-coaps resources on the 765 same (UDP) server port that the Pledge's DTLS initial connection is 766 using. This avoids the Pledge having to reconnect using DTLS, in 767 order to proceed with EST enrollment after the BRSKI bootstrap. [TBD 768 EDNOTE: a Registrar that does host EST resources on another port 769 won't be able to onboard Pledges that skip the discovery, so not 770 interoperable. Should we fix this?] 772 The Content-Format 50 (application/json) MUST be supported and 60 773 (application/cbor) MUST be supported by the Registrar for the /vs and 774 /es resources. 776 Content-Format TBD3 MUST be supported by the Registrar for the /rv 777 resource. 779 When a Registrar receives a "CA certificates request" (/crts) request 780 with a CoAP Accept Option with value TBD287 ("application/pkix-cert") 781 it SHOULD return only the single CA certificate that is the 782 envisioned or actual authority for the current, authenticated Pledge 783 making the request. 785 If the Pledge included in its request an Accept Option for only the 786 TBD287 ("application/pkix-cert") Content Format, but the domain has 787 been configured to operate with multiple CA trust anchors only, then 788 the Registrar returns a 4.06 Not Acceptable error to signal that the 789 Pledge needs to use the Content Format 281 ("application/pkcs7-mime; 790 smime-type=certs-only") to retrieve all the certificates. 792 If the current authenticated client is an EST-coaps client that was 793 already enrolled in the domain, and the Registrar is configured to 794 assign this client to a new domain CA trust anchor during the next 795 EST re-enrollment procedure, then the Registrar MUST respond with the 796 new domain CA certificate in case the client performs the "CA 797 Certificates request" (/crts) with an Accept Option for TBD287 only. 798 This signals the client that a new domain is assigned to it. The 799 client follows the procedure as defined in Section 6.6.2. 801 6.7. DTLS handshake fragmentation Considerations 803 DTLS includes a mechanism to fragment the handshake messages. This 804 is described in Section 4.4 of [I-D.ietf-tls-dtls13]. The protocol 805 described in this document will often be used with a Join Proxy 806 described in [I-D.ietf-anima-constrained-join-proxy]. The Join Proxy 807 will need some overhead, while the maximum packet sized guaranteed on 808 802.15.4 networks is 1280 bytes. It is RECOMMENDED that a PMTU of 809 1024 bytes be assumed for the DTLS handshake. It is unlikely that 810 any Packet Too Big indications [RFC4443] will be relayed by the Join 811 Proxy. 813 During the operation of the constrained BRSKI-EST protocol, the CoAP 814 Blockwise transfer mechanism will be used when message sizes exceed 815 the PMTU. A Pledge/EST-client on a constrained network MUST use the 816 (D)TLS maximum fragment length extension ("max_fragment_length") 817 defined in Section 4 of [RFC6066] with the maximum fragment length 818 set to a value of either 2^9 or 2^10. 820 7. BRSKI-MASA Protocol 822 This section describes extensions to and clarifications of the BRSKI- 823 MASA protocol between Registrar and MASA. 825 7.1. Protocol and Formats 827 Section 5.4 of [RFC8995] describes a connection between the Registrar 828 and the MASA as being a normal TLS connection using HTTPS. This 829 document does not change that. The Registrar MAY use the new format 830 "application/voucher-cose+cbor" in its voucher request to MASA, or 831 the existing BRSKI format "application/voucher-cms+json" defined by 832 [RFC8995]. 834 The MASA only needs to support formats for which there are Pledges 835 that use that format. 837 The Registrar MUST use the same format for the RVR as the Pledge used 838 for its PVR. 840 The Registrar indicates the voucher format it wants to receive from 841 MASA using the HTTP Accept header. This format MUST be the same as 842 the format of the PVR, so that the Pledge can parse it. 844 At the moment of writing the creation of coaps based MASAs is deemed 845 unrealistic. The use of CoAP for the BRSKI-MASA connection can be 846 the subject of another document. Some consideration was made to 847 specify CoAP support for consistency, but: 849 * the Registrar is not expected to be so constrained that it cannot 850 support HTTPS client connections. 852 * the technology and experience to build Internet-scale HTTPS 853 responders (which the MASA is) is common, while the experience 854 doing the same for CoAP is much less common. 856 * in many Enterprise networks, outgoing UDP connections are often 857 treated as suspicious, and there seems to be no advantage to using 858 CoAP in that environment. 860 * a Registrar is likely to provide onboarding services to both 861 constrained and non-constrained devices. Such a Registrar would 862 need to speak HTTPS anyway. 864 * similarly, a manufacturer is likely to offer both constrained and 865 non-constrained devices, so there may in practice be no situation 866 in which the MASA could be CoAP-only. Additionally, as the MASA 867 is intended to be a function that can easily be oursourced to a 868 third-party service provider, reducing the complexity would also 869 seem to reduce the cost of that function. 871 7.2. Registrar Voucher Request 873 If the PVR contains a proximity assertion, the Registrar MUST 874 propagate this assertion into the RVR by including the "assertion" 875 field with the value "proximity". This conforms to the example in 876 Section 3.3 of [RFC8995] of carrying the assertion forward. 878 7.3. MASA and the Server Name Indicator (SNI) 880 A TLS/HTTPS connection is established between the Registrar and MASA. 882 Section 5.4 of [RFC8995] explains this process, and there are no 883 externally visible changes. A MASA that supports the unconstrained 884 voucher formats should be able to support constrained vouchers 885 requests equally well. 887 There is no requirement that a single MASA be used for both 888 constrained and unconstrained voucher requests: the choice of MASA is 889 determined by the id-mod-MASAURLExnn2016 extension contained in the 890 IDevID. 892 The Registrar MUST do [RFC6125] DNS-ID checks on the contents of the 893 certificate provided by the MASA. 895 In constrast to the Pledge/Registrar situation, the Registrar always 896 knows the name of the MASA, and MUST always include an [RFC6066] 897 Server Name Indicator. The SNI is optional in TLS1.2, but common. 898 The SNI it considered mandatory with TLS1.3, so this requirement is 899 not unusual. 901 The presence of the SNI is need by the MASA in order for the MASA to 902 host multiple tenants (for different customers). 904 The Registrar SHOULD use a TLS Client Certificate to authenticate to 905 the MASA. If the certificate that the Registrar uses is marked as a 906 cmcRA certificate, via Extended Key Usage, then it MUST also have the 907 id-kp-clientAuth EKU attribute set. 909 7.3.1. Registrar Certificate Requirement 911 In summary for typical Registrar use, where a single Registrar 912 certificate is used, then the certificate MUST have EKU of: id-kp- 913 cmcRA, id-kp-serverAuth, id-kp-clientAuth. 915 8. Pinning in Voucher Artifacts 917 The voucher is a statement by the MASA for use by the Pledge that 918 provide the identity of the Pledge's owner. This section describes 919 how the owner's identity is determined and how it is encoded within 920 the voucher. 922 8.1. Registrar Identity Selection and Encoding 924 Section 5.5 of [RFC8995] describes BRSKI policies for selection of 925 the owner identity. It indicates some of the flexibility that is 926 possible for the Registrar. 928 The recommendation made there is for the Registrar to include only 929 certificates in the voucher request (CMS) signing structure that 930 participate in the certificate chain that is to be pinned. 932 The MASA is expected to evaluate the certificates included by the 933 Registrar in its voucher request, forming them into a chain with the 934 Registrar's (signing) identity on one end. Then, it pins a 935 certificate selected from the chain. For instance, for a domain with 936 a two-level certification authority (see Figure 1), where the 937 voucher-request has been signed by "Registrar", its signing structure 938 includes two additional CA certificates. The arrows in the figure 939 indicate the issuer of a certificate, i.e. (1) issued (2) and (2) 940 issued (3). 942 .------------------. 943 | domain CA (1) | 944 | trust anchor | 945 '------------------' 946 | 947 v 948 .------------. 949 | domain (2) | 950 | Sub-CA | 951 '------------' 952 | 953 | 954 v 955 .----------------. 956 | domain | 957 | Registrar (3) | 958 | EE certificate | 959 '----------------' 961 Figure 1: Two-Level CA PKI 963 When the Registrar is using a COSE-signed constrained voucher request 964 towards MASA, instead of a regular CMS-signed voucher request, the 965 COSE_Sign1 object contains a protected and an unprotected header. 966 The Registrar MUST place all the certificates needed to validate the 967 signature chain from the Registrar on the RVR in an "x5bag" attribute 968 in the unprotected header [I-D.ietf-cose-x509]. 970 The "x5bag" attribute is very important as it provides the required 971 signals from the Registrar to control what identity is pinned in the 972 resulting voucher. This is explained in the next section. 974 8.2. MASA Pinning Policy 976 The MASA, having assembled and verified the chain in the signing 977 structure of the voucher request, will now need to select a 978 certificate to pin. (For the case that only the Registrar's End- 979 Entity certificate is included, only this certificate can be selected 980 and this section does not apply.) The BRSKI policy for pinning by 981 the MASA as described in Section 5.5.2 of [RFC8995] leaves much 982 flexibility to the manufacturer. 984 The present document adds the following rules to the MASA pinning 985 policy to reduce the network load: 987 1. for a voucher containing a nonce, it SHOULD select the most 988 specific (lowest-level) CA certificate in the chain. 990 2. for a nonceless voucher, it SHOULD select the least-specific 991 (highest-level) CA certificate in the chain that is allowed under 992 the MASA's policy for this specific domain. 994 The rationale for 1. is that in case of a voucher with nonce, the 995 voucher is valid only in scope of the present DTLS connection between 996 Pledge and Registrar anyway, so it would have no benefit to pin a 997 higher-level CA. By pinning the most specific CA the constrained 998 Pledge can validate its DTLS connection using less crypto operations. 999 The rationale for pinning a CA instead of the Registrar's End-Entity 1000 certificate directly is the following benefit on constrained 1001 networks: the pinned certificate in the voucher can in common cases 1002 be re-used as a Domain CA trust anchor during the EST enrollment and 1003 during the operational phase that follows after EST enrollment, as 1004 explained in Section 6.6.1. 1006 The rationale for 2. follows from the flexible BRSKI trust model for, 1007 and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of 1008 [RFC8995]). 1010 Using the previous example of a domain with a two-level certification 1011 authority, the most specific CA ("Sub-CA") is the identity that is 1012 pinned by MASA in a nonced voucher. A Registrar that wished to have 1013 only the Registrar's End-Entity certificate pinned would omit the 1014 "domain CA" and "Sub-CA" certificates from the voucher-request. 1016 In case of a nonceless voucher, the MASA would depending on trust 1017 level pin only "Registrar" certificate (low trust in customer), or 1018 the "Sub-CA" certificate (in case of medium trust, implying that any 1019 Registrar of that sub-domain is acceptable), or even the "domain CA" 1020 certificate (in case of high trust in the customer, and possibly a 1021 pre-agreed need of the customer to obtain flexible long-lived 1022 vouchers). 1024 8.3. Pinning of Raw Public Keys 1026 Specifically for constrained use cases, the pinning of the raw public 1027 key (RPK) of the Registrar is also supported in the constrained 1028 voucher, instead of an X.509 certificate. If an RPK is pinned it 1029 MUST be the RPK of the Registrar. 1031 When the Pledge is known by MASA to support RPK but not X.509 1032 certificates, the voucher produced by the MASA pins the RPK of the 1033 Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk- 1034 sha256" field of a voucher. This is described in more detail in 1035 Section 9.2.3. A Pledge that does not support X.509 certificates 1036 cannot use EST to enroll; it has to use another method for enrollment 1037 without certificates and the Registrar has to support this method 1038 also. It is possible that the Pledge will not enroll, but instead 1039 only a network join operation will occur, such as described in 1040 [RFC9031]. How the Pledge discovers this method and details of the 1041 enrollment method are out of scope of this document. 1043 When the Pledge is known by MASA to support PKIX format certificates, 1044 the "pinned-domain-cert" field present in a voucher typically pins a 1045 domain certificate. That can be either the End-Entity certificate of 1046 the Registrar, or the certificate of a domain CA of the Registrar's 1047 domain as specified in Section 8.2. However, if the Pledge is known 1048 to also support RPK pinning and the MASA intends to identify the 1049 Registrar in the voucher (not the CA), then MASA MUST pin the RPK 1050 (RPK3 in Figure 2) of the Registrar instead of the Registrar's End- 1051 Entity certificate to save space in the voucher. 1053 .------------. 1054 | pub-CA (1) | 1055 '------------' 1056 | 1057 v 1058 .------------. 1059 | sub-CA (2) | 1060 '------------' 1061 | 1062 v 1063 .--------------. 1064 | Registrar(3) | 1065 | RPK3 | 1066 '--------------' 1068 Figure 2: Raw Public Key pinning 1070 8.4. Considerations for use of IDevID-Issuer 1072 [RFC8366] and [RFC8995] defines the idevid-issuer attribute for 1073 voucher and voucher-request (respectively), but they do not explain 1074 that much about when to use it. 1076 The use of idevid-issuer is provided so that the serial-number to 1077 which the issued voucher pertains can be relative to the entity that 1078 issued the devices' IDevID. In most cases there is a one to one 1079 relationship between the trust anchor that signs vouchers (and is 1080 trusted by the pledge), and the Certification Authority that signs 1081 the IDevID. In that case, the serial-number in the voucher must 1082 refer to the same device as the serial-number that is in IDevID 1083 certificate. 1085 However, there situations where the one to one relationship may be 1086 broken. This occurs whenever a manufacturer has a common MASA, but 1087 different producers (on different assembly lines) are produced with 1088 identical serial numbers. A system of serial numbers which is just a 1089 simple counter is a good example of this. A system of serial numbers 1090 where there is some prefix relating the product type does not fit 1091 into this, even if the lower digits are a counter. 1093 It is not possible for the Pledge or the Registrar to know which 1094 situation applies. The question to be answered is whether or not to 1095 include the idevid-issuer in the PVR and the RVR. A second question 1096 arose as to what the format of the idevid-issuer contents are. 1098 Analysis of the situation shows that the pledge never needs to 1099 include the idevid-issuer in it's PVR, because the pledge's IDevID 1100 certificate is available the Registrar, and the Authority Key 1101 Identifier is contained within that. The pledge therefore has no 1102 need to repeat this. 1104 For the RVR, the Registrar has to examine the pledge's IDevID 1105 certificate to discover the serial number for the Registrar's Voucher 1106 Request (RVR). This is clear in Section 5.5 of [RFC8995]. That 1107 section also clarifies that the idevid-issuer is to be included in 1108 the RVR. 1110 There has been some confusion as to how much of the Authority Key 1111 Identifier is to be included. The explanation in the YANG module of 1112 [RFC8366] is a bit vague as there are two different OCTET STRINGS 1113 present in respectively Section 4.1 of [RFC5280] and Section 4.2.1.1 1114 of [RFC5280] for this extension. The correct interpretation is that 1115 [RFC8366] specifies that the entire object i.e. the extnValue OCTET 1116 STRING is to be included: comprising the AuthorityKeyIdentifier, 1117 SEQUENCE, Choice as well as the OCTET STRING that is the 1118 keyIdentifier. 1120 !-- ********************************************** --> 1122 9. Artifacts 1124 This section describes for both the voucher request and the voucher 1125 first the abstract (tree) definition as explained in [RFC8340]. This 1126 provides a high-level view of the contents of each artifact. 1128 Then the assigned SID values are presented. These have been assigned 1129 using the rules in [I-D.ietf-core-sid]. 1131 9.1. Voucher Request artifact 1133 9.1.1. Tree Diagram 1135 The following diagram is largely a duplicate of the contents of 1136 [RFC8366], with the addition of the fields proximity-registrar-pubk, 1137 proximity-registrar-pubk-sha256, proximity-registrar-cert, and prior- 1138 signed-voucher-request. 1140 prior-signed-voucher-request is only used between the Registrar and 1141 the MASA. proximity-registrar-pubk or proximity-registrar-pubk-sha256 1142 optionally replaces proximity-registrar-cert for the most constrained 1143 cases where RPK is used by the Pledge. 1145 module: ietf-constrained-voucher-request 1147 grouping voucher-request-constrained-grouping 1148 +-- voucher 1149 +-- created-on? yang:date-and-time 1150 +-- expires-on? yang:date-and-time 1151 +-- assertion enumeration 1152 +-- serial-number string 1153 +-- idevid-issuer? binary 1154 +-- pinned-domain-cert? binary 1155 +-- domain-cert-revocation-checks? boolean 1156 +-- nonce? binary 1157 +-- last-renewal-date? yang:date-and-time 1158 +-- proximity-registrar-pubk? binary 1159 +-- proximity-registrar-pubk-sha256? binary 1160 +-- proximity-registrar-cert? binary 1161 +-- prior-signed-voucher-request? binary 1163 9.1.2. SID values 1164 SID Assigned to 1165 --------- -------------------------------------------------- 1166 2519 data /ietf-constrained-voucher-request:voucher 1167 2520 data .../assertion 1168 2521 data .../created-on 1169 2522 data .../domain-cert-revocation-checks 1170 2523 data .../expires-on 1171 2524 data .../idevid-issuer 1172 2525 data .../last-renewal-date 1173 2526 data /ietf-constrained-voucher-request:voucher/nonce 1174 2527 data .../pinned-domain-cert 1175 2528 data .../prior-signed-voucher-request 1176 2529 data .../proximity-registrar-cert 1177 2530 data .../proximity-registrar-pubk 1178 2531 data .../proximity-registrar-pubk-sha256 1179 2532 data .../serial-number 1180 2501 data /ietf-voucher-request-constrained:voucher 1181 2502 data .../assertion 1182 2503 data .../created-on 1183 2504 data .../domain-cert-revocation-checks 1184 2505 data .../expires-on 1185 2506 data .../idevid-issuer 1186 2507 data .../last-renewal-date 1187 2508 data /ietf-voucher-request-constrained:voucher/nonce 1188 2509 data .../pinned-domain-cert 1189 2510 data .../prior-signed-voucher-request 1190 2511 data .../proximity-registrar-cert 1191 2513 data .../proximity-registrar-pubk 1192 2512 data .../proximity-registrar-pubk-sha256 1193 2514 data .../serial-number 1195 WARNING, obsolete definitions 1197 9.1.3. YANG Module 1199 In the constrained-voucher-request YANG module, the voucher is 1200 "augmented" within the "used" grouping statement such that one 1201 continuous set of SID values is generated for the constrained- 1202 voucher-request module name, all voucher attributes, and the 1203 constrained-voucher-request attributes. Two attributes of the 1204 voucher are "refined" to be optional. 1206 file "ietf-voucher-request-constrained@2021-04-15.yang" 1207 module ietf-constrained-voucher-request { 1208 yang-version 1.1; 1210 namespace 1211 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; 1213 prefix "constrained"; 1215 import ietf-restconf { 1216 prefix rc; 1217 description 1218 "This import statement is only present to access 1219 the yang-data extension defined in RFC 8040."; 1220 reference "RFC 8040: RESTCONF Protocol"; 1221 } 1223 import ietf-voucher { 1224 prefix "v"; 1225 } 1227 organization 1228 "IETF ANIMA Working Group"; 1230 contact 1231 "WG Web: 1232 WG List: 1233 Author: Michael Richardson 1234 1235 Author: Peter van der Stok 1236 1237 Author: Panos Kampanakis 1238 "; 1240 description 1241 "This module defines the format for a voucher request, 1242 which is produced by a pledge to request a voucher. 1243 The voucher-request is sent to the potential owner's 1244 Registrar, which in turn sends the voucher request to 1245 the manufacturer or its delegate (MASA). 1247 A voucher is then returned to the pledge, binding the 1248 pledge to the owner. This is a constrained version of the 1249 voucher-request present in 1250 {{I-D.ietf-anima-bootstrap-keyinfra}} 1252 This version provides a very restricted subset appropriate 1253 for very constrained devices. 1254 In particular, it assumes that nonce-ful operation is 1255 always required, that expiration dates are rather weak, as no 1256 clocks can be assumed, and that the Registrar is identified 1257 by either a pinned Raw Public Key of the Registrar, or by a 1258 pinned X.509 certificate of the Registrar or domain CA. 1260 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1261 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1262 and 'OPTIONAL' in the module text are to be interpreted as 1263 described in RFC 2119."; 1265 revision "2021-04-15" { 1266 description 1267 "Initial version"; 1268 reference 1269 "RFC XXXX: Voucher Profile for Constrained Devices"; 1270 } 1272 rc:yang-data voucher-request-constrained-artifact { 1273 // YANG data template for a voucher. 1274 uses voucher-request-constrained-grouping; 1275 } 1277 // Grouping defined for future usage 1278 grouping voucher-request-constrained-grouping { 1279 description 1280 "Grouping to allow reuse/extensions in future work."; 1282 uses v:voucher-artifact-grouping { 1284 refine voucher/created-on { 1285 mandatory false; 1286 } 1288 refine voucher/pinned-domain-cert { 1289 mandatory false; 1290 } 1292 augment "voucher" { 1293 description "Base the constrained voucher-request upon the 1294 regular one"; 1296 leaf proximity-registrar-pubk { 1297 type binary; 1298 description 1299 "The proximity-registrar-pubk replaces 1300 the proximity-registrar-cert in constrained uses of 1301 the voucher-request. 1302 The proximity-registrar-pubk is the 1303 Raw Public Key of the Registrar. This field is encoded 1304 as specified in RFC7250, section 3. 1305 The ECDSA algorithm MUST be supported. 1306 The EdDSA algorithm as specified in 1307 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1309 Support for the DSA algorithm is not recommended. 1310 Support for the RSA algorithm is a MAY, but due to 1311 size is discouraged."; 1312 } 1314 leaf proximity-registrar-pubk-sha256 { 1315 type binary; 1316 description 1317 "The proximity-registrar-pubk-sha256 1318 is an alternative to both 1319 proximity-registrar-pubk and pinned-domain-cert. 1320 In many cases the public key of the domain has already 1321 been transmitted during the key agreement protocol, 1322 and it is wasteful to transmit the public key another 1323 two times. 1324 The use of a hash of public key info, at 32-bytes for 1325 sha256 is a significant savings compared to an RSA 1326 public key, but is only a minor savings compared to 1327 a 256-bit ECDSA public-key. 1328 Algorithm agility is provided by extensions to this 1329 specification which may define a new leaf for another 1330 hash type."; 1331 } 1333 leaf proximity-registrar-cert { 1334 type binary; 1335 description 1336 "An X.509 v3 certificate structure as specified by 1337 RFC 5280, 1338 Section 4 encoded using the ASN.1 distinguished encoding 1339 rules (DER), as specified in ITU-T X.690. 1341 The first certificate in the Registrar TLS server 1342 certificate_list sequence (see [RFC5246]) presented by 1343 the Registrar to the Pledge. This field or one of its 1344 alternatives MUST be populated in a 1345 Pledge's voucher request if the proximity assertion is 1346 populated."; 1347 } 1349 leaf prior-signed-voucher-request { 1350 type binary; 1351 description 1352 "If it is necessary to change a voucher, or re-sign and 1353 forward a voucher that was previously provided along a 1354 protocol path, then the previously signed voucher 1355 SHOULD be included in this field. 1357 For example, a pledge might sign a proximity voucher, 1358 which an intermediate registrar then re-signs to 1359 make its own proximity assertion. This is a simple 1360 mechanism for a chain of trusted parties to change a 1361 voucher, while maintaining the prior signature 1362 information. 1364 The pledge MUST ignore all prior voucher information 1365 when accepting a voucher for imprinting. Other 1366 parties MAY examine the prior signed voucher 1367 information for the purposes of policy decisions. 1368 For example, this information could be useful to a 1369 MASA to determine that both pledge and registrar 1370 agree on proximity assertions. The MASA SHOULD 1371 remove all prior-signed-voucher-request information when 1372 signing a voucher for imprinting so as to minimize the 1373 final voucher size."; 1374 } 1375 } 1376 } 1377 } 1378 } 1379 1381 9.1.4. Example voucher request artifact 1383 Below is a CBOR serialization of an example constrained voucher 1384 request from a Pledge to a Registrar, shown in CBOR diagnostic 1385 notation. The enum value of the assertion field is calculated to be 1386 2 by following the algorithm described in section 9.6.4.2 of 1387 [RFC7950]. Four dots ("....") in a CBOR byte string denotes a 1388 sequence of bytes that are not shown for brevity. 1390 { 1391 2501: { 1392 +2 : "2016-10-07T19:31:42Z", / SID=2503, created-on / 1393 +4 : "2016-10-21T19:31:42Z", / SID=2505, expires-on / 1394 +1 : 2, / SID=2502, assertion "proximity" / 1395 +13: "JADA123456789", / SID=2514, serial-number / 1396 +5 : h'08C2BF36....B3D2B3', / SID=2506, idevid-issuer / 1397 +10: h'30820275....82c35f', / SID=2511, proximity-registrar-cert/ 1398 +3 : true, / SID=2504, domain-cert 1399 -revocation-checks/ 1400 +6 : "2017-10-07T19:31:42Z" / SID=2507, last-renewal-date / 1401 } 1402 } 1403 1405 9.2. Voucher artifact 1407 The voucher's primary purpose is to securely assign a Pledge to an 1408 owner. The voucher informs the Pledge which entity it should 1409 consider to be its owner. 1411 9.2.1. Tree Diagram 1413 The following diagram is largely a duplicate of the contents of 1414 [RFC8366], with only the addition of the fields pinned-domain-pubk 1415 and pinned-domain-pubk-sha256. 1417 module: ietf-constrained-voucher 1419 grouping voucher-constrained-grouping 1420 +-- voucher 1421 +-- created-on? yang:date-and-time 1422 +-- expires-on? yang:date-and-time 1423 +-- assertion enumeration 1424 +-- serial-number string 1425 +-- idevid-issuer? binary 1426 +-- pinned-domain-cert? binary 1427 +-- domain-cert-revocation-checks? boolean 1428 +-- nonce? binary 1429 +-- last-renewal-date? yang:date-and-time 1430 +-- pinned-domain-pubk? binary 1431 +-- pinned-domain-pubk-sha256? binary 1432 1434 9.2.2. SID values 1435 SID Assigned to 1436 --------- -------------------------------------------------- 1437 2467 data /ietf-constrained-voucher:voucher 1438 2468 data /ietf-constrained-voucher:voucher/assertion 1439 2469 data /ietf-constrained-voucher:voucher/created-on 1440 2470 data .../domain-cert-revocation-checks 1441 2471 data /ietf-constrained-voucher:voucher/expires-on 1442 2472 data /ietf-constrained-voucher:voucher/idevid-issuer 1443 2473 data .../last-renewal-date 1444 2474 data /ietf-constrained-voucher:voucher/nonce 1445 2475 data .../pinned-domain-cert 1446 2476 data .../pinned-domain-pubk 1447 2477 data .../pinned-domain-pubk-sha256 1448 2478 data /ietf-constrained-voucher:voucher/serial-number 1449 2451 data /ietf-voucher-constrained:voucher 1450 2452 data /ietf-voucher-constrained:voucher/assertion 1451 2453 data /ietf-voucher-constrained:voucher/created-on 1452 2454 data .../domain-cert-revocation-checks 1453 2455 data /ietf-voucher-constrained:voucher/expires-on 1454 2456 data /ietf-voucher-constrained:voucher/idevid-issuer 1455 2457 data .../last-renewal-date 1456 2458 data /ietf-voucher-constrained:voucher/nonce 1457 2459 data .../pinned-domain-cert 1458 2460 data .../pinned-domain-pubk 1459 2461 data .../pinned-domain-pubk-sha256 1460 2462 data /ietf-voucher-constrained:voucher/serial-number 1462 WARNING, obsolete definitions 1464 1466 9.2.3. YANG Module 1468 In the constrained-voucher YANG module, the voucher is "augmented" 1469 within the "used" grouping statement such that one continuous set of 1470 SID values is generated for the constrained-voucher module name, all 1471 voucher attributes, and the constrained-voucher attributes. Two 1472 attributes of the voucher are "refined" to be optional. 1474 file "ietf-constrained-voucher@2021-04-15.yang" 1475 module ietf-constrained-voucher { 1476 yang-version 1.1; 1478 namespace 1479 "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; 1480 prefix "constrained"; 1482 import ietf-restconf { 1483 prefix rc; 1484 description 1485 "This import statement is only present to access 1486 the yang-data extension defined in RFC 8040."; 1487 reference "RFC 8040: RESTCONF Protocol"; 1488 } 1490 import ietf-voucher { 1491 prefix "v"; 1492 } 1494 organization 1495 "IETF ANIMA Working Group"; 1497 contact 1498 "WG Web: 1499 WG List: 1500 Author: Michael Richardson 1501 1502 Author: Peter van der Stok 1503 1504 Author: Panos Kampanakis 1505 "; 1507 description 1508 "This module defines the format for a voucher, which 1509 is produced by a pledge's manufacturer or its delegate 1510 (MASA) to securely assign one or more pledges to an 'owner', 1511 so that a pledge may establish a secure connection to the 1512 owner's network infrastructure. 1514 This version provides a very restricted subset appropriate 1515 for very constrained devices. 1516 In particular, it assumes that nonce-ful operation is 1517 always required, that expiration dates are rather weak, as no 1518 clocks can be assumed, and that the Registrar is identified 1519 by either a pinned Raw Public Key of the Registrar, or by a 1520 pinned X.509 certificate of the Registrar or domain CA. 1522 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1523 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1524 and 'OPTIONAL' in the module text are to be interpreted as 1525 described in RFC 2119."; 1527 revision "2021-04-15" { 1528 description 1529 "Initial version"; 1530 reference 1531 "RFC XXXX: Voucher Profile for Constrained Devices"; 1532 } 1534 rc:yang-data voucher-constrained-artifact { 1535 // YANG data template for a voucher. 1536 uses voucher-constrained-grouping; 1537 } 1539 // Grouping defined for future usage 1540 grouping voucher-constrained-grouping { 1541 description 1542 "Grouping to allow reuse/extensions in future work."; 1544 uses v:voucher-artifact-grouping { 1546 refine voucher/created-on { 1547 mandatory false; 1548 } 1550 refine voucher/pinned-domain-cert { 1551 mandatory false; 1552 } 1554 augment "voucher" { 1555 description "Base the constrained voucher 1556 upon the regular one"; 1557 leaf pinned-domain-pubk { 1558 type binary; 1559 description 1560 "The pinned-domain-pubk may replace the 1561 pinned-domain-cert in constrained uses of 1562 the voucher. The pinned-domain-pubk 1563 is the Raw Public Key of the Registrar. 1564 This field is encoded as a Subject Public Key Info block 1565 as specified in RFC7250, in section 3. 1566 The ECDSA algorithm MUST be supported. 1567 The EdDSA algorithm as specified in 1568 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1569 Support for the DSA algorithm is not recommended. 1570 Support for the RSA algorithm is a MAY."; 1571 } 1573 leaf pinned-domain-pubk-sha256 { 1574 type binary; 1575 description 1576 "The pinned-domain-pubk-sha256 is a second 1577 alternative to pinned-domain-cert. In many cases the 1578 public key of the domain has already been transmitted 1579 during the key agreement process, and it is wasteful 1580 to transmit the public key another two times. 1581 The use of a hash of public key info, at 32-bytes for 1582 sha256 is a significant savings compared to an RSA 1583 public key, but is only a minor savings compared to 1584 a 256-bit ECDSA public-key. 1585 Algorithm agility is provided by extensions to this 1586 specification which can define a new leaf for another 1587 hash type."; 1588 } 1589 } 1590 } 1591 } 1592 } 1593 1595 9.2.4. Example voucher artifacts 1597 Below the CBOR serialization of an example constrained voucher is 1598 shown in CBOR diagnostic notation. The enum value of the assertion 1599 field is calculated to be zero by following the algorithm described 1600 in section 9.6.4.2 of [RFC7950]. Four dots ("....") in a CBOR byte 1601 string denotes a sequence of bytes that are not shown for brevity. 1603 { 1604 2451: { 1605 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 1606 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 1607 +1 : 0, / SID = 2452, assertion "verified" / 1608 +11: "JADA123456789", / SID = 2462, serial-number / 1609 +5 : h'E40393B4....68A3', / SID = 2456, idevid-issuer / 1610 +8 : h'30820275....C35F', / SID = 2459, pinned-domain-cert/ 1611 +3 : true, / SID = 2454, domain-cert / 1612 / -revocation-checks / 1613 +6 : "2017-10-07T19:31:42Z" / SID = 2457, last-renewal-date / 1614 } 1615 } 1617 1619 9.3. Signing voucher and voucher-request artifacts with COSE 1621 The COSE_Sign1 structure is discussed in Section 4.2 of 1622 [I-D.ietf-cose-rfc8152bis-struct]. The CBOR object that carries the 1623 body, the signature, and the information about the body and signature 1624 is called the COSE_Sign1 structure. It is used when only one 1625 signature is used on the body. 1627 Support for ECDSA with SHA2-256 using curve secp256r1 (aka 1628 prime256k1) is RECOMMENDED. Most current low power hardware has 1629 support for acceleration of this algorithm. Future hardware designs 1630 could omit this in favour of a newer algorithms. This is the ES256 1631 keytype from Table 1 of [I-D.ietf-cose-rfc8152bis-algs]. Support for 1632 curve secp256k1 is OPTIONAL. 1634 Support for EdDSA using Curve 25519 is RECOMMENDED in new designs if 1635 hardware support is available. This is keytype EDDSA (-8) from 1636 Table 2 of [I-D.ietf-cose-rfc8152bis-algs]. A "crv" parameter is 1637 necessary to specify the Curve, which from Table 18. The 'kty' field 1638 MUST be present, and it MUST be 'OKP'. (Table 17) 1640 A transition towards EdDSA is occuring in the industry. Some 1641 hardware can accelerate only some algorithms with specific curves, 1642 other hardware can accelerate any curve, and still other kinds of 1643 hardware provide a tool kit for acceleration of any eliptic curve 1644 algorithm. 1646 In general, the Pledge is expected to support only a single 1647 algorithm, while the Registrar, usually not constrained, is expected 1648 to support a wide variety of algorithms: both legacy ones and up-and- 1649 coming ones via regular software updates. 1651 An example of the supported COSE_Sign1 object structure is shown in 1652 Figure 3. 1654 COSE_Sign1( 1655 [ 1656 h'A101382E', # protected header encoding: {1: -47} , which means { "alg": ES256K } 1657 { 1658 4 : h'7890A03F1234' # 4 is the "kid" binary key identifier 1659 }, 1660 h'1234....5678', #voucher-request binary content (CBOR) 1661 h'4567....1234' #voucher-request binary public signature 1662 ] 1663 ) 1665 Figure 3: COSE_Sign1 example in CBOR diagnostic notation 1667 The [COSE-registry] specifies the integers/encoding for the "alg" and 1668 "kid" fields in Figure 3. The "alg" field restricts the key usage 1669 for verification of this COSE object to a particular cryptographic 1670 algorithm. 1672 The "kid" field is optionally present: it is an unprotected field 1673 that identifies the public key of the key pair that was used to sign 1674 this message. The value of the key identifier "kid" parameter is an 1675 example value. Usually a hash of the public key is used to identify 1676 the public key, but a device serial number may also be used. The 1677 choice of key identifier method is vendor-specific. If "kid" is not 1678 present, then a verifying party needs to use other context 1679 information to retrieve the right public key to verify the COSE_Sign1 1680 object against. For example, this context information may be a 1681 unique serial number encoded in the binary content (CBOR) field. 1683 A Registrar MAY use a "kid" parameter in its RVR to identify its 1684 signing key as used to sign the RVR. The method of generating this 1685 "kid" is vendor-specific and SHOULD be configurable in the Registrar 1686 to support commonly used methods. In order to support future 1687 business cases and supply chain integrations, a Registrar MUST be 1688 configurable, on a per-manufacturer basis, to be able to configure 1689 the "kid" to a particular value. Both binary and string values are 1690 to be supported, each being inserted using a CBOR bstr or tstr. By 1691 default, a Registrar does not include a "kid" parameter in its RVR 1692 since the signing key is already identified by the included signing 1693 certificates in the COSE "x5bag" structure. 1695 A Pledge normally SHOULD NOT use a "kid" parameter in its PVR, 1696 because its signing key is already identified by the Pledge's unique 1697 serial number that is included in the PVR. Still, where needed the 1698 Pledge MAY use a "kid" parameter in its PVR to help the MASA identify 1699 the right public key to verify against. This can occur for example 1700 if a Pledge has multiple IDevID identities. A Registrar normally 1701 SHOULD ignore a "kid" parameter used in a received PVR, as this 1702 information is intended for the MASA. In other words, there is no 1703 need for the Registrar to verify the contents of this field, but it 1704 may include it in an audit log. 1706 In Appendix C a binary COSE_Sign1 object is shown based on the 1707 voucher-request example of Section 9.1.4. 1709 10. Deployment specific Discovery Considerations 1711 This section details how discovery is done in a specific deployment 1712 scenarios. 1714 10.1. 6TSCH Deployments 1716 In 6TISCH networks, the Constrained Join Proxy (CoJP) mechanism is 1717 described in [RFC9031]. Such networks are expected to use a 1718 [I-D.ietf-lake-edhoc] to do key management. This is the subject of 1719 future work. The Enhanced Beacon has been extended in [RFC9032] to 1720 allow for discovery of the Join Proxy. 1722 10.2. Generic networks using GRASP 1724 [RFC8995] defines a mechanism for the Pledge to discover a Join Proxy 1725 by listening for [RFC8990] GRASP messages. This mechanism can be 1726 used on any network which does not have another more specific 1727 mechanism. This mechanism supports mesh networks, and can also be 1728 used over unencrypted WIFI. 1730 10.3. Generic networks using mDNS 1732 [RFC8995] also defines a non-normative mechanism for the Pledge to 1733 discover a Join Proxy by doing mDNS queries. This mechanism can be 1734 used on any network which does not have another recommended 1735 mechanism. This mechanism does not easily support mesh networks. It 1736 can be used over unencrypted WIFI. 1738 10.4. Thread networks using Mesh Link Establishment (MLE) 1740 TBD. 1742 10.5. Non-mesh networks using CoAP Discovery 1744 On unencrypted constrained networks such as 802.15.4, CoAP discover 1745 may be done using the mechanism detailed in [I-D.ietf-ace-coap-est] 1746 section 5.1. 1748 11. Design Considerations 1750 The design considerations for the CBOR encoding of vouchers are much 1751 the same as for JSON vouchers in [RFC8366]. One key difference is 1752 that the names of the leaves in the YANG definition do not affect the 1753 size of the resulting CBOR, as the SID translation process assigns 1754 integers to the names. 1756 Any POST request to the Registrar with resource /vs or /es returns a 1757 2.04 Changed response with empty payload. The client should be aware 1758 that the server may use a piggybacked CoAP response (ACK, 2.04) but 1759 may also respond with a separate CoAP response, i.e. first an (ACK, 1760 0.0) that is an acknowledgement of the request reception followed by 1761 a (CON, 2.04) response in a separate CoAP message. 1763 12. Raw Public Key Use Considerations 1765 This section explains techniques to reduce the number of bytes that 1766 are sent over the wire during the BRSKI bootstrap. The use of a raw 1767 public key (RPK) in the pinning process can significantly reduce the 1768 number of bytes and round trips, but it comes with a few significant 1769 operational limitations. 1771 12.1. The Registrar Trust Anchor 1773 When the Pledge first connects to the Registrar, the connection to 1774 the Registrar is provisional, as explained in Section 5.6.2 of 1775 [RFC8995]. The Registrar provides its public key in a 1776 TLSServerCertificate, and the Pledge uses that to validate that 1777 integrity of the (D)TLS connection, but it does not validate the 1778 identity of the provided certificate. 1780 As the TLSServerCertificate object is never verified directly by the 1781 pledge, sending it can be considered superfluous. Instead of using a 1782 (TLSServer)Certificate of type X509 (see section 4.4.2 of [RFC8446]), 1783 a RawPublicKey object is used. 1785 A Registrar operating in a mixed environment can determine whether to 1786 send a Certificate or a Raw Public key: this is determined by the 1787 pledge including the server_certificate_type of RawPublicKey. This 1788 is shown in section 5 of [RFC7250]. 1790 The Pledge continues to send a client_certificate_type of X509, so 1791 that the Registrar can properly identify the pledge and distill the 1792 MASA URI information from its certificate. 1794 12.2. The Pledge Voucher Request 1796 The Pledge puts the Registrar's public key into the proximity- 1797 registrar-pubk field of the voucher-request. (The proximity- 1798 registrar-pubk-sha256 can also be used if the 32-bytes of a SHA256 1799 hash turns out to be smaller than a typical ECDSA key.) 1801 As the format of the pubk field is identical to the TLS Certificate 1802 RawPublicKey, no manipulation at all is needed to insert this into a 1803 voucher-request. 1805 12.3. The Voucher Response 1807 A returned voucher will have a pinned-domain-subk field with the 1808 identical key as was found in the proximity-registrar-pubk field 1809 above, as well as in the TLS connection. 1811 Validation of this key by the pledge is what takes the DTLS 1812 connection out of the provisional state see Section 5.6.2 of 1813 [RFC8995]. 1815 The voucher needs to be validated first. The Pledge needs to have a 1816 public key to validate the signature from the MASA on the voucher. 1818 In certain cases, the MASA's public key counterpart of the (private) 1819 signing key is already installed in the Pledge at manufacturing time. 1820 In other cases, if the MASA signing key is based upon a PKI (see 1821 [I-D.richardson-anima-masa-considerations] Section 2.3), then a 1822 certificate chain may need to be included with the voucher in order 1823 for the pledge to validate the signature. In CMS signed artifacts, 1824 the CMS structure has a place for such certificates. 1826 In the COSE-signed Constrained Vouchers described in this document, 1827 the x5bag attribute from [I-D.ietf-cose-x509] is to be used for this. 1829 13. Security Considerations 1831 13.1. Duplicate serial-numbers 1833 In the absense of correct use of idevid-issuer by the Registrar as 1834 detailed in Section 8.4, it would be possible for a malicious 1835 Registrar to an unauthorized voucher for a device. This would apply 1836 only to the case where a Manufacturer Authorized Signing Authority 1837 (MASA) is trusted by different products from the same manufacturer, 1838 and the manufacturer has duplicated serial numbers as a result of a 1839 merge, acquisition or mis-management. 1841 For example, imagine the same manufacturer makes light bulbs as well 1842 as gas centrofuges, and that said manufacturer does not uniquely 1843 allocate product serial numbers. This attack only works for 1844 nonceless vouchers. The attacker has obtained a light bulb which 1845 happens to have the same serial-number as a gas centrofuge which it 1846 wishes to obtain access. The attacker performs a normal BRSKI 1847 onboarding for the light bulb, but then uses the resulting voucher to 1848 onboard the gas centrofuge. The attack requires that the gas 1849 centrofuge be returned to a state where it is willing to perform a 1850 new onboarding operation. 1852 This attack is prevented by the mechanism of having the Registrar 1853 include the idevid-issuer in the RVR, and the MASA including it in 1854 the resulting voucher. The idevid-issuer is not included by default: 1855 a MASA needs to be aware if there are parts of the organization which 1856 duplicates serial numbers, and if so, include it. 1858 13.2. IDevID security in Pledge 1860 TBD. 1862 13.3. Security of CoAP and UDP protocols 1864 Section 7.1 explains that no CoAPS version of the BRSKI-MASA protocol 1865 is proposed. The connection from the Registrar to the MASA continues 1866 to be HTTPS as in [RFC8995]. This has been done as it simplifies the 1867 MASA deployment for the manufacturer because no new protocol needs to 1868 be enabled. 1870 The use of UDP protocols across the open Internet is sometimes 1871 fraught with security challenges. Denial of service attacks against 1872 UDP based protocols is trivial as there is no three-way handshake as 1873 done for TCP. The three-way handshake of TCP guarantees that the 1874 node sending the connection request is reachable using the origin IP 1875 address. While DTLS contains an option to do a stateless challenge 1876 -- a process actually stronger than that done by TCP, it is not yet 1877 common for this mechanism to be available in hardware at multigigabit 1878 speeds. It is for this reason that this protocols sticks to using 1879 HTTPS for the Registrar->MASA connection. 1881 13.4. Registrar Certificate may be self-signed 1883 The provisional (D)TLS connection formed by the Pledge with the 1884 Registrar does not authenticate the Registrar's identity. This 1885 Registrar's identity is validated by the [RFC8366] voucher that is 1886 issued by the MASA, signed with an anchor that was built-in to the 1887 Pledge. 1889 The Registrar may therefore use any certificate, including a self- 1890 signed one. The only restrictions on the certificate is that it MUST 1891 have EKU bits set as detailed in Section 7.3.1. 1893 A Registrar that uses a Raw Public Key (RPK) has no certificate 1894 structure, and therefore has no EKU bits that can be set. 1896 14. IANA Considerations 1898 14.1. Resource Type Registry 1900 Additions to the sub-registry "Resource Type Link Target Attribute 1901 Values", within the "CoRE parameters" IANA registry are specified 1902 below. 1904 brski needs registration with IANA 1905 brski.rv needs registration with IANA 1906 brski.vs needs registration with IANA 1907 brski.es needs registration with IANA 1909 14.2. The IETF XML Registry 1911 This document registers two URIs in the IETF XML registry [RFC3688]. 1912 Following the format in [RFC3688], the following registration is 1913 requested: 1915 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 1916 Registrant Contact: The ANIMA WG of the IETF. 1917 XML: N/A, the requested URI is an XML namespace. 1919 URI: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request 1920 Registrant Contact: The ANIMA WG of the IETF. 1921 XML: N/A, the requested URI is an XML namespace. 1923 14.3. The YANG Module Names Registry 1925 This document registers two YANG modules in the YANG Module Names 1926 registry [RFC6020]. Following the format defined in [RFC6020], the 1927 the following registration is requested: 1929 name: ietf-constrained-voucher 1930 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained-voucher 1931 prefix: vch 1932 reference: RFC XXXX 1934 name: ietf-constrained-voucher-request 1935 namespace: urn:ietf:params:xml:ns:yang:ietf-constrained 1936 -voucher-request 1937 prefix: vch 1938 reference: RFC XXXX 1940 14.4. The RFC SID range assignment sub-registry 1942 ------------ ------ --------------------------- ------------ 1943 Entry-point | Size | Module name | RFC Number 1944 ------------ ------ --------------------------- ------------ 1945 2450 50 ietf-voucher-constrained [ThisRFC] 1946 2500 50 ietf-voucher-request [ThisRFC} 1947 -constrained 1948 ----------- ------ --------------------------- ------------ 1950 Warning: These SID values are defined in [I-D.ietf-core-sid], not as 1951 an Early Allocation. 1953 IANA: please update the names in the Registry to match these revised 1954 names, if they have not already been revised. 1956 14.5. Media Types Registry 1958 This section registers the 'application/voucher-cose+cbor' in the 1959 IANA "Media Types" registry. This media type is used to indicate 1960 that the content is a CBOR voucher or voucher request signed with a 1961 COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct]. 1963 14.5.1. application/voucher-cose+cbor 1965 Type name: application 1966 Subtype name: voucher-cose+cbor 1967 Required parameters: none 1968 Optional parameters: none 1969 Encoding considerations: binary (CBOR) 1970 Security considerations: Security Considerations of THIS RFC. 1971 Interoperability considerations: The format is designed to be 1972 broadly interoperable. 1973 Published specification: THIS RFC. 1974 Applications that use this media type: ANIMA, 6tisch, and other 1975 zero-touch onboarding systems Fragment identifier considerations: The syntax and semantics of 1976 fragment identifiers specified for application/voucher-cose+cbor are 1977 as specified for application/cbor. (At publication of this 1978 document, there is no fragment identification syntax defined for 1979 application/cbor.) 1980 Additional information: 1981 Magic number(s): None 1982 File extension(s): .vch 1983 Macintosh file type code(s): none 1984 Person & email address to contact for further information: IETF 1985 ANIMA Working Group (anima@ietf.org) or IETF Operations and 1986 Management Area Working Group (opsawg@ietf.org) 1987 Intended usage: LIMITED [^ouch2] 1988 Restrictions on usage: NONE 1989 Author: ANIMA WG 1990 Change controller: IETF 1991 Provisional registration? (standards tree only): NO 1993 14.6. CoAP Content-Format Registry 1995 Additions to the sub-registry "CoAP Content-Formats", within the 1996 "CoRE Parameters" registry are needed for two media types. These can 1997 be registered either in the Expert Review range (0-255) or IETF 1998 Review range (256-9999). 2000 Media type Encoding ID References 2001 ---------------------------- --------- ---- ---------- 2002 application/voucher-cose+cbor - TBD3 [This RFC] 2004 15. Acknowledgements 2006 We are very grateful to Jim Schaad for explaining COSE and CMS 2007 choices. Also thanks to Jim Schaad for correcting earlier version of 2008 the COSE Sign1 objects. 2010 Michel Veillette did extensive work on _pyang_ to extend it to 2011 support the SID allocation process, and this document was among its 2012 first users. 2014 16. Changelog 2016 -10 Design considerations extended Examples made consistent 2018 -08 Examples for cose_sign1 are completed and improved. 2020 -06 New SID values assigned; regenerated examples 2022 -04 voucher and request-voucher MUST be signed examples for signed 2023 request are added in appendix IANA SID registration is updated SID 2024 values in examples are aligned signed cms examples aligned with new 2025 SIDs 2027 -03 2029 Examples are inverted. 2031 -02 2033 Example of requestvoucher with unsigned appllication/cbor is added 2034 attributes of voucher "refined" to optional 2035 CBOR serialization of vouchers improved 2036 Discovery port numbers are specified 2038 -01 2040 application/json is optional, application/cbor is compulsory 2041 Cms and cose mediatypes are introduced 2043 17. References 2045 17.1. Normative References 2047 [I-D.ietf-ace-coap-est] 2048 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 2049 Raza, "EST over secure CoAP (EST-coaps)", Work in 2050 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 2051 January 2020, . 2054 [I-D.ietf-core-sid] 2055 Veillette, M., Pelov, A., Petrov, I., and C. Bormann, 2056 "YANG Schema Item iDentifier (YANG SID)", Work in 2057 Progress, Internet-Draft, draft-ietf-core-sid-16, 24 June 2058 2021, . 2061 [I-D.ietf-core-yang-cbor] 2062 Veillette, M., Petrov, I., Pelov, A., and C. Bormann, 2063 "CBOR Encoding of Data Modeled with YANG", Work in 2064 Progress, Internet-Draft, draft-ietf-core-yang-cbor-16, 24 2065 June 2021, . 2068 [I-D.ietf-cose-rfc8152bis-algs] 2069 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2070 Initial Algorithms", Work in Progress, Internet-Draft, 2071 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2072 . 2075 [I-D.ietf-cose-rfc8152bis-struct] 2076 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2077 Structures and Process", Work in Progress, Internet-Draft, 2078 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2079 . 2082 [I-D.ietf-cose-x509] 2083 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2084 Header parameters for carrying and referencing X.509 2085 certificates", Work in Progress, Internet-Draft, draft- 2086 ietf-cose-x509-08, 14 December 2020, 2087 . 2090 [I-D.ietf-tls-dtls13] 2091 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2092 Datagram Transport Layer Security (DTLS) Protocol Version 2093 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2094 dtls13-43, 30 April 2021, 2095 . 2098 [I-D.selander-ace-ake-authz] 2099 Selander, G., Mattsson, J. P., Vučinić, M., Richardson, 2100 M., and A. Schellenbaum, "Lightweight Authorization for 2101 Authenticated Key Exchange.", Work in Progress, Internet- 2102 Draft, draft-selander-ace-ake-authz-04, 22 October 2021, 2103 . 2106 [ieee802-1AR] 2107 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 2108 2009, . 2111 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2112 Requirement Levels", BCP 14, RFC 2119, 2113 DOI 10.17487/RFC2119, March 1997, 2114 . 2116 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2117 DOI 10.17487/RFC3688, January 2004, 2118 . 2120 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2121 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2122 . 2124 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2125 "Internet X.509 Public Key Infrastructure Certificate 2126 Management Protocol (CMP)", RFC 4210, 2127 DOI 10.17487/RFC4210, September 2005, 2128 . 2130 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2131 Housley, R., and W. Polk, "Internet X.509 Public Key 2132 Infrastructure Certificate and Certificate Revocation List 2133 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2134 . 2136 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2137 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2138 . 2140 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2141 the Network Configuration Protocol (NETCONF)", RFC 6020, 2142 DOI 10.17487/RFC6020, October 2010, 2143 . 2145 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2146 Extensions: Extension Definitions", RFC 6066, 2147 DOI 10.17487/RFC6066, January 2011, 2148 . 2150 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2151 Verification of Domain-Based Application Service Identity 2152 within Internet Public Key Infrastructure Using X.509 2153 (PKIX) Certificates in the Context of Transport Layer 2154 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2155 2011, . 2157 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2158 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2159 Transport Layer Security (TLS) and Datagram Transport 2160 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2161 June 2014, . 2163 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2164 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2165 . 2167 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2168 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2169 May 2017, . 2171 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2172 "A Voucher Artifact for Bootstrapping Protocols", 2173 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2174 . 2176 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2177 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2178 . 2180 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2181 Definition Language (CDDL): A Notational Convention to 2182 Express Concise Binary Object Representation (CBOR) and 2183 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2184 June 2019, . 2186 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2187 Representation (CBOR)", STD 94, RFC 8949, 2188 DOI 10.17487/RFC8949, December 2020, 2189 . 2191 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2192 and K. Watsen, "Bootstrapping Remote Secure Key 2193 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2194 May 2021, . 2196 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 2197 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 2198 RFC 9031, DOI 10.17487/RFC9031, May 2021, 2199 . 2201 [RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of 2202 6TiSCH Join and Enrollment Information Elements", 2203 RFC 9032, DOI 10.17487/RFC9032, May 2021, 2204 . 2206 17.2. Informative References 2208 [COSE-registry] 2209 IANA, ., "CBOR Object Signing and Encryption (COSE) 2210 registry", 2017, 2211 . 2213 [I-D.ietf-anima-constrained-join-proxy] 2214 Richardson, M., Stok, P. V. D., and P. Kampanakis, 2215 "Constrained Join Proxy for Bootstrapping Protocols", Work 2216 in Progress, Internet-Draft, draft-ietf-anima-constrained- 2217 join-proxy-05, 18 October 2021, 2218 . 2221 [I-D.ietf-lake-edhoc] 2222 Selander, G., Mattsson, J. P., and F. Palombini, 2223 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 2224 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 2225 October 2021, . 2228 [I-D.kuehlewind-update-tag] 2229 Kuehlewind, M. and S. Krishnan, "Definition of new tags 2230 for relations between RFCs", Work in Progress, Internet- 2231 Draft, draft-kuehlewind-update-tag-04, 12 July 2021, 2232 . 2235 [I-D.richardson-anima-masa-considerations] 2236 Richardson, M. and J. Yang, "Operatonal Considerations for 2237 Voucher infrastructure for BRSKI MASA", Work in Progress, 2238 Internet-Draft, draft-richardson-anima-masa- 2239 considerations-05, 12 March 2021, 2240 . 2243 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2244 Control Message Protocol (ICMPv6) for the Internet 2245 Protocol Version 6 (IPv6) Specification", STD 89, 2246 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2247 . 2249 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2250 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2251 . 2253 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2254 "Enrollment over Secure Transport", RFC 7030, 2255 DOI 10.17487/RFC7030, October 2013, 2256 . 2258 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2259 Constrained-Node Networks", RFC 7228, 2260 DOI 10.17487/RFC7228, May 2014, 2261 . 2263 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2264 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2265 . 2267 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 2268 Autonomic Signaling Protocol (GRASP)", RFC 8990, 2269 DOI 10.17487/RFC8990, May 2021, 2270 . 2272 Appendix A. Library support for BRSKI 2274 For the implementation of BRSKI, the use of a software library to 2275 manipulate certificates and use crypto algorithms is often 2276 beneficial. Two C-based examples are OPENSSL and mbedtls. Others 2277 more targeted to specific platforms or languages exist. It is 2278 important to realize that the library interfaces differ significantly 2279 between libraries. 2281 Libraries do not support all known crypto algorithms. Before 2282 deciding on a library, it is important to look at their supported 2283 crypto algorithms and the roadmap for future support. Apart from 2284 availability, the library footprint, and the required execution 2285 cycles should be investigated beforehand. 2287 The handling of certificates usually includes the checking of a 2288 certificate chain. In some libraries, chains are constructed and 2289 verified on the basis of a set of certificates, the trust anchor 2290 (usually self signed root CA), and the target certificate. In other 2291 libraries, the chain must be constructed beforehand and obey order 2292 criteria. Verification always includes the checking of the 2293 signatures. Less frequent is the checking the validity of the dates 2294 or checking the existence of a revoked certificate in the chain 2295 against a set of revoked certificates. Checking the chain on the 2296 consistency of the certificate extensions which specify the use of 2297 the certificate usually needs to be programmed explicitly. 2299 A libary can be used to construct a (D)TLS connection. It is useful 2300 to realize that differences beetween (D)TLS implementations will 2301 occur due to the differences in the certicate checks supported by the 2302 library. On top of that, checks between client and server 2303 certificates enforced by (D)TLS are not always helpful for a BRSKI 2304 implementation. For example, the certificates of Pledge and 2305 Registrar are usually not related when the BRSKI protocol is started. 2306 It must be verified that checks on the relation between client and 2307 server certificates do not hamper a succeful DTLS connection 2308 establishment. 2310 A.1. OpensSSL 2312 from openssl's apps/verify.c 2313 X509 *x = NULL; 2314 int i = 0, ret = 0; 2315 X509_STORE_CTX *csc; 2316 STACK_OF(X509) *chain = NULL; 2317 int num_untrusted; 2319 x = load_cert(file, "certificate file"); 2320 if (x == NULL) 2321 goto end; 2323 csc = X509_STORE_CTX_new(); 2324 if (csc == NULL) { 2325 BIO_printf(bio_err, "error %s: X.509 store context" 2326 "allocation failed\n", 2327 (file == NULL) ? "stdin" : file); 2328 goto end; 2329 } 2331 X509_STORE_set_flags(ctx, vflags); 2332 if (!X509_STORE_CTX_init(csc, ctx, x, uchain)) { 2333 X509_STORE_CTX_free(csc); 2334 BIO_printf(bio_err, 2335 "error %s: X.509 store context" 2336 "initialization failed\n", 2337 (file == NULL) ? "stdin" : file); 2338 goto end; 2339 } 2340 if (tchain != NULL) 2341 X509_STORE_CTX_set0_trusted_stack(csc, tchain); 2342 if (crls != NULL) 2343 X509_STORE_CTX_set0_crls(csc, crls); 2345 i = X509_verify_cert(csc); 2346 X509_STORE_CTX_free(csc); 2347 2349 A.2. mbedTLS 2351 mbedtls_x509_crt cert; 2352 mbedtls_x509_crt caCert; 2353 uint32_t certVerifyResultFlags; 2354 ... 2355 int result = mbedtls_x509_crt_verify(&cert, &caCert, NULL, NULL, 2356 &certVerifyResultFlags, NULL, NULL); 2358 A.3. wolfSSL 2360 To be added (TBD). 2362 Appendix B. Constrained BRSKI-EST messages 2364 This section extends the examples from Appendix A of 2365 [I-D.ietf-ace-coap-est] with the constrained BRSKI requests. The 2366 CoAP headers are only worked out for the enrollstatus example. 2368 B.1. enrollstatus 2370 A coaps enrollstatus message can be : 2372 POST coaps://192.0.2.1:8085/b/es 2374 The corresponding CoAP header fields are shown below. 2376 Ver = 1 2377 T = 0 (CON) 2378 Code = 0x02 (0.02 is POST) 2379 Options 2380 Option (Uri-Path) 2381 Option Delta = 0xb (option nr = 11) 2382 Option Length = 0x1 2383 Option Value = "b" 2384 Option (Uri-Path) 2385 Option Delta = 0x0 (option nr = 11) 2386 Option Length = 0x2 2387 Option Value = "es" 2388 Option (Content-Format) 2389 Option Delta = 0x1 (option nr = 12) 2390 Option Length = 0x1 2391 Option Value = 60 (application/cbor) 2392 Payload Marker = 0xFF 2393 Payload = 2395 The Uri-Host and Uri-Port Options are omitted because they coincide 2396 with the transport protocol destination address and port 2397 respectively. TBD - Show the binary CBOR payload of this example. 2399 A 2.04 Changed response from the Registrar will then be: 2401 2.04 Changed 2403 With CoAP fields: 2405 Ver=1 2406 T=2 (ACK) 2407 Code = 0x44 (2.04 Changed) 2409 B.2. voucher_status 2411 A coaps voucher_status message can be: 2413 POST coaps://[2001:db8::2:1]:61616/b/vs 2414 Content-Format: 60 (application/cbor) 2415 Payload = 2416 a46776657273696f6e0166737461747573f466726561736f6e7828496e66 2417 6f726d61746976652068756d616e2d7265616461626c65206572726f7220 2418 6d6573736167656e726561736f6e2d636f6e74657874a100764164646974 2419 696f6e616c20696e666f726d6174696f6e 2420 2422 The request payload above is binary CBOR but represented here in 2423 hexadecimal for readability. Below is the equivalent CBOR diagnostic 2424 format. 2426 {"version": 1, "status": false, 2427 "reason": "Informative human-readable error message", 2428 "reason-context": { 0: "Additional information" } } 2430 2432 A 2.04 Changed response without payload will then be sent by the 2433 Registrar back to the Pledge. 2435 2.04 Changed 2437 Appendix C. COSE examples 2439 These examples are generated on a Pi 4 and a PC running BASH. Keys 2440 and Certificates have been generated with openssl with the following 2441 shell script: 2443 #!/bin/bash 2444 #try-cert.sh 2445 export dir=./brski/intermediate 2446 export cadir=./brski 2447 export cnfdir=./conf 2448 export format=pem 2449 export default_crl_days=30 2450 sn=8 2452 DevID=pledge.1.2.3.4 2453 serialNumber="serialNumber=$DevID" 2454 export hwType=1.3.6.1.4.1.6715.10.1 2455 export hwSerialNum=01020304 # Some hex 2456 export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" 2457 echo $hwType - $hwSerialNum 2458 echo $serialNumber 2459 OPENSSL_BIN="openssl" 2461 # remove all files 2462 rm -r ./brski/* 2463 # 2464 # initialize file structure 2465 # root level 2466 cd $cadir 2467 mkdir certs crl csr newcerts private 2468 chmod 700 private 2469 touch index.txt 2470 touch serial 2471 echo 11223344556600 >serial 2472 echo 1000 > crlnumber 2473 # intermediate level 2474 mkdir intermediate 2475 cd intermediate 2476 mkdir certs crl csr newcerts private 2477 chmod 700 private 2478 touch index.txt 2479 echo 11223344556600 >serial 2480 echo 1000 > crlnumber 2481 cd ../.. 2483 # file structure is cleaned start filling 2485 echo "#############################" 2486 echo "create registrar keys and certificates " 2487 echo "#############################" 2489 echo "create root registrar certificate using ecdsa with sha 256 key" 2490 $OPENSSL_BIN ecparam -name prime256v1 -genkey \ 2491 -noout -out $cadir/private/ca-regis.key 2493 $OPENSSL_BIN req -new -x509 \ 2494 -config $cnfdir/openssl-regis.cnf \ 2495 -key $cadir/private/ca-regis.key \ 2496 -out $cadir/certs/ca-regis.crt \ 2497 -extensions v3_ca\ 2498 -days 365 \ 2499 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \ 2500 /CN=registrar.stok.nl" 2502 # Combine authority certificate and key 2503 echo "Combine authority certificate and key" 2504 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2505 -inkey $cadir/private/ca-regis.key \ 2506 -in $cadir/certs/ca-regis.crt -export \ 2507 -out $cadir/certs/ca-regis-comb.pfx 2509 # converteer authority pkcs12 file to pem 2510 echo "converteer authority pkcs12 file to pem" 2511 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2512 -in $cadir/certs/ca-regis-comb.pfx \ 2513 -out $cadir/certs/ca-regis-comb.crt -nodes 2515 #show certificate in registrar combined certificate 2516 $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text 2518 # 2519 # Certificate Authority for MASA 2520 # 2521 echo "#############################" 2522 echo "create MASA keys and certificates " 2523 echo "#############################" 2525 echo "create root MASA certificate using ecdsa with sha 256 key" 2526 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 2527 -out $cadir/private/ca-masa.key 2529 $OPENSSL_BIN req -new -x509 \ 2530 -config $cnfdir/openssl-masa.cnf \ 2531 -days 1000 -key $cadir/private/ca-masa.key \ 2532 -out $cadir/certs/ca-masa.crt \ 2533 -extensions v3_ca\ 2534 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\ 2535 /CN=masa.stok.nl" 2537 # Combine authority certificate and key 2538 echo "Combine authority certificate and key for masa" 2539 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2540 -inkey $cadir/private/ca-masa.key \ 2541 -in $cadir/certs/ca-masa.crt -export \ 2542 -out $cadir/certs/ca-masa-comb.pfx 2544 # converteer authority pkcs12 file to pem for masa 2545 echo "converteer authority pkcs12 file to pem for masa" 2546 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2547 -in $cadir/certs/ca-masa-comb.pfx \ 2548 -out $cadir/certs/ca-masa-comb.crt -nodes 2550 #show certificate in pledge combined certificate 2551 $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text 2553 # 2554 # Certificate for Pledge derived from MASA certificate 2555 # 2556 echo "#############################" 2557 echo "create pledge keys and certificates " 2558 echo "#############################" 2560 # Pledge derived Certificate 2562 echo "create pledge derived certificate using ecdsa with sha 256 key" 2563 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 2564 -out $dir/private/pledge.key 2566 echo "create pledge certificate request" 2567 $OPENSSL_BIN req -nodes -new -sha256 \ 2568 -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ 2569 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ 2570 /CN=uuid:$DevID/$serialNumber" 2572 # Sign pledge derived Certificate 2573 echo "sign pledge derived certificate " 2574 $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \ 2575 -extensions 8021ar_idevid\ 2576 -days 365 -in $dir/csr/pledge.csr \ 2577 -out $dir/certs/pledge.crt 2579 # Add pledge key and pledge certificate to pkcs12 file 2580 echo "Add derived pledge key and derived pledge \ 2581 certificate to pkcs12 file" 2582 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2583 -inkey $dir/private/pledge.key \ 2584 -in $dir/certs/pledge.crt -export \ 2585 -out $dir/certs/pledge-comb.pfx 2587 # converteer pledge pkcs12 file to pem 2588 echo "converteer pledge pkcs12 file to pem" 2589 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2590 -in $dir/certs/pledge-comb.pfx \ 2591 -out $dir/certs/pledge-comb.crt -nodes 2593 #show certificate in pledge-comb.crt 2594 $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text 2596 #show private key in pledge-comb.crt 2597 $OPENSSL_BIN ecparam -name prime256v1\ 2598 -in $dir/certs/pledge-comb.crt -text 2599 2601 The xxxx-comb certificates have been generated as required by libcoap 2602 for the DTLS connection generation. 2604 C.1. Pledge, Registrar and MASA keys 2606 This first section documents the public and private keys used in the 2607 subsequent test vectors below. These keys come from test code and 2608 are not used in any production system, and should only be used only 2609 to validate implementations. 2611 C.1.1. Pledge private key 2613 Private-Key: (256 bit) 2614 priv: 2615 9b:4d:43:b6:a9:e1:7c:04:93:45:c3:13:d9:b5:f0: 2616 41:a9:6a:9c:45:79:73:b8:62:f1:77:03:3a:fc:c2: 2617 9c:9a 2618 pub: 2619 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 2620 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 2621 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 2622 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 2623 60:eb:95:5c:54 2624 ASN1 OID: prime256v1 2625 NIST CURVE: P-256 2626 2628 C.1.2. Registrar private key 2629 Private-Key: (256 bit) 2630 priv: 2631 81:df:bb:50:a3:45:58:06:b5:56:3b:46:de:f3:e9: 2632 e9:00:ae:98:13:9e:2f:36:68:81:fc:d9:65:24:fb: 2633 21:7e 2634 pub: 2635 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2636 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2637 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2638 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2639 3e:d0:2d:c7:b7 2640 ASN1 OID: prime256v1 2641 NIST CURVE: P-256 2642 2644 C.1.3. MASA private key 2646 Private-Key: (256 bit) 2647 priv: 2648 c6:bb:a5:8f:b6:d3:c4:75:28:d8:d3:d9:46:c3:31: 2649 83:6d:00:0a:9a:38:ce:22:5c:e9:d9:ea:3b:98:32: 2650 ec:31 2651 pub: 2652 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2653 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2654 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2655 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2656 ed:f3:17:5c:f1 2657 ASN1 OID: prime256v1 2658 NIST CURVE: P-256 2659 2661 C.2. Pledge, Registrar and MASA certificates 2663 Below the certificates that accompany the keys. The certificate 2664 description is followed by the hexadecimal DER of the certificate 2666 C.2.1. Pledge IDevID certificate 2667 Certificate: 2668 Data: 2669 Version: 3 (0x2) 2670 Serial Number: 4822678189204992 (0x11223344556600) 2671 Signature Algorithm: ecdsa-with-SHA256 2672 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturer, 2673 CN=masa.stok.nl 2674 Validity 2675 Not Before: Dec 9 10:02:36 2020 GMT 2676 Not After : Dec 31 23:59:59 9999 GMT 2677 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturing, 2678 CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4 2679 Subject Public Key Info: 2680 Public Key Algorithm: id-ecPublicKey 2681 Public-Key: (256 bit) 2682 pub: 2683 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 2684 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 2685 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 2686 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 2687 60:eb:95:5c:54 2688 ASN1 OID: prime256v1 2689 NIST CURVE: P-256 2690 X509v3 extensions: 2691 X509v3 Basic Constraints: 2692 CA:FALSE 2693 X509v3 Authority Key Identifier: 2694 keyid: 2695 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2697 Signature Algorithm: ecdsa-with-SHA256 2698 30:46:02:21:00:d2:e6:45:3b:b0:c3:00:b3:25:8d:f1:83:fe: 2699 d9:37:c1:a2:49:65:69:7f:6b:b9:ef:2c:05:07:06:31:ac:17: 2700 bd:02:21:00:e2:ce:9e:7b:7f:74:50:33:ad:9e:ff:12:4e:e9: 2701 a6:f3:b8:36:65:ab:7d:80:bb:56:88:bc:03:1d:e5:1e:31:6f 2703 2705 This is the hexadecimal representation in (request-)voucher examples 2706 referred to as pledge-cert-hex. 2708 30820226308201cba003020102020711223344556600300a06082a8648ce3d04 2709 0302306f310b3009060355040613024e4c310b300906035504080c024e423110 2710 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 2711 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 2712 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323031323039313030 2713 3233365a180f39393939313233313233353935395a308190310b300906035504 2714 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 2715 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 2716 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 2717 3a706c656467652e312e322e332e34311730150603550405130e706c65646765 2718 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 2719 420004d6b76f7488bd80ae5f28412c7202ef5f98b481e1d9104cf81b66d43e5c 2720 eada73e6a838a9f1351185b6cde20410befed50b3b14692ee1b06abc554060eb 2721 955c54a32e302c30090603551d1304023000301f0603551d23041830168014e4 2722 0393b4c3d3f42a80a47718f6964903011768a3300a06082a8648ce3d04030203 2723 49003046022100d2e6453bb0c300b3258df183fed937c1a24965697f6bb9ef2c 2724 05070631ac17bd022100e2ce9e7b7f745033ad9eff124ee9a6f3b83665ab7d80 2725 bb5688bc031de51e316f 2727 C.2.2. Registrar Certificate 2728 Certificate: 2729 Data: 2730 Version: 3 (0x2) 2731 Serial Number: 2732 70:56:ea:aa:30:66:d8:82:6a:55:5b:90:88:d4:62:bf:9c:f2:8c:fd 2733 Signature Algorithm: ecdsa-with-SHA256 2734 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 2735 CN=registrar.stok.nl 2736 Validity 2737 Not Before: Dec 9 10:02:36 2020 GMT 2738 Not After : Dec 9 10:02:36 2021 GMT 2739 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 2740 CN=registrar.stok.nl 2741 Subject Public Key Info: 2742 Public Key Algorithm: id-ecPublicKey 2743 Public-Key: (256 bit) 2744 pub: 2745 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2746 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2747 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2748 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2749 3e:d0:2d:c7:b7 2750 ASN1 OID: prime256v1 2751 NIST CURVE: P-256 2752 X509v3 extensions: 2753 X509v3 Subject Key Identifier: 2754 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2755 X509v3 Authority Key Identifier: 2756 keyid: 2757 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2759 X509v3 Basic Constraints: critical 2760 CA:TRUE 2761 X509v3 Extended Key Usage: 2762 CMC Registration Authority, TLS Web Server 2763 Authentication, TLS Web Client Authentication 2764 X509v3 Key Usage: critical 2765 Digital Signature, Non Repudiation, Key Encipherment, 2766 Data Encipherment, Certificate Sign, CRL Sign 2767 Signature Algorithm: ecdsa-with-SHA256 2768 30:44:02:20:74:4c:99:00:85:13:b2:f1:bc:fd:f9:02:1a:46: 2769 fb:17:4c:f8:83:a2:7c:a1:d9:3f:ae:ac:f3:1e:4e:dd:12:c6: 2770 02:20:11:47:14:db:f5:1a:5e:78:f5:81:b9:42:1c:6e:47:02: 2771 ab:53:72:70:c5:ba:fb:2d:16:c3:de:9a:a1:82:c3:5f 2773 2774 This the hexadecimal representation, in (request-)voucher examples 2775 referred to as regis-cert-hex 2777 308202753082021ca00302010202147056eaaa3066d8826a555b9088d462bf9c 2778 f28cfd300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 2779 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2780 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 2781 73756c74616e6379311a301806035504030c117265676973747261722e73746f 2782 6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030 2783 3233365a3073310b3009060355040613024e4c310b300906035504080c024e42 2784 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 2785 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 2786 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 2787 8648ce3d020106082a8648ce3d03010703420004507ac8491a8c69c7b5c31d03 2788 09ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b8934021898d 2789 a789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d 2790 0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d23 2791 04183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d 2792 130101ff040530030101ff30270603551d250420301e06082b0601050507031c 2793 06082b0601050507030106082b06010505070302300e0603551d0f0101ff0404 2794 030201f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 2795 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf51a5e 2796 78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f 2798 C.2.3. MASA Certificate 2800 Certificate: 2801 Data: 2802 Version: 3 (0x2) 2803 Serial Number: 2804 14:26:b8:1c:ce:d8:c3:e8:14:05:cb:87:67:0d:be:ef:d5:81:25:b4 2805 Signature Algorithm: ecdsa-with-SHA256 2806 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 2807 OU=manufacturer, CN=masa.stok.nl 2809 Validity 2810 Not Before: Dec 9 10:02:36 2020 GMT 2811 Not After : Sep 5 10:02:36 2023 GMT 2812 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 2813 OU=manufacturer, CN=masa.stok.nl 2814 Subject Public Key Info: 2815 Public Key Algorithm: id-ecPublicKey 2816 Public-Key: (256 bit) 2817 pub: 2818 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2819 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2820 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2821 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2823 ed:f3:17:5c:f1 2824 ASN1 OID: prime256v1 2825 NIST CURVE: P-256 2826 X509v3 extensions: 2827 X509v3 Subject Key Identifier: 2828 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2829 X509v3 Authority Key Identifier: 2830 keyid: 2831 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2833 X509v3 Basic Constraints: critical 2834 CA:TRUE 2835 X509v3 Extended Key Usage: 2836 CMC Registration Authority, 2837 TLS Web Server Authentication, 2838 TLS Web Client Authentication 2839 X509v3 Key Usage: critical 2840 Digital Signature, Non Repudiation, Key Encipherment, 2841 Data Encipherment, Certificate Sign, CRL Sign 2842 Signature Algorithm: ecdsa-with-SHA256 2843 30:44:02:20:2e:c5:f2:24:72:70:20:ea:6e:74:8b:13:93:67: 2844 8a:e6:fe:fb:8d:56:7f:f5:34:18:a9:ef:a5:0f:c3:99:ca:53: 2845 02:20:3d:dc:91:d0:e9:6a:69:20:01:fb:e4:20:40:de:7c:7d: 2846 98:ed:d8:84:53:61:84:a7:f9:13:06:4c:a9:b2:8f:5c 2848 2850 This is the hexadecimal representation, in (request-)voucher examples 2851 referred to as masa-cert-hex. 2853 3082026d30820214a00302010202141426b81cced8c3e81405cb87670dbeefd5 2854 8125b4300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 2855 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2856 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 2857 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 2858 301e170d3230313230393130303233365a170d3233303930353130303233365a 2859 306f310b3009060355040613024e4c310b300906035504080c024e423110300e 2860 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 2861 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 2862 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 2863 2a8648ce3d0301070342000459809466149420303c6608855586dbe7d4d1d77a 2864 d2a31a0c736b010d021215d61ff36ec8d48460433b21c583801efce237857797 2865 94d4aa34b5b6c6edf3175cf1a3818d30818a301d0603551d0e04160414e40393 2866 b4c3d3f42a80a47718f6964903011768a3301f0603551d23041830168014e403 2867 93b4c3d3f42a80a47718f6964903011768a3300f0603551d130101ff04053003 2868 0101ff30270603551d250420301e06082b0601050507031c06082b0601050507 2869 030106082b06010505070302300e0603551d0f0101ff0404030201f6300a0608 2870 2a8648ce3d040302034700304402202ec5f224727020ea6e748b1393678ae6fe 2871 fb8d567ff53418a9efa50fc399ca5302203ddc91d0e96a692001fbe42040de7c 2872 7d98edd884536184a7f913064ca9b28f5c 2874 C.3. COSE signed voucher request from Pledge to Registrar 2876 In this example the voucher request has been signed by the Pledge, 2877 and has been sent to the JRC over CoAPS. The Pledge uses the 2878 proximity assertion together with an included proximity-registrar- 2879 cert field to inform MASA about its proximity to the specific 2880 Registrar. 2882 POST coaps://registrar.example.com/b/rv 2883 (Content-Format: application/voucher-cose+cbor) 2884 signed_request_voucher 2886 The payload signed_request_voucher is shown as hexadecimal dump (with 2887 lf added): 2889 d28444a101382ea104582097113db094eee8eae48683e7337875c0372164 2890 be89d023a5f3df52699c0fbfb55902d2a11909c5a60274323032302d3132 2891 2d32335431323a30353a32325a0474323032322d31322d32335431323a30 2892 353a32325a01020750684ca83e27230aff97630cf2c1ec409a0d6e706c65 2893 6467652e312e322e332e340a590279308202753082021ca0030201020214 2894 7056eaaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d04 2895 03023073310b3009060355040613024e4c310b300906035504080c024e42 2896 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76 2897 616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e63 2898 79311a301806035504030c117265676973747261722e73746f6b2e6e6c30 2899 1e170d3230313230393130303233365a170d323131323039313030323336 2900 5a3073310b3009060355040613024e4c310b300906035504080c024e4231 2901 10300e06035504070c0748656c6d6f6e6431133011060355040a0c0a7661 2902 6e64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379 2903 311a301806035504030c117265676973747261722e73746f6b2e6e6c3059 2904 301306072a8648ce3d020106082a8648ce3d03010703420004507ac8491a 2905 8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6beb 2906 b94e02b8934021898da789c711cea71339f50e348edf0d923ed02dc7b7a3 2907 818d30818a301d0603551d0e0416041408c2bf36887f79412185872f16a7 2908 aca6efb3d2b3301f0603551d2304183016801408c2bf36887f7941218587 2909 2f16a7aca6efb3d2b3300f0603551d130101ff040530030101ff30270603 2910 551d250420301e06082b0601050507031c06082b0601050507030106082b 2911 06010505070302300e0603551d0f0101ff0404030201f6300a06082a8648 2912 ce3d04030203470030440220744c99008513b2f1bcfdf9021a46fb174cf8 2913 83a27ca1d93faeacf31e4edd12c60220114714dbf51a5e78f581b9421c6e 2914 4702ab537270c5bafb2d16c3de9aa182c35f58473045022063766c7bbd1b 2915 339dbc398e764af3563e93b25a69104befe9aac2b3336b8f56e1022100cd 2916 0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f2991484 2917 e9 2918 2920 The representiation of signed_voucher_request in CBOR diagnostic 2921 format is: 2923 Diagnose(signed_request_voucher) = 2924 18([ 2925 h'A101382E', // {"alg": -47} 2926 {4: h'97113DB094EEE8EAE48683E7337875C0372164B 2927 E89D023A5F3DF52699C0FBFB5'}, 2928 h'1234', // request_voucher 2929 h'3045022063766C7BBD1B339DBC398E764AF3563E93B 2930 25A69104BEFE9AAC2B3336B8F56E1022100CD0419559A 2931 D960CCAED4DEE3F436ECA40B7570B25A52EB60332BC1F 2932 2991484E9' 2933 ]) 2935 Diagnose(request_voucher) = 2936 {2501: {2: "2020-12-23T12:05:22Z", 2937 4: "2022-12-23T12:05:22Z", 2938 1: 2, 2939 7: h'684CA83E27230AFF97630CF2C1EC409A', 2940 13: "pledge.1.2.3.4", 2941 10: h'1234' // regis-cert-hex 2942 }} 2943 2945 C.4. COSE signed voucher request from Registrar to MASA 2947 TBD - modify example to use full paths to MASA, not short-names. 2948 Also not use CoAP but HTTP protocol. 2950 In this example the voucher request has been signed by the JRC using 2951 the private key from Appendix C.1.2. Contained within this voucher 2952 request is the voucher request from the Pledge to JRC. 2954 POST coaps://masa.example.com/b/rv 2955 (Content-Format: application/voucher-cose+cbor) 2956 signed_masa_request_voucher 2958 The payload signed_masa_voucher_request is shown as hexadecimal dump 2959 (with lf added): 2961 d28444a101382ea1045820e8735bc4b470c3aa6a7aa9aa8ee584c09c1113 2962 1b205efec5d0313bad84c5cd05590414a11909c5a60274323032302d3132 2963 2d32385431303a30333a33355a0474323032322d31322d32385431303a30 2964 333a33355a07501551631f6e0416bd162ba53ea00c2a050d6e706c656467 2965 652e312e322e332e3405587131322d32385431303a30333a33355a075015 2966 51631f6e0416bd162ba53ea00c2a050d6e706c656467652e312e322e332e 2967 3405587131322d32385431303a300000000000000000000000000416bd16 2968 2ba53ea00c2a050d6e706c656467652e312e322e332e3405587131322d32 2969 385431303a09590349d28444a101382ea104582097113db094eee8eae486 2970 83e7337875c0372164be89d023a5f3df52699c0fbfb55902d2a11909c5a6 2971 0274323032302d31322d32385431303a30333a33355a0474323032322d31 2972 322d32385431303a30333a33355a010207501551631f6e0416bd162ba53e 2973 a00c2a050d6e706c656467652e312e322e332e340a590279308202753082 2974 021ca00302010202147056eaaa3066d8826a555b9088d462bf9cf28cfd30 2975 0a06082a8648ce3d0403023073310b3009060355040613024e4c310b3009 2976 06035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2977 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b63 2978 6f6e73756c74616e6379311a301806035504030c11726567697374726172 2979 2e73746f6b2e6e6c301e170d3230313230393130303233365a170d323131 2980 3230393130303233365a3073310b3009060355040613024e4c310b300906 2981 035504080c024e423110300e06035504070c0748656c6d6f6e6431133011 2982 060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f 2983 6e73756c74616e6379311a301806035504030c117265676973747261722e 2984 73746f6b2e6e6c3059301306072a8648ce3d020106082a8648ce3d030107 2985 03420004507ac8491a8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018 2986 154fa059b020ec6bebb94e02b8934021898da789c711cea71339f50e348e 2987 df0d923ed02dc7b7a3818d30818a301d0603551d0e0416041408c2bf3688 2988 7f79412185872f16a7aca6efb3d2b3301f0603551d2304183016801408c2 2989 bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff0405 2990 30030101ff30270603551d250420301e06082b0601050507031c06082b06 2991 01050507030106082b06010505070302300e0603551d0f0101ff04040302 2992 01f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 2993 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf5 2994 1a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f584730 2995 45022063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3 2996 336b8f56e1022100cd0419559ad960ccaed4dee3f436eca40b7570b25a52 2997 eb60332bc1f2991484e958473045022100e6b45558c1b806bba23f4ac626 2998 c9bdb6fd354ef4330d8dfb7c529f29cca934c802203c1f2ccbbac89733d1 2999 7ee7775bc2654c5f1cc96afba2741cc31532444aa8fed8 3001 3003 The representiation of signed_masa_voucher_request in CBOR diagnostic 3004 format is: 3006 Diagnose(signed_registrar_request-voucher) 3007 18([ 3008 h'A101382E', // {"alg": -47} 3009 h'E8735BC4B470C3AA6A7AA9AA8EE584C09C11131B205EFEC5D0313BAD84 3010 C5CD05'}, 3011 h'1234', // registrar_request_voucher', 3012 h'3045022100E6B45558C1B806BBA23F4AC626C9BDB6FD354EF4330D8DFB 3013 7C529F29CCA934C802203C1F2CCBBAC89733D17EE7775BC2654C5F1CC96A 3014 FBA2741CC31532444AA8FED8' 3015 ]) 3017 Diagnose(registrar_request_voucher) 3018 {2501: 3019 {2: "2020-12-28T10:03:35Z", 3020 4: "2022-12-28T10:03:35Z", 3021 7: h'1551631F6E0416BD162BA53EA00C2A05', 3022 13: "pledge.1.2.3.4", 3023 5: h'31322D32385431303A30333A33355A07501551631F6E0416BD 3024 162BA53EA00C2A050D6E706C656467652E312E322E332E3405 3025 587131322D32385431303A3000000000000000000000000004 3026 16BD162BA53EA00C2A050D6E706C656467652E312E322E332E 3027 3405587131322D32385431303A', 3028 9: h'1234' // signature 3029 }} 3030 3032 C.5. COSE signed voucher from MASA to Pledge via Registrar 3034 The resulting voucher is created by the MASA and returned via the JRC 3035 to the Pledge. It is signed by the MASA's private key Appendix C.1.3 3036 and can be verified by the Pledge using the MASA's public key 3037 contained within the MASA certificate. 3039 This is the raw binary signed_voucher, encoded in hexadecimal (with 3040 lf added): 3042 d28444a101382ea104582039920a34ee92d3148ab3a729f58611193270c9 3043 029f7784daf112614b19445d5158cfa1190993a70274323032302d31322d 3044 32335431353a30333a31325a0474323032302d31322d32335431353a3233 3045 3a31325a010007506508e06b2959d5089d7a3169ea889a490b6e706c6564 3046 67652e312e322e332e340858753073310b3009060355040613024e4c310b 3047 300906035504080c024e423110300e06035504070c0748656c6d6f6e6431 3048 133011060355040a0c0a76616e64657273746f6b31143012060355040b0c 3049 0b636f6e73756c74616e6379311a301806035504030c1172656769737472 3050 61722e73746f6b2e6e6c03f458473045022022515d96cd12224ee5d3ac67 3051 3237163bba24ad84815699285d9618f463ee73fa022100a6bff9d8585c1c 3052 9256371ece94da3d26264a5dfec0a354fe7b3aef58344c512f 3054 3056 The representiation of signed_voucher in CBOR diagnostic format is: 3058 Diagnose(signed_voucher) = 3059 18([ 3060 h'A101382E', # {"alg": -47} 3061 {4: h'39920A34EE92D3148AB3A729F58611193270C9029F7784DAF112614B194 3062 45D51'}, 3063 h'voucher', 3064 h'3045022022515D96CD12224EE5D3AC673237163BBA24AD84815699285D9618F 3065 463EE73FA022100A6BFF9D8585C1C9256371ECE94DA3D26264A5DFEC0A354FE7B 3066 3AEF58344C512F' 3067 ]) 3069 Diagnose(voucher) = 3070 {2451: 3071 {2: "2020-12-23T15:03:12Z", 3072 4: "2020-12-23T15:23:12Z", 3073 1: 0, 3074 7: h'6508E06B2959D5089D7A3169EA889A49', 3075 11: "pledge.1.2.3.4", 3076 8: h'regis-cert-hex', 3077 3: false}} 3078 3080 Contributors 3082 Russ Housley 3084 Email: housley@vigilsec.com 3086 Authors' Addresses 3087 Michael Richardson 3088 Sandelman Software Works 3090 Email: mcr+ietf@sandelman.ca 3092 Peter van der Stok 3093 vanderstok consultancy 3095 Email: stokcons@bbhmail.nl 3097 Panos Kampanakis 3098 Cisco Systems 3100 Email: pkampana@cisco.com 3102 Esko Dijk 3103 IoTconsultancy.nl 3105 Email: esko.dijk@iotconsultancy.nl