idnits 2.17.00 (12 Aug 2021) /tmp/idnits21041/draft-ietf-anima-constrained-voucher-17.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 is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document updates RFC8366, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8995, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1342 has weird spacing: '...ndatory false...' == Line 1346 has weird spacing: '...ndatory false...' == Line 1592 has weird spacing: '...ndatory false...' == Line 1596 has weird spacing: '...ndatory false...' -- The document date (7 April 2022) is 37 days in the past. Is this intentional? 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: 'This RFC' is mentioned on line 2255, but not defined == Unused Reference: 'RFC5280' is defined on line 2388, but no explicit reference was found in the text == Outdated reference: draft-ietf-ace-coap-est has been published as RFC 9148 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-19 ** 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' == Outdated reference: A later version (-10) exists of draft-ietf-anima-constrained-join-proxy-09 == Outdated reference: A later version (-13) exists of draft-ietf-lake-edhoc-12 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 5 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: 9 October 2022 P. Kampanakis 7 Cisco Systems 8 E. Dijk 9 IoTconsultancy.nl 10 7 April 2022 12 Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) 13 draft-ietf-anima-constrained-voucher-17 15 Abstract 17 This document defines the Constrained Bootstrapping Remote Secure Key 18 Infrastructure (Constrained BRSKI) protocol, which provides a 19 solution for secure zero-touch bootstrapping of resource-constrained 20 (IoT) devices into the network of a domain owner. This protocol is 21 designed for constrained networks, which may have limited data 22 throughput or may experience frequent packet loss. Constrained BRSKI 23 is a variant of the BRSKI protocol, which uses an artifact signed by 24 the device manufacturer called the "voucher" which enables a new 25 device and the owner's network to mutually authenticate. While the 26 BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines 27 a compact CBOR-encoded voucher. The BRSKI voucher is extended with 28 new data types that allow for smaller voucher sizes. The Enrollment 29 over Secure Transport (EST) protocol, used in BRSKI, is replaced with 30 EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 9 October 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 68 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 6 69 5. Updates to RFC8366 and RFC8995 . . . . . . . . . . . . . . . 7 70 6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Registrar and the Server Name Indicator (SNI) . . . . . . 8 72 6.2. TLS Client Certificates: IDevID authentication . . . . . 9 73 6.3. Discovery, URIs and Content Formats . . . . . . . . . . . 10 74 6.3.1. RFC8995 Telemetry Returns . . . . . . . . . . . . . . 12 75 6.4. Join Proxy options . . . . . . . . . . . . . . . . . . . 13 76 6.5. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 13 77 6.5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 13 78 6.5.2. CoAP responses . . . . . . . . . . . . . . . . . . . 13 79 6.6. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 14 80 6.6.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 15 81 6.6.2. EST-client Extensions . . . . . . . . . . . . . . . . 16 82 6.6.3. Registrar Extensions . . . . . . . . . . . . . . . . 18 83 6.7. DTLS handshake fragmentation Considerations . . . . . . . 19 84 7. BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . . 19 85 7.1. Protocol and Formats . . . . . . . . . . . . . . . . . . 19 86 7.2. Registrar Voucher Request . . . . . . . . . . . . . . . . 20 87 7.3. MASA and the Server Name Indicator (SNI) . . . . . . . . 20 88 7.3.1. Registrar Certificate Requirement . . . . . . . . . . 21 89 8. Pinning in Voucher Artifacts . . . . . . . . . . . . . . . . 21 90 8.1. Registrar Identity Selection and Encoding . . . . . . . . 21 91 8.2. MASA Pinning Policy . . . . . . . . . . . . . . . . . . . 23 92 8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 24 93 8.4. Considerations for use of IDevID-Issuer . . . . . . . . . 25 94 9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 26 96 9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 26 97 9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 27 98 9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 28 99 9.1.4. Example voucher request artifact . . . . . . . . . . 32 100 9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 32 101 9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32 102 9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 33 103 9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 33 104 9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 36 105 9.3. Signing voucher and voucher-request artifacts with 106 COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 37 107 10. Deployment-specific Discovery Considerations . . . . . . . . 38 108 10.1. 6TSCH Deployments . . . . . . . . . . . . . . . . . . . 39 109 10.2. Generic networks using GRASP . . . . . . . . . . . . . . 39 110 10.3. Generic networks using mDNS . . . . . . . . . . . . . . 39 111 10.4. Thread networks using Mesh Link Establishment (MLE) . . 39 112 10.5. Non-mesh networks using CoAP Discovery . . . . . . . . . 40 113 11. Design Considerations . . . . . . . . . . . . . . . . . . . . 40 114 12. Raw Public Key Use Considerations . . . . . . . . . . . . . . 40 115 12.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 40 116 12.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 41 117 12.3. The Voucher Response . . . . . . . . . . . . . . . . . . 41 118 13. Use of constrained vouchers with HTTPS . . . . . . . . . . . 41 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 42 120 14.1. Duplicate serial-numbers . . . . . . . . . . . . . . . . 42 121 14.2. IDevID security in Pledge . . . . . . . . . . . . . . . 43 122 14.3. Security of CoAP and UDP protocols . . . . . . . . . . . 44 123 14.4. Registrar Certificate may be self-signed . . . . . . . . 45 124 14.5. Use of RPK alternatives to proximity-registrar-cert . . 45 125 14.6. MASA support of CoAPS . . . . . . . . . . . . . . . . . 46 126 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 127 15.1. Resource Type Registry . . . . . . . . . . . . . . . . . 46 128 15.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 47 129 15.3. The YANG Module Names Registry . . . . . . . . . . . . . 47 130 15.4. The RFC SID range assignment sub-registry . . . . . . . 47 131 15.5. Media Types Registry . . . . . . . . . . . . . . . . . . 48 132 15.5.1. application/voucher-cose+cbor . . . . . . . . . . . 48 133 15.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 48 134 15.7. Update to BRSKI Parameters Registry . . . . . . . . . . 49 135 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 136 17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 50 137 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 138 18.1. Normative References . . . . . . . . . . . . . . . . . . 50 139 18.2. Informative References . . . . . . . . . . . . . . . . . 54 140 Appendix A. Library Support for BRSKI . . . . . . . . . . . . . 56 141 A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 57 142 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 58 143 Appendix B. Constrained BRSKI-EST Message Examples . . . . . . . 59 144 B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 59 145 B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 60 146 Appendix C. COSE-signed Voucher (Request) Examples . . . . . . . 61 147 C.1. Pledge, Registrar and MASA Keys . . . . . . . . . . . . . 61 148 C.1.1. Pledge IDevID private key . . . . . . . . . . . . . . 61 149 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 61 150 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 62 151 C.2. Pledge, Registrar and MASA Certificates . . . . . . . . . 62 152 C.2.1. Pledge IDevID Certificate . . . . . . . . . . . . . . 62 153 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 64 154 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 66 155 C.3. COSE-signed Pledge Voucher Request (PVR) . . . . . . . . 68 156 C.4. COSE-signed Registrar Voucher Request (RVR) . . . . . . . 70 157 C.5. COSE-signed Voucher from MASA . . . . . . . . . . . . . . 72 158 Appendix D. Generating Certificates with OpenSSL . . . . . . . . 74 159 Appendix E. Pledge Device Class Profiles . . . . . . . . . . . . 77 160 E.1. Minimal Pledge . . . . . . . . . . . . . . . . . . . . . 78 161 E.2. Typical Pledge . . . . . . . . . . . . . . . . . . . . . 78 162 E.3. Full-featured Pledge . . . . . . . . . . . . . . . . . . 78 163 E.4. Comparison Chart of Pledge Classes . . . . . . . . . . . 78 164 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 79 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 167 1. Introduction 169 Secure enrollment of new nodes into constrained networks with 170 constrained nodes presents unique challenges. As explained in 171 [RFC7228], the networks are challenged and the nodes are constrained 172 by energy, memory space, and code size. 174 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 175 described in [RFC8995] provides a solution for secure zero-touch 176 (automated) bootstrap of new (unconfigured) devices. In it, new 177 devices, such as IoT devices, are called "pledges", and equipped with 178 a factory-installed Initial Device Identifier (IDevID) (see 179 [ieee802-1AR]), are enrolled into a network. 181 The BRSKI solution described in [RFC8995] was designed to be modular, 182 and this document describes a version scaled to the constraints of 183 IoT deployments. 185 Therefore, this document defines a constrained version of the voucher 186 artifact (described in [RFC8366]), along with a constrained version 187 of BRSKI. This constrained-BRSKI protocol makes use of the 188 constrained CoAP-based version of EST (EST-coaps from 189 [I-D.ietf-ace-coap-est]) rather than the EST over HTTPS [RFC7030]. 190 Constrained-BRSKI is itself scalable to multiple resource levels 191 through the definition of optional functions. Appendix E illustrates 192 this. 194 In BRSKI, the [RFC8366] voucher is by default serialized to JSON with 195 a signature in CMS [RFC5652]. This document defines a new voucher 196 serialization to CBOR [RFC8949] with a signature in COSE 197 [I-D.ietf-cose-rfc8152bis-struct]. 199 This COSE-signed CBOR-encoded voucher is transported using both 200 secured CoAP and HTTPS. The CoAP connection (between Pledge and 201 Registrar) is to be protected by either OSCORE+EDHOC 202 [I-D.ietf-lake-edhoc] or DTLS (CoAPS). The HTTP connection (between 203 Registrar and MASA) is to be protected using TLS (HTTPS). 205 This document specifies a constrained voucher-request artifact based 206 on Section 3 of [RFC8995], and voucher(-request) transport over CoAP 207 based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est]. 209 The CBOR definitions for the constrained voucher format are defined 210 using the mechanism described in [I-D.ietf-core-yang-cbor] using the 211 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 212 convert YANG documents into a list of SID keys is still in its 213 infancy, the table of SID values presented here MUST be considered 214 normative rather than the output of the tool specified in 215 [I-D.ietf-core-sid]. 217 2. Terminology 219 The following terms are defined in [RFC8366], and are used 220 identically as in that document: artifact, domain, imprint, Join 221 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 222 Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and 223 Voucher. 225 The following terms from [RFC8995] are used identically as in that 226 document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, 227 manufacturer, nonced, nonceless, PKIX. 229 The term Pledge Voucher Request, or acronym PVR, is introduced to 230 refer to the voucher request between the pledge and the Registrar. 232 The term Registrar Voucher Request, or acronym RVR, is introduced to 233 refer to the voucher request between the Registrar and the MASA. 235 In code examples, the string "" denotes the start of a 236 code example and "" the end of the code example. Four 237 dots ("....") in a CBOR diagnostic notation byte string denotes a 238 further sequence of bytes that is not shown for brevity. 240 3. Requirements Language 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 244 "OPTIONAL" in this document are to be interpreted as described in 245 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 246 capitals, as shown here. 248 4. Overview of Protocol 250 [RFC8366] provides for vouchers that assert proximity, authenticate 251 the Registrar, and can offer varying levels of anti-replay 252 protection. 254 The proximity proof provided for in [RFC8366], is an assertion that 255 the Pledge and the Registrar are believed to be close together, from 256 a network topology point of view. Like in [RFC8995], proximity is 257 shown by making TLS connections between the Pledge and Registrar 258 using IPv6 Link-Local addresses. 260 The TLS connection is used to make a Voucher Request. This request 261 is verified by an agent of the Pledge's manufacturer, which then 262 issues a voucher. The voucher provides an authorization statement 263 from the manufacturer indicating that the Registrar is the intended 264 owner of the device. The voucher refers to the Registrar through 265 pinning of the Registrar's identity. 267 This document does not make any extensions to the semantic meaning of 268 vouchers, only the encoding has been changed to optimize for 269 constrained devices and networks. The two main parts of the BRSKI 270 protocol are named separately in this document: BRSKI-EST for the 271 protocol between Pledge and Registrar, and BRSKI-MASA for the 272 protocol between the Registrar and the MASA. 274 Time-based vouchers are supported in this definition, but given that 275 constrained devices are extremely unlikely to have accurate time, 276 their use will be uncommon. Most Pledges using constrained vouchers 277 will be online during enrollment and will use live nonces to provide 278 anti-replay protection rather than expiry times. 280 [RFC8366] defines the voucher artifact, while the Voucher Request 281 artifact was defined in [RFC8995]. This document defines both a 282 constrained voucher and a constrained voucher-request. They are 283 presented in the order "voucher-request", followed by a "voucher" 284 response as this is the order that they occur in the protocol. 286 The constrained voucher request MUST be signed by the Pledge. It 287 signs using the private key associated with its IDevID X.509 288 certificate, or if an IDevID is not available, then the private key 289 associated with its manufacturer-installed raw public key (RPK). 290 Section 12 provides additional details on PKIX-less operations. 292 The constrained voucher MUST be signed by the MASA. 294 For the constrained voucher request this document defines two 295 distinct methods for the Pledge to identify the Registrar: using 296 either the Registrar's X.509 certificate, or using a raw public key 297 (RPK) of the Registrar. 299 For the constrained voucher both methods are supported to indicate 300 (pin) a trusted domain identity: using either a pinned domain X.509 301 certificate, or a pinned raw public key (RPK). 303 The BRSKI architectures mandates that the MASA be aware of the 304 capabilities of the pledge. This is not a drawback as the pledges 305 are constructed by a manufacturer which also arranges for the MASA to 306 be aware of the inventory of devices. 308 The MASA therefore knows if the pledge supports PKIX operations, PKIX 309 format certificates, or if the pledge is limited to Raw Public Keys 310 (RPK). Based upon this, the MASA can select which attributes to use 311 in the voucher for certain operations, like the pinning of the 312 Registrar identity. This is described in more detail in 313 Section 9.2.3, Section 8 and Section 8.3 (for RPK specifically). 315 5. Updates to RFC8366 and RFC8995 317 This section details the ways in which this document updates other 318 RFCs. The terminology for Updates is taken from 319 [I-D.kuehlewind-update-tag]. 321 This document Updates [RFC8366]. It Extends [RFC8366] by creating a 322 new serialization format, and creates a mechanism to pin Raw Public 323 Key (RPK). 325 This document Updates [RFC8995]. It Amends [RFC8995] 327 * by clarifying how pinning is done, 329 * adopts clearer explanation of the TLS Server Name Indicator (SNI), 330 see Section 6.1 and Section 7.3 332 * clarifies when new trust anchors should be retrieved 333 (Section 6.6.1), 335 * clarified what kinds of Extended Key Usage attributes are 336 appropriate for each certificate (Section 7.3.1) 338 It Extends [RFC8995] as follows: * defines the CoAP version of the 339 BRSKI protocol 341 * makes some messages optional if the results can be inferred from 342 other validations (Section 6.6), 344 * provides the option to return trust anchors in a simpler format 345 (Section 6.6.3) 347 * extends the BRSKI-MASA protocol to carry the new voucher-cose+cbor 348 format. 350 6. BRSKI-EST Protocol 352 This section describes the constrained BRSKI extensions to EST-coaps 353 [I-D.ietf-ace-coap-est] to transport the voucher between Registrar 354 and Pledge (optionally via a Join Proxy) over CoAP. The extensions 355 are targeting low-resource networks with small packets. 357 The constrained BRSKI-EST protocol described in this section is 358 between the Pledge and the Registrar only. 360 6.1. Registrar and the Server Name Indicator (SNI) 362 A DTLS connection is established between the Pledge and the 363 Registrar, similar to the TLS connection described in Section 5.1 of 364 [RFC8995]. This may occur via a Join Proxy as described in 365 Section 6.4. Regardless of the Join Proxy mechanism, the DTLS 366 connection should operate identically. 368 The SNI issue described below affects [RFC8995] as well, and is 369 reported in errata: https://www.rfc-editor.org/errata/eid6648 371 As the Registrar is discovered by IP address, and typically connected 372 via a Join Proxy, the name of the Registrar is not known to the 373 Pledge. The Pledge will not know what the hostname for the Registrar 374 is, so it cannot do RFC6125 DNS-ID validation on the Registrar's 375 certificate. Instead, it must do validation using the RFC8366 376 voucher. 378 As the Pledge does not know the name of the Registrar, the Pledge 379 cannot put any reasonable value into the [RFC6066] Server Name 380 Indicator (SNI). Threfore the Pledge SHOULD omit the SNI extension 381 as per Section 9.2 of [RFC8446]. 383 In some cases, particularly while testing BRSKI, a Pledge may be 384 given the hostname of a particular Registrar to connect to directly. 385 Such a bypass of the discovery process may result in the Pledge 386 taking a different code branch to establish a DTLS connection, and 387 may result in the SNI being inserted by a library. The Registrar 388 MUST ignore any SNI seen. 390 A primary motivation for making the SNI ubiquitous in the public web 391 is because it allows for multi-tenant hosting of HTTPS sites on a 392 single (scarce) IPv4 address. This consideration does not apply to 393 the server function in the Registrar because: 395 * it uses DTLS and CoAP, not HTTPS 397 * it typically uses IPv6, often [RFC4193] Unique Local Address, 398 which are plentiful 400 * the server port number is typically discovered, so multiple 401 tenants can be accomodated via unique port numbers. 403 As per Section 3.6.1 of [RFC7030], the Registrar certificate MUST 404 have the Extended Key Usage (EKU) id-kp-cmcRA. This certificate is 405 also used as a TLS Server Certificate, so it MUST also have the EKU 406 id-kp-serverAuth. 408 6.2. TLS Client Certificates: IDevID authentication 410 As described in Section 5.1 of [RFC8995], the Pledge makes a 411 connection to the Registrar using a TLS Client Certificate for 412 authentication. 414 Subsequently the Pledge will send a Pledge Voucher Request (PVR). 416 As explained below in Section 8.1, the "x5bag" element may be used in 417 the RVR to communicate identity of the Registrar to MASA. The Pledge 418 SHOULD NOT use the x5bag attribute in this way in the PVR. A 419 Registrar that processes a PVR with an x5bag attribute MUST ignore 420 it, and MUST use only the TLS Client Certificate extension for 421 authentication of the Pledge. 423 A situation where the Pledge MAY use the x5bag is for communication 424 of certificate chains to the MASA. This would arise in some vendor- 425 specific situations involving outsourcing of MASA functionality, or 426 rekeying of the IDevID certification authority. 428 6.3. Discovery, URIs and Content Formats 430 To keep the protocol messages small the EST-coaps and constrained- 431 BRSKI URIs are shorter than the respective EST and BRSKI URIs. 433 The EST-coaps server URIs differ from the EST URIs by replacing the 434 scheme https by coaps and by specifying shorter resource path names. 435 Below are some examples; the first two using a discovered short path 436 name and the last one using the well-known URI of EST which requires 437 no discovery. 439 coaps://server.example.com/est/ 440 coaps://server.example.com/e/ 441 coaps://server.example.com/.well-known/est/ 443 Similarly the constrained BRSKI server URIs differ from the BRSKI 444 URIs by replacing the scheme https by coaps and by specifying shorter 445 resource path names. Below are some examples; the first two using a 446 discovered short path name and the last one using the well-known URI 447 prefix which requires no discovery. This is the same "/.well-known/ 448 brski" prefix as defined in Section 5 of [RFC8995]. 450 coaps://server.example.com/brski/ 451 coaps://server.example.com/b/ 452 coaps://server.example.com/.well-known/brski/ 454 Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations 455 supported by EST, for which Table 1 in Section 5.1 of 456 [I-D.ietf-ace-coap-est] enumerates the corresponding EST-coaps short 457 path names. Similarly, Table 1 below provides the mapping from the 458 supported BRSKI extension URI paths to the constrained-BRSKI URI 459 paths. 461 +=================+============================+ 462 | BRSKI resource | constrained-BRSKI resource | 463 +=================+============================+ 464 | /requestvoucher | /rv | 465 +-----------------+----------------------------+ 466 | /voucher_status | /vs | 467 +-----------------+----------------------------+ 468 | /enrollstatus | /es | 469 +-----------------+----------------------------+ 471 Table 1: BRSKI URI paths mapping to 472 Constrained BRSKI URI paths 474 Note that /requestvoucher indicated above occurs between the Pledge 475 and Registrar (in scope of the BRSKI-EST protocol), but it also 476 occurs between Registrar and MASA. However, as described in 477 Section 6, this section and above table addresses only the BRSKI-EST 478 protocol. 480 Pledges that wish to discover the available BRSKI bootstrap options/ 481 formats, or reduce the size of the CoAP headers by eliminating the 482 "/.well-known/brski" path, can do a discovery operation using 483 [RFC6690] Section 4 by sending a discovery query to the Registrar. 485 For example, if the Registrar supports a short BRSKI URL (/b) and 486 supports the voucher format "application/voucher-cose+cbor" (TBD3), 487 and status reporting in both CBOR and JSON formats: 489 REQ: GET /.well-known/core?rt=brski* 491 RES: 2.05 Content 492 Content-Format: 40 493 Payload: 494 ;rt=brski, 495 ;rt=brski.rv;ct=TBD3, 496 ;rt=brski.vs;ct="50 60", 497 ;rt=brski.es;ct="50 60" 499 The Registrar is under no obligation to provide shorter URLs, and MAY 500 respond to this query with only the "/.well-known/brski/" 501 resources for the short names as defined in Table 1. 503 Registrars that have implemented shorter URLs MUST also respond in 504 equivalent ways to the corresponding "/.well-known/brski/" URLs, and MUST NOT distinguish between them. In particular, a 506 Pledge MAY use the longer and shorter URLs in any combination. 508 When responding to a discovery request for BRSKI resources, the 509 server MAY in addition return the full resource paths and the content 510 types which are supported by these resources as shown in above 511 example. This is useful when multiple content types are specified 512 for a particular resource on the server. The server responds with 513 only the root path for the BRSKI resources (rt=brski, resource /b in 514 above example) and no others in case the client queries for only 515 rt=brski type resources. (So, a query for rt=brski, without the 516 wildcard character.) 518 Without discovery, a longer well-known URL can only be used, such as: 520 REQ: GET /.well-known/brski/rv 522 while with discovery of shorter URLs, a request such as: 524 REQ: GET /b/rv 526 is possible. 528 The return of multiple content-types in the "ct" attribute allows the 529 Pledge to choose the most appropriate one. Note that Content-Format 530 TBD3 ("application/voucher-cose+cbor") is defined in this document. 532 Content-Format TBD3 MUST be supported by the Registrar for the /rv 533 resource. If the "ct" attribute is not indicated for the /rv 534 resource in the link format description, this implies that at least 535 TBD3 is supported. 537 Note that this specification allows for voucher-cose+cbor format 538 requests and vouchers to be transmitted over HTTPS, as well as for 539 voucher-cms+json and other formats yet to be defined over CoAP. The 540 burden for this flexibility is placed upon the Registrar. A Pledge 541 on constrained hardware is expected to support a single format only. 543 The Pledge and MASA need to support one or more formats (at least 544 TBD3) for the voucher and for the voucher request. The MASA needs to 545 support all formats that the Pledge supports. 547 Section 10 details how the Pledge discovers the Registrar and Join 548 Proxy in different deployment scenarios. 550 6.3.1. RFC8995 Telemetry Returns 552 [RFC8995] defines two telemetry returns from the Pledge which are 553 sent to the Registrar. These are the BRSKI Status Telemetry 554 [RFC8995], Section 5.7 and the Enrollment Status Telemetry [RFC8995], 555 Section 5.9.4. These are two POST operations made the by Pledge at 556 two key steps in the process. 558 [RFC8995] defines the content of these POST operations in CDDL, which 559 are serialized as JSON. This document extends the list of acceptable 560 formats to CBOR as well as JSON, using the rules from [RFC8610]. 562 The existing JSON format is described as CoAP Content-Format 50 563 ("application/json"), and it MAY be supported. The new CBOR format 564 described as CoAP Content-Format 60 ("application/cbor"), MUST be 565 supported by the Registrar for both the /vs and /es resources. 567 6.4. Join Proxy options 569 [I-D.ietf-anima-constrained-join-proxy] specifies a constrained Join 570 Proxy that is optionally placed between Pledge and Registrar. This 571 includes methods for discovery of the Join Proxy by the Pledge and 572 discovery of the Registrar by the Join Proxy. 574 6.5. Extensions to BRSKI 576 6.5.1. Discovery 578 The Pledge discovers an IP address and port number that connects to 579 the Registrar (possibly via a Join Proxy), and it establishes a DTLS 580 connection. 582 No further discovery of hosts or port numbers is required, but a 583 pledge that can do more than one kind of enrollment (future work 584 offers protocols other than [I-D.ietf-ace-coap-est]), then a pledge 585 may need to use CoAP Discovery to determine what other protocols are 586 available. 588 A Pledge that only supports the EST-coaps enrollment method SHOULD 589 NOT use discovery for BRSKI resources. It is more efficient to just 590 try the supported enrollment method via the well-known BRSKI/EST- 591 coaps resources. This also avoids the Pledge doing any CoRE Link 592 Format parsing, which is specified in [I-D.ietf-ace-coap-est], 593 Section 4.1. 595 The Registrar MUST support all of the EST resources at their default 596 ".well-known" locations (on the specified port) as well as any 597 server-specific shorter form that might also be supported. 599 However, when discovery is being done by the Pledge, it is possible 600 for the Registrar to return references to resources which are on 601 different port numbers. The Registrar SHOULD NOT use different ports 602 numbers by default, because a Pledge that is connected via a Join 603 Proxy can only access a single UDP port. A Registrar configured to 604 never use Join Proxies MAY be configured to use multiple port 605 numbers. Therefore a Registrar MUST host all discoverable BRSKI 606 resources on the same (UDP) server port that the Pledge's DTLS 607 connection is using. Using the same UDP server port for all 608 resources allows the Pledge to continue via the same DTLS connection 609 which is more efficient. 611 6.5.2. CoAP responses 613 [RFC8995], Section 5 defines a number of HTTP response codes that the 614 Registrar is to return when certain conditions occur. 616 The 401, 403, 404, 406 and 415 response codes map directly to CoAP 617 codes 4.01, 4.03, 4.04, 4.06 and 4.15. 619 The 202 Retry process which occurs in the voucher request, is to be 620 handled in the same way as Section 5.7 of [I-D.ietf-ace-coap-est] 621 process for Delayed Responses. 623 6.6. Extensions to EST-coaps 625 This document extends [I-D.ietf-ace-coap-est], and it inherits the 626 functions described in that document: specifically, the mandatory 627 Simple (Re-)Enrollment (/sen and /sren) and Certification Authority 628 certificates request (/crts). Support for CSR Attributes Request 629 (/att) and server-side key generation (/skg, /skc) remains optional 630 for the EST server. 632 Collecting the resource definitions from both [RFC8995], [RFC7030], 633 and [I-D.ietf-ace-coap-est] results in the following shorter forms of 634 URI paths for the commonly used resources: 636 +=================+=========================+===============+ 637 | BRSKI + EST | Constrained-BRSKI + EST | Well-known | 638 | | | URI namespace | 639 +=================+=========================+===============+ 640 | /requestvoucher | /rv | brski | 641 +-----------------+-------------------------+---------------+ 642 | /voucher_status | /vs | brski | 643 +-----------------+-------------------------+---------------+ 644 | /csrattrs | /att | est | 645 +-----------------+-------------------------+---------------+ 646 | /simpleenroll | /sen | est | 647 +-----------------+-------------------------+---------------+ 648 | /cacerts | /crts | est | 649 +-----------------+-------------------------+---------------+ 650 | /enrollstatus | /es | brski | 651 +-----------------+-------------------------+---------------+ 652 | /simplereenroll | /sren | est | 653 +-----------------+-------------------------+---------------+ 655 Table 2: BRSKI/EST URI paths mapping to Constrained 656 BRSKI/EST short URI paths 658 6.6.1. Pledge Extensions 660 This section defines extensions to the BRSKI Pledge, which are 661 applicable during the BRSKI bootstrap procedure. A Pledge which only 662 supports the EST-coaps enrollment method, SHOULD NOT use discovery 663 for EST-coaps resources, because it is more efficient to enroll (e.g. 664 /sen) via the well-known EST resource on the current DTLS connection. 665 This avoids an additional round-trip of packets and avoids the Pledge 666 having to unnecessarily implement CoRE Link Format parsing. 668 A constrained Pledge SHOULD NOT perform the optional EST "CSR 669 attributes request" (/att) to minimize network traffic. The Pledge 670 selects which attributes to include in the CSR. 672 One or more Subject Distinguished Name fields MUST be included. If 673 the Pledge has no specific information on what attributes/fields are 674 desired in the CSR, it MUST use the Subject Distinguished Name fields 675 from its IDevID unmodified. The Pledge can receive such information 676 via the voucher (encoded in a vendor-specific way) or via some other, 677 out-of-band means. 679 A constrained Pledge MAY use the following optimized EST-coaps 680 procedure to minimize network traffic. 682 1. if the voucher, that validates the current Registrar, contains a 683 single pinned domain CA certificate, the Pledge provisionally 684 considers this certificate as the EST trust anchor, as if it were 685 the result of "CA certificates request" (/crts) to the Registrar. 687 2. Using this CA certificate as trust anchor it proceeds with EST 688 simple enrollment (/sen) to obtain its provisionally trusted 689 LDevID certificate. 691 3. If the Pledge validates that the trust anchor CA was used to sign 692 its LDevID certificate, the Pledge accepts the pinned domain CA 693 certificate as the legitimate trust anchor CA for the Registrar's 694 domain and accepts the associated LDevID certificate. 696 4. If the trust anchor CA was NOT used to sign its LDevID 697 certificate, the Pledge MUST perform an actual "CA certificates 698 request" (/crts) to the EST server to obtain the EST CA trust 699 anchor(s) since these can differ from the (temporary) pinned 700 domain CA. 702 5. When doing this /crts request, the Pledge MAY use a CoAP Accept 703 Option with value TBD287 ("application/pkix-cert") to limit the 704 number of returned EST CA trust anchors to only one. A 705 constrained Pledge MAY support only this format in a /crts 706 response, per Section 5.3 of [I-D.ietf-ace-coap-est]. 708 6. If the Pledge cannot obtain the single CA certificate or the 709 finally validated CA certificate cannot be chained to the LDevID 710 certificate, then the Pledge MUST abort the enrollment process 711 and report the error using the enrollment status telemetry (/es). 713 Note that even though the Pledge may avoid performing any /crts 714 request using the above EST-coaps procedure during bootstrap, it 715 SHOULD support retrieval of the trust anchor CA periodically as 716 detailed in the next section. 718 6.6.2. EST-client Extensions 720 This section defines extensions to EST-coaps clients, used after the 721 BRSKI bootstrap procedure is completed. (Note that such client is 722 not called "Pledge" in this section, since it is already enrolled 723 into the domain.) A constrained EST-coaps client MAY support only 724 the Content-Format TBD287 ("application/pkix-cert") in a /crts 725 response, per Section 5.3 of [I-D.ietf-ace-coap-est]. In this case, 726 it can only store one trust anchor of the domain. 728 An EST-coaps client that has an idea of the current time (internally, 729 or via NTP) SHOULD consider the validity time of the trust anchor CA, 730 and MAY begin requesting a new trust anchor CA using the /crts 731 request when the CA has 50% of it's validity time (notAfter - 732 notBefore) left. A client without access to the current time cannot 733 decide if the trust anchor CA has expired, and SHOULD poll 734 periodically for a new trust anchor using the /crts request at an 735 interval of approximately 1 month. An EST-coaps server SHOULD 736 include the CoAP ETag Option in every response to a /crts request, to 737 enable clients to perform low-overhead validation whether their trust 738 anchor CA is still valid. The EST-coaps client SHOULD store the ETag 739 resulting from a /crts response in memory and SHOULD use this value 740 in an ETag Option in its next GET /crts request. 742 The above-mentioned limitation that an EST-coaps client may support 743 only one trust anchor CA is not an issue in case the domain trust 744 anchor remains stable. However, special consideration is needed for 745 cases where the domain trust anchor can change over time. Such a 746 change may happen due to relocation of the client device to a new 747 domain, or due to key update of the trust anchor as described in 748 [RFC4210], Section 4.4. 750 From the client's viewpoint, a trust anchor change typically happens 751 during EST re-enrollment: a change of domain CA requires all devices 752 operating under the old domain CA to acquire a new LDevID issued by 753 the new domain CA. A client's re-enrollment may be triggered by 754 various events, such as an instruction to re-enroll sent by a domain 755 entity, or an imminent expiry of its LDevID certificate. How the re- 756 enrollment is explicitly triggered on the client by a domain entity, 757 such as a commissioner or a Registrar, is out of scope of this 758 specification. 760 The mechanism described in [RFC4210], Section 4.4 for Root CA key 761 update requires four certificates: OldWithOld, OldWithNew, 762 NewWithOld, and NewWithNew. The OldWithOld certificate is already 763 stored in the EST client's trust store. The NewWithNew certificate 764 will be distributed as the single certificate in a /crts response, 765 during EST re-enrollment. Since the EST client can only accept a 766 single certificate in a /crts response it implies that the EST client 767 cannot obtain the certificates OldWithNew and NewWithOld in this way, 768 to perform the complete verification of the new domain CA. Instead, 769 the client only verifies the EST server (Registrar) using its old 770 domain CA certificate in its trust store as detailed below, and based 771 on this trust in the active and valid DTLS connection it 772 automatically trusts the new (NewWithNew) domain CA certificate that 773 the EST server provides in the /crts response. 775 In this manner, even during rollover of trust anchors, it is possible 776 to have only a single trust anchor provided in a /crts response. 778 During the period of the certificate renewal, it is not possible to 779 create new communication channels between devices with NewCA 780 certificates devices with OldCA certificates. One option is that 781 devices should avoid restarting existing DTLS or OSCORE connections 782 during this interval that new certificates are being deployed. The 783 recommended period for certificate renewal is 24 hours. For re- 784 enrollment, the constrained EST-coaps client MUST support the 785 following EST-coaps procedure, where optional re-enrollment to a new 786 domain is under control of the Registrar: 788 1. The client connects with DTLS to the Registrar, and authenticates 789 with its present domain certificate (LDevID certificate) as 790 usual. The Registrar authenticates itself with its domain 791 certificate that is trusted by the client, i.e. it chains to the 792 single trust anchor that the client has stored. This is the 793 "old" trust anchor, the one that will be eventually replaced in 794 case the Registrar decides to re-enroll the client into a new 795 domain. 797 2. The client performs the simple re-enrollment request (/sren) and 798 upon success it obtains a new LDevID. 800 3. The client verifies the new LDevID against its (single) existing 801 domain trust anchor. If it chains successfully, this means the 802 trust anchor did not change and the client MAY skip retrieving 803 the current CA certificate using the "CA certificates request" 804 (/crts). If it does not chain successfully, this means the trust 805 anchor was changed/updated and the client then MUST retrieve the 806 new domain trust anchor using the "CA certificates request" 807 (/crts). 809 4. If the client retrieved a new trust anchor in step 3, then it 810 MUST verify that the new trust anchor chains with the new LDevID 811 certificate it obtained in step 2. If it chains successfully, 812 the client stores both, accepts the new LDevID certificate and 813 stops using it prior LDevID certificate. If it does not chain 814 successfully, the client MUST NOT update its LDevID certificate, 815 it MUST NOT update its (single) domain trust anchor, and the 816 client MUST abort the enrollment process and report the error to 817 the Registrar using enrollment status telemetry (/es). 819 Note that even though the EST-coaps client may skip the /crts request 820 in step 3, it SHOULD support retrieval of the trust anchor CA 821 periodically as detailed earlier in this section. 823 6.6.3. Registrar Extensions 825 A Registrar SHOULD host any discoverable EST-coaps resources on the 826 same (UDP) server port that the Pledge's DTLS initial connection is 827 using. This avoids the overhead of the Pledge reconnecting using 828 DTLS, when it performs EST enrollment after the BRSKI voucher 829 request. 831 The Content-Format 50 (application/json) MUST be supported and 60 832 (application/cbor) MUST be supported by the Registrar for the /vs and 833 /es resources. 835 Content-Format TBD3 MUST be supported by the Registrar for the /rv 836 resource. 838 When a Registrar receives a "CA certificates request" (/crts) request 839 with a CoAP Accept Option with value TBD287 ("application/pkix-cert") 840 it SHOULD return only the single CA certificate that is the 841 envisioned or actual authority for the current, authenticated Pledge 842 making the request. 844 If the Pledge included in its request an Accept Option for only the 845 TBD287 ("application/pkix-cert") Content Format, but the domain has 846 been configured to operate with multiple CA trust anchors only, then 847 the Registrar returns a 4.06 Not Acceptable error to signal that the 848 Pledge needs to use the Content Format 281 ("application/pkcs7-mime; 849 smime-type=certs-only") to retrieve all the certificates. 851 If the current authenticated client is an EST-coaps client that was 852 already enrolled in the domain, and the Registrar is configured to 853 assign this client to a new domain CA trust anchor during the next 854 EST re-enrollment procedure, then the Registrar MUST respond with the 855 new domain CA certificate in case the client performs the "CA 856 Certificates request" (/crts) with an Accept Option for TBD287 only. 857 This signals the client that a new domain is assigned to it. The 858 client follows the procedure as defined in Section 6.6.2. 860 6.7. DTLS handshake fragmentation Considerations 862 DTLS includes a mechanism to fragment the handshake messages. This 863 is described in Section 4.4 of [I-D.ietf-tls-dtls13]. The protocol 864 described in this document will often be used with a Join Proxy 865 described in [I-D.ietf-anima-constrained-join-proxy]. The Join Proxy 866 will need some overhead, while the maximum packet sized guaranteed on 867 802.15.4 networks is 1280 bytes. It is RECOMMENDED that a PMTU of 868 1024 bytes be assumed for the DTLS handshake. It is unlikely that 869 any Packet Too Big indications [RFC4443] will be relayed by the Join 870 Proxy. 872 During the operation of the constrained BRSKI-EST protocol, the CoAP 873 Blockwise transfer mechanism will be used when message sizes exceed 874 the PMTU. A Pledge/EST-client on a constrained network MUST use the 875 (D)TLS maximum fragment length extension ("max_fragment_length") 876 defined in Section 4 of [RFC6066] with the maximum fragment length 877 set to a value of either 2^9 or 2^10. 879 7. BRSKI-MASA Protocol 881 This section describes extensions to and clarifications of the BRSKI- 882 MASA protocol between Registrar and MASA. 884 7.1. Protocol and Formats 886 Section 5.4 of [RFC8995] describes a connection between the Registrar 887 and the MASA as being a normal TLS connection using HTTPS. This 888 document does not change that. The Registrar MUST use the format 889 "application/voucher-cose+cbor" in its voucher request to MASA, when 890 the Pledge uses this format in its reauqtes to the Registrar 891 [RFC8995]. 893 The MASA only needs to support formats for which there are Pledges 894 that use that format. 896 The Registrar MUST use the same format for the RVR as the Pledge used 897 for its PVR. 899 The Registrar indicates the voucher format it wants to receive from 900 MASA using the HTTP Accept header. This format MUST be the same as 901 the format of the PVR, so that the Pledge can parse it. 903 At the moment of writing the creation of coaps based MASAs is deemed 904 unrealistic. The use of CoAP for the BRSKI-MASA connection can be 905 the subject of another document. Some consideration was made to 906 specify CoAP support for consistency, but: 908 * the Registrar is not expected to be so constrained that it cannot 909 support HTTPS client connections. 911 * the technology and experience to build Internet-scale HTTPS 912 responders (which the MASA is) is common, while the experience 913 doing the same for CoAP is much less common. 915 * a Registrar is likely to provide onboarding services to both 916 constrained and non-constrained devices. Such a Registrar would 917 need to speak HTTPS anyway. 919 * a manufacturer is likely to offer both constrained and non- 920 constrained devices, so there may in practice be no situation in 921 which the MASA could be CoAP-only. Additionally, as the MASA is 922 intended to be a function that can easily be oursourced to a 923 third-party service provider, reducing the complexity would also 924 seem to reduce the cost of that function. 926 * security-related considerations: see Section 14.6. 928 7.2. Registrar Voucher Request 930 If the PVR contains a proximity assertion, the Registrar MUST 931 propagate this assertion into the RVR by including the "assertion" 932 field with the value "proximity". This conforms to the example in 933 Section 3.3 of [RFC8995] of carrying the assertion forward. 935 7.3. MASA and the Server Name Indicator (SNI) 937 A TLS/HTTPS connection is established between the Registrar and MASA. 939 Section 5.4 of [RFC8995] explains this process, and there are no 940 externally visible changes. A MASA that supports the unconstrained 941 voucher formats should be able to support constrained voucher formats 942 equally well. 944 There is no requirement that a single MASA be used for both 945 constrained and unconstrained voucher requests: the choice of MASA is 946 determined by the id-mod-MASAURLExtn2016 extension contained in the 947 IDevID. 949 The Registrar MUST do [RFC6125] DNS-ID checks on the contents of the 950 certificate provided by the MASA. 952 In constrast to the Pledge/Registrar situation, the Registrar always 953 knows the name of the MASA, and MUST always include an [RFC6066] 954 Server Name Indicator. The SNI is optional in TLS1.2, but common. 955 The SNI it considered mandatory with TLS1.3. 957 The presence of the SNI is needed by the MASA, in order for the 958 MASA's server to host multiple tenants (for different customers). 960 The Registrar SHOULD use a TLS Client Certificate to authenticate to 961 the MASA per Section 5.4.1 of [RFC8995]. If the certificate that the 962 Registrar uses is marked as a id-kp-cmcRA certificate, via Extended 963 Key Usage, then it MUST also have the id-kp-clientAuth EKU attribute 964 set. 966 7.3.1. Registrar Certificate Requirement 968 In summary for typical Registrar use, where a single Registrar 969 certificate is used, then the certificate MUST have EKU of: id-kp- 970 cmcRA, id-kp-serverAuth, id-kp-clientAuth. 972 8. Pinning in Voucher Artifacts 974 The voucher is a statement by the MASA for use by the Pledge that 975 provides the identity of the Pledge's owner. This section describes 976 how the owner's identity is determined and how it is specified within 977 the voucher. 979 8.1. Registrar Identity Selection and Encoding 981 Section 5.5 of [RFC8995] describes BRSKI policies for selection of 982 the owner identity. It indicates some of the flexibility that is 983 possible for the Registrar, and recommends the Registrar to include 984 only certificates in the voucher request (CMS) signing structure that 985 participate in the certificate chain that is to be pinned. 987 The MASA is expected to evaluate the certificates included by the 988 Registrar in its voucher request, forming them into a chain with the 989 Registrar's (signing) identity on one end. Then, it pins a 990 certificate selected from the chain. For instance, for a domain with 991 a two-level certification authority (see Figure 1), where the 992 voucher-request has been signed by "Registrar", its signing structure 993 includes two additional CA certificates. The arrows in the figure 994 indicate the issuing of a certificate, i.e. author of (1) issued (2) 995 and author of (2) issued (3). 997 .------------------. 998 | domain CA (1) | 999 | trust anchor | 1000 '------------------' 1001 | 1002 v 1003 .------------. 1004 | domain (2) | 1005 | Sub-CA | 1006 '------------' 1007 | 1008 | 1009 v 1010 .----------------. 1011 | domain | 1012 | Registrar (3) | 1013 | EE certificate | 1014 '----------------' 1016 Figure 1: Two-Level CA PKI 1018 When the Registrar is using a COSE-signed constrained voucher request 1019 towards MASA, instead of a regular CMS-signed voucher request, the 1020 COSE_Sign1 object contains a protected and an unprotected header. 1021 The Registrar MUST place all the certificates needed to validate the 1022 signature chain from the Registrar on the RVR in an "x5bag" attribute 1023 in the unprotected header [I-D.ietf-cose-x509]. 1025 The "x5bag" attribute is very important as it provides the required 1026 signals from the Registrar to control what identity is pinned in the 1027 resulting voucher. This is explained in the next section. 1029 8.2. MASA Pinning Policy 1031 The MASA, having assembled and verified the chain in the signing 1032 structure of the voucher request needs to select a certificate to 1033 pin. (For the case that only the Registrar's End-Entity certificate 1034 is included, only this certificate can be selected and this section 1035 does not apply.) The BRSKI policy for pinning by the MASA as 1036 described in Section 5.5.2 of [RFC8995] leaves much flexibility to 1037 the manufacturer. 1039 The present document adds the following rules to the MASA pinning 1040 policy to reduce the network load: 1042 1. for a voucher containing a nonce, it SHOULD select the most 1043 specific (lowest-level) CA certificate in the chain. 1045 2. for a nonceless voucher, it SHOULD select the least-specific 1046 (highest-level) CA certificate in the chain that is allowed under 1047 the MASA's policy for this specific domain. 1049 The rationale for 1. is that in case of a voucher with nonce, the 1050 voucher is valid only in scope of the present DTLS connection between 1051 Pledge and Registrar anyway, so there is no benefit to pin a higher- 1052 level CA. By pinning the most specific CA the constrained Pledge can 1053 validate its DTLS connection using less crypto operations. The 1054 rationale for pinning a CA instead of the Registrar's End-Entity 1055 certificate directly is based on the following benefit on constrained 1056 networks: the pinned certificate in the voucher can in common cases 1057 be re-used as a Domain CA trust anchor during the EST enrollment and 1058 during the operational phase that follows after EST enrollment, as 1059 explained in Section 6.6.1. 1061 The rationale for 2. follows from the flexible BRSKI trust model for, 1062 and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of 1063 [RFC8995]). 1065 Refering to Figure 1 of a domain with a two-level certification 1066 authority, the most specific CA ("Sub-CA") is the identity that is 1067 pinned by MASA in a nonced voucher. A Registrar that wished to have 1068 only the Registrar's End-Entity certificate pinned would omit the 1069 "domain CA" and "Sub-CA" certificates from the voucher-request. 1071 In case of a nonceless voucher, depending on the trust level, the 1072 MASA pins the "Registrar" certificate (low trust in customer), or the 1073 "Sub-CA" certificate (in case of medium trust, implying that any 1074 Registrar of that sub-domain is acceptable), or even the "domain CA" 1075 certificate (in case of high trust in the customer, and possibly a 1076 pre-agreed need of the customer to obtain flexible long-lived 1077 vouchers). 1079 8.3. Pinning of Raw Public Keys 1081 Specifically for constrained use cases, the pinning of the raw public 1082 key (RPK) of the Registrar is also supported in the constrained 1083 voucher, instead of an X.509 certificate. If an RPK is pinned it 1084 MUST be the RPK of the Registrar. 1086 When the Pledge is known by MASA to support RPK but not X.509 1087 certificates, the voucher produced by the MASA pins the RPK of the 1088 Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk- 1089 sha256" field of a voucher. This is described in more detail in 1090 Section 9.2.3. A Pledge that does not support X.509 certificates 1091 cannot use EST to enroll; it has to use another method for enrollment 1092 without certificates and the Registrar has to support this method 1093 also. It is possible that the Pledge will not enroll, but instead 1094 only a network join operation will occur (See [RFC9031]). How the 1095 Pledge discovers this method and details of the enrollment method are 1096 out of scope of this document. 1098 When the Pledge is known by MASA to support PKIX format certificates, 1099 the "pinned-domain-cert" field present in a voucher typically pins a 1100 domain certificate. That can be either the End-Entity certificate of 1101 the Registrar, or the certificate of a domain CA of the Registrar's 1102 domain as specified in Section 8.2. However, if the Pledge is known 1103 to also support RPK pinning and the MASA intends to identify the 1104 Registrar in the voucher (not the CA), then MASA MUST pin the RPK 1105 (RPK3 in Figure 2) of the Registrar instead of the Registrar's End- 1106 Entity certificate to save space in the voucher. 1108 .------------. 1109 | pub-CA (1) | 1110 '------------' 1111 | 1112 v 1113 .------------. 1114 | sub-CA (2) | 1115 '------------' 1116 | 1117 v 1118 .--------------. 1119 | Registrar(3) | 1120 | RPK3 | 1121 '--------------' 1123 Figure 2: Raw Public Key pinning 1125 8.4. Considerations for use of IDevID-Issuer 1127 [RFC8366] and [RFC8995] defines the idevid-issuer attribute for 1128 voucher and voucher-request (respectively), but they summarily 1129 explain when to use it. 1131 The use of idevid-issuer is provided so that the serial-number to 1132 which the issued voucher pertains can be relative to the entity that 1133 issued the devices' IDevID. In most cases there is a one to one 1134 relationship between the trust anchor that signs vouchers (and is 1135 trusted by the pledge), and the Certification Authority that signs 1136 the IDevID. In that case, the serial-number in the voucher must 1137 refer to the same device as the serial-number that is in IDevID 1138 certificate. 1140 However, there situations where the one to one relationship may be 1141 broken. This occurs whenever a manufacturer has a common MASA, but 1142 different products (on different assembly lines) are produced with 1143 identical serial numbers. A system of serial numbers which is just a 1144 simple counter is a good example of this. A system of serial numbers 1145 where there is some prefix relating the product type does not fit 1146 into this, even if the lower digits are a counter. 1148 It is not possible for the Pledge or the Registrar to know which 1149 situation applies. The question to be answered is whether or not to 1150 include the idevid-issuer in the PVR and the RVR. A second question 1151 arisews as to what the format of the idevid-issuer contents are. 1153 Analysis of the situation shows that the pledge never needs to 1154 include the idevid-issuer in it's PVR, because the pledge's IDevID 1155 certificate is available to the Registrar, and the Authority Key 1156 Identifier is contained within that. The pledge therefore has no 1157 need to repeat this. 1159 For the RVR, the Registrar has to examine the pledge's IDevID 1160 certificate to discover the serial number for the Registrar's Voucher 1161 Request (RVR). This is clear in Section 5.5 of [RFC8995]. That 1162 section also clarifies that the idevid-issuer is to be included in 1163 the RVR. 1165 Concerning the Authority Key Identifier, [RFC8366] specifies that the 1166 entire object i.e. the extnValue OCTET STRING is to be included: 1167 comprising the AuthorityKeyIdentifier, SEQUENCE, Choice as well as 1168 the OCTET STRING that is the keyIdentifier. 1170 9. Artifacts 1172 This section describes for both the voucher request and the voucher 1173 first the abstract (tree) definition as explained in [RFC8340]. This 1174 provides a high-level view of the contents of each artifact. 1176 Then the assigned SID values are presented. These have been assigned 1177 using the rules in [I-D.ietf-core-sid]. 1179 9.1. Voucher Request artifact 1181 9.1.1. Tree Diagram 1183 The following diagram is largely a duplicate of the contents of 1184 [RFC8366], with the addition of the fields proximity-registrar-pubk, 1185 proximity-registrar-pubk-sha256, proximity-registrar-cert, and prior- 1186 signed-voucher-request. 1188 prior-signed-voucher-request is only used between the Registrar and 1189 the MASA. proximity-registrar-pubk or proximity-registrar-pubk-sha256 1190 optionally replaces proximity-registrar-cert for the most constrained 1191 cases where RPK is used by the Pledge. 1193 module: ietf-voucher-request-constrained 1195 grouping voucher-request-constrained-grouping 1196 +-- voucher 1197 +-- created-on? yang:date-and-time 1198 +-- expires-on? yang:date-and-time 1199 +-- assertion enumeration 1200 +-- serial-number string 1201 +-- idevid-issuer? binary 1202 +-- pinned-domain-cert? binary 1203 +-- domain-cert-revocation-checks? boolean 1204 +-- nonce? binary 1205 +-- last-renewal-date? yang:date-and-time 1206 +-- proximity-registrar-pubk? binary 1207 +-- proximity-registrar-pubk-sha256? binary 1208 +-- proximity-registrar-cert? binary 1209 +-- prior-signed-voucher-request? binary 1211 9.1.2. SID values 1213 SID Assigned to 1214 --------- -------------------------------------------------- 1215 2501 data /ietf-voucher-request-constrained:voucher 1216 2502 data .../assertion 1217 2503 data .../created-on 1218 2504 data .../domain-cert-revocation-checks 1219 2505 data .../expires-on 1220 2506 data .../idevid-issuer 1221 2507 data .../last-renewal-date 1222 2508 data /ietf-voucher-request-constrained:voucher/nonce 1223 2509 data .../pinned-domain-cert 1224 2510 data .../prior-signed-voucher-request 1225 2511 data .../proximity-registrar-cert 1226 2513 data .../proximity-registrar-pubk 1227 2512 data .../proximity-registrar-pubk-sha256 1228 2514 data .../serial-number 1230 WARNING, obsolete definitions 1232 The "assertion" attribute is an enumerated type [RFC8366], and the 1233 current PYANG tooling does not document the valid values for this 1234 attribute. In the JSON serialization, the literal strings from the 1235 enumerated types are used so there is no ambiguity. In the CBOR 1236 serialization, a small integer is used. This following values are 1237 documented here, but the YANG module should be considered 1238 authoritative. No IANA registry is provided or necessary because the 1239 YANG module provides for extensions. 1241 +=========+================+ 1242 | Integer | Assertion Type | 1243 +=========+================+ 1244 | 0 | verified | 1245 +---------+----------------+ 1246 | 1 | logged | 1247 +---------+----------------+ 1248 | 2 | proximity | 1249 +---------+----------------+ 1251 Table 3: CBOR integers 1252 for the "assertion" 1253 attribute enum 1255 9.1.3. YANG Module 1257 In the voucher-request-constrained YANG module, the voucher is 1258 "augmented" within the "used" grouping statement such that one 1259 continuous set of SID values is generated for the voucher-request- 1260 constrained module name, all voucher attributes, and the voucher- 1261 request-constrained attributes. Two attributes of the voucher are 1262 "refined" to be optional. 1264 file "ietf-voucher-request-constrained@2021-04-15.yang" 1265 module ietf-voucher-request-constrained { 1266 yang-version 1.1; 1268 namespace 1269 "urn:ietf:params:xml:ns:yang:ietf-voucher-request-constrained"; 1270 prefix "constrained"; 1272 import ietf-restconf { 1273 prefix rc; 1274 description 1275 "This import statement is only present to access 1276 the yang-data extension defined in RFC 8040."; 1277 reference "RFC 8040: RESTCONF Protocol"; 1278 } 1280 import ietf-voucher { 1281 prefix "v"; 1282 } 1284 organization 1285 "IETF ANIMA Working Group"; 1287 contact 1288 "WG Web: 1289 WG List: 1290 Author: Michael Richardson 1291 1292 Author: Peter van der Stok 1293 1294 Author: Panos Kampanakis 1295 "; 1297 description 1298 "This module defines the format for a voucher request, 1299 which is produced by a pledge to request a voucher. 1300 The voucher-request is sent to the potential owner's 1301 Registrar, which in turn sends the voucher request to 1302 the manufacturer or its delegate (MASA). 1304 A voucher is then returned to the pledge, binding the 1305 pledge to the owner. This is a constrained version of the 1306 voucher-request present in 1307 {{I-D.ietf-anima-bootstrap-keyinfra}} 1309 This version provides a very restricted subset appropriate 1310 for very constrained devices. 1311 In particular, it assumes that nonce-ful operation is 1312 always required, that expiration dates are rather weak, as no 1313 clocks can be assumed, and that the Registrar is identified 1314 by either a pinned Raw Public Key of the Registrar, or by a 1315 pinned X.509 certificate of the Registrar or domain CA. 1317 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1318 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1319 and 'OPTIONAL' in the module text are to be interpreted as 1320 described in RFC 2119."; 1322 revision "2021-04-15" { 1323 description 1324 "Initial version"; 1325 reference 1326 "RFC XXXX: Voucher Profile for Constrained Devices"; 1327 } 1329 rc:yang-data voucher-request-constrained-artifact { 1330 // YANG data template for a voucher. 1331 uses voucher-request-constrained-grouping; 1332 } 1334 // Grouping defined for future usage 1335 grouping voucher-request-constrained-grouping { 1336 description 1337 "Grouping to allow reuse/extensions in future work."; 1339 uses v:voucher-artifact-grouping { 1341 refine voucher/created-on { 1342 mandatory false; 1343 } 1345 refine voucher/pinned-domain-cert { 1346 mandatory false; 1347 } 1349 augment "voucher" { 1350 description "Base the constrained voucher-request upon the 1351 regular one"; 1353 leaf proximity-registrar-pubk { 1354 type binary; 1355 description 1356 "The proximity-registrar-pubk replaces 1357 the proximity-registrar-cert in constrained uses of 1358 the voucher-request. 1359 The proximity-registrar-pubk is the 1360 Raw Public Key of the Registrar. This field is encoded 1361 as specified in RFC7250, section 3. 1362 The ECDSA algorithm MUST be supported. 1363 The EdDSA algorithm as specified in 1364 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1365 Support for the DSA algorithm is not recommended. 1366 Support for the RSA algorithm is a MAY, but due to 1367 size is discouraged."; 1368 } 1370 leaf proximity-registrar-pubk-sha256 { 1371 type binary; 1372 description 1373 "The proximity-registrar-pubk-sha256 1374 is an alternative to both 1375 proximity-registrar-pubk and pinned-domain-cert. 1376 In many cases the public key of the domain has already 1377 been transmitted during the key agreement protocol, 1378 and it is wasteful to transmit the public key another 1379 two times. 1380 The use of a hash of public key info, at 32-bytes for 1381 sha256 is a significant savings compared to an RSA 1382 public key, but is only a minor savings compared to 1383 a 256-bit ECDSA public-key. 1385 Algorithm agility is provided by extensions to this 1386 specification which may define a new leaf for another 1387 hash type."; 1388 } 1390 leaf proximity-registrar-cert { 1391 type binary; 1392 description 1393 "An X.509 v3 certificate structure as specified by 1394 RFC 5280, 1395 Section 4 encoded using the ASN.1 distinguished encoding 1396 rules (DER), as specified in ITU-T X.690. 1398 The first certificate in the Registrar TLS server 1399 certificate_list sequence (see [RFC5246]) presented by 1400 the Registrar to the Pledge. This field or one of its 1401 alternatives MUST be populated in a 1402 Pledge's voucher request if the proximity assertion is 1403 populated."; 1404 } 1406 leaf prior-signed-voucher-request { 1407 type binary; 1408 description 1409 "If it is necessary to change a voucher, or re-sign and 1410 forward a voucher that was previously provided along a 1411 protocol path, then the previously signed voucher 1412 SHOULD be included in this field. 1414 For example, a pledge might sign a proximity voucher, 1415 which an intermediate registrar then re-signs to 1416 make its own proximity assertion. This is a simple 1417 mechanism for a chain of trusted parties to change a 1418 voucher, while maintaining the prior signature 1419 information. 1421 The pledge MUST ignore all prior voucher information 1422 when accepting a voucher for imprinting. Other 1423 parties MAY examine the prior signed voucher 1424 information for the purposes of policy decisions. 1425 For example, this information could be useful to a 1426 MASA to determine that both pledge and registrar 1427 agree on proximity assertions. The MASA SHOULD 1428 remove all prior-signed-voucher-request information when 1429 signing a voucher for imprinting so as to minimize the 1430 final voucher size."; 1431 } 1432 } 1434 } 1435 } 1436 } 1437 1439 9.1.4. Example voucher request artifact 1441 Below is a CBOR serialization of an example constrained voucher 1442 request from a Pledge to a Registrar, shown in CBOR diagnostic 1443 notation. The enum value of the assertion field is calculated to be 1444 2 by following the algorithm described in section 9.6.4.2 of 1445 [RFC7950]. 1447 { 1448 2501: { 1449 +2 : "2016-10-07T19:31:42Z", / SID=2503, created-on / 1450 +4 : "2016-10-21T19:31:42Z", / SID=2505, expires-on / 1451 +1 : 2, / SID=2502, assertion "proximity" / 1452 +13: "JADA123456789", / SID=2514, serial-number / 1453 +5 : h'08C2BF36....B3D2B3', / SID=2506, idevid-issuer / 1454 +10: h'30820275....82c35f', / SID=2511, proximity-registrar-cert/ 1455 +3 : true, / SID=2504, domain-cert 1456 -revocation-checks/ 1457 +6 : "2017-10-07T19:31:42Z" / SID=2507, last-renewal-date / 1458 } 1459 } 1461 9.2. Voucher artifact 1463 The voucher's primary purpose is to securely assign a Pledge to an 1464 owner. The voucher informs the Pledge which entity it should 1465 consider to be its owner. 1467 9.2.1. Tree Diagram 1469 The following diagram is largely a duplicate of the contents of 1470 [RFC8366], with only the addition of the fields pinned-domain-pubk 1471 and pinned-domain-pubk-sha256. 1473 module: ietf-voucher-constrained 1475 grouping voucher-constrained-grouping 1476 +-- voucher 1477 +-- created-on? yang:date-and-time 1478 +-- expires-on? yang:date-and-time 1479 +-- assertion enumeration 1480 +-- serial-number string 1481 +-- idevid-issuer? binary 1482 +-- pinned-domain-cert? binary 1483 +-- domain-cert-revocation-checks? boolean 1484 +-- nonce? binary 1485 +-- last-renewal-date? yang:date-and-time 1486 +-- pinned-domain-pubk? binary 1487 +-- pinned-domain-pubk-sha256? binary 1489 9.2.2. SID values 1491 SID Assigned to 1492 --------- -------------------------------------------------- 1493 2451 data /ietf-voucher-constrained:voucher 1494 2452 data /ietf-voucher-constrained:voucher/assertion 1495 2453 data /ietf-voucher-constrained:voucher/created-on 1496 2454 data .../domain-cert-revocation-checks 1497 2455 data /ietf-voucher-constrained:voucher/expires-on 1498 2456 data /ietf-voucher-constrained:voucher/idevid-issuer 1499 2457 data .../last-renewal-date 1500 2458 data /ietf-voucher-constrained:voucher/nonce 1501 2459 data .../pinned-domain-cert 1502 2460 data .../pinned-domain-pubk 1503 2461 data .../pinned-domain-pubk-sha256 1504 2462 data /ietf-voucher-constrained:voucher/serial-number 1506 WARNING, obsolete definitions 1508 The "assertion" enumerated attribute is numbered as per 1509 Section 9.1.2. 1511 9.2.3. YANG Module 1513 In the voucher-constrained YANG module, the voucher is "augmented" 1514 within the "used" grouping statement such that one continuous set of 1515 SID values is generated for the voucher-constrained module name, all 1516 voucher attributes, and the voucher-constrained attributes. Two 1517 attributes of the voucher are "refined" to be optional. 1519 file "ietf-voucher-constrained@2021-04-15.yang" 1520 module ietf-voucher-constrained { 1521 yang-version 1.1; 1523 namespace 1524 "urn:ietf:params:xml:ns:yang:ietf-voucher-constrained"; 1525 prefix "constrained"; 1527 import ietf-restconf { 1528 prefix rc; 1529 description 1530 "This import statement is only present to access 1531 the yang-data extension defined in RFC 8040."; 1532 reference "RFC 8040: RESTCONF Protocol"; 1533 } 1535 import ietf-voucher { 1536 prefix "v"; 1537 } 1539 organization 1540 "IETF ANIMA Working Group"; 1542 contact 1543 "WG Web: 1544 WG List: 1545 Author: Michael Richardson 1546 1547 Author: Peter van der Stok 1548 1549 Author: Panos Kampanakis 1550 "; 1552 description 1553 "This module defines the format for a voucher, which 1554 is produced by a pledge's manufacturer or its delegate 1555 (MASA) to securely assign one or more pledges to an 'owner', 1556 so that a pledge may establish a secure connection to the 1557 owner's network infrastructure. 1559 This version provides a very restricted subset appropriate 1560 for very constrained devices. 1561 In particular, it assumes that nonce-ful operation is 1562 always required, that expiration dates are rather weak, as no 1563 clocks can be assumed, and that the Registrar is identified 1564 by either a pinned Raw Public Key of the Registrar, or by a 1565 pinned X.509 certificate of the Registrar or domain CA. 1567 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1568 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1569 and 'OPTIONAL' in the module text are to be interpreted as 1570 described in RFC 2119."; 1572 revision "2021-04-15" { 1573 description 1574 "Initial version"; 1575 reference 1576 "RFC XXXX: Voucher Profile for Constrained Devices"; 1577 } 1579 rc:yang-data voucher-constrained-artifact { 1580 // YANG data template for a voucher. 1581 uses voucher-constrained-grouping; 1582 } 1584 // Grouping defined for future usage 1585 grouping voucher-constrained-grouping { 1586 description 1587 "Grouping to allow reuse/extensions in future work."; 1589 uses v:voucher-artifact-grouping { 1591 refine voucher/created-on { 1592 mandatory false; 1593 } 1595 refine voucher/pinned-domain-cert { 1596 mandatory false; 1597 } 1599 augment "voucher" { 1600 description "Base the constrained voucher 1601 upon the regular one"; 1602 leaf pinned-domain-pubk { 1603 type binary; 1604 description 1605 "The pinned-domain-pubk may replace the 1606 pinned-domain-cert in constrained uses of 1607 the voucher. The pinned-domain-pubk 1608 is the Raw Public Key of the Registrar. 1609 This field is encoded as a Subject Public Key Info block 1610 as specified in RFC7250, in section 3. 1611 The ECDSA algorithm MUST be supported. 1612 The EdDSA algorithm as specified in 1613 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1614 Support for the DSA algorithm is not recommended. 1616 Support for the RSA algorithm is a MAY."; 1617 } 1619 leaf pinned-domain-pubk-sha256 { 1620 type binary; 1621 description 1622 "The pinned-domain-pubk-sha256 is a second 1623 alternative to pinned-domain-cert. In many cases the 1624 public key of the domain has already been transmitted 1625 during the key agreement process, and it is wasteful 1626 to transmit the public key another two times. 1627 The use of a hash of public key info, at 32-bytes for 1628 sha256 is a significant savings compared to an RSA 1629 public key, but is only a minor savings compared to 1630 a 256-bit ECDSA public-key. 1631 Algorithm agility is provided by extensions to this 1632 specification which can define a new leaf for another 1633 hash type."; 1634 } 1635 } 1636 } 1637 } 1638 } 1639 1641 9.2.4. Example voucher artifacts 1643 Below the CBOR serialization of an example constrained voucher is 1644 shown in CBOR diagnostic notation. The enum value of the assertion 1645 field is calculated to be zero by following the algorithm described 1646 in section 9.6.4.2 of [RFC7950]. 1648 { 1649 2451: { 1650 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 1651 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 1652 +1 : 0, / SID = 2452, assertion "verified" / 1653 +11: "JADA123456789", / SID = 2462, serial-number / 1654 +5 : h'E40393B4....68A3', / SID = 2456, idevid-issuer / 1655 +8 : h'30820275....C35F', / SID = 2459, pinned-domain-cert/ 1656 +3 : true, / SID = 2454, domain-cert / 1657 / -revocation-checks / 1658 +6 : "2017-10-07T19:31:42Z" / SID = 2457, last-renewal-date / 1659 } 1660 } 1662 9.3. Signing voucher and voucher-request artifacts with COSE 1664 The COSE_Sign1 structure is discussed in Section 4.2 of 1665 [I-D.ietf-cose-rfc8152bis-struct]. The CBOR object that carries the 1666 body, the signature, and the information about the body and signature 1667 is called the COSE_Sign1 structure. It is used when only one 1668 signature is used on the body. 1670 Support for ECDSA with SHA2-256 using curve secp256r1 (aka 1671 prime256k1) is RECOMMENDED. Most current low power hardware has 1672 support for acceleration of this algorithm. Future hardware designs 1673 could omit this in favour of a newer algorithms. This is the ES256 1674 keytype from Table 1 of [I-D.ietf-cose-rfc8152bis-algs]. Support for 1675 curve secp256k1 is OPTIONAL. 1677 Support for EdDSA using Curve 25519 is RECOMMENDED in new designs if 1678 hardware support is available. This is keytype EDDSA (-8) from 1679 Table 2 of [I-D.ietf-cose-rfc8152bis-algs]. A "crv" parameter is 1680 necessary to specify the Curve, which from Table 18. The 'kty' field 1681 MUST be present, and it MUST be 'OKP'. (Table 17) 1683 A transition towards EdDSA is occuring in the industry. Some 1684 hardware can accelerate only some algorithms with specific curves, 1685 other hardware can accelerate any curve, and still other kinds of 1686 hardware provide a tool kit for acceleration of any eliptic curve 1687 algorithm. 1689 In general, the Pledge is expected to support only a single 1690 algorithm, while the Registrar, usually not constrained, is expected 1691 to support a wide variety of algorithms: both legacy ones and up-and- 1692 coming ones via regular software updates. 1694 An example of the supported COSE_Sign1 object structure is shown in 1695 Figure 3. 1697 18( / COSE_Sign1 / 1698 [ 1699 h'A101382E', / protected header encoding: {1: -47} / 1700 { / which means { "alg": ES256K } / 1701 4 : h'7890A03F1234' / 4 is the "kid" binary key identifier / 1702 }, 1703 h'1234....5678', / voucher-request binary content (CBOR) / 1704 h'4567....1234' / voucher-request binary public signature / 1705 ] 1706 ) 1708 Figure 3: COSE_Sign1 example in CBOR diagnostic notation 1710 The [COSE-registry] specifies the integers/encoding for the "alg" and 1711 "kid" fields in Figure 3. The "alg" field restricts the key usage 1712 for verification of this COSE object to a particular cryptographic 1713 algorithm. 1715 The "kid" field is optionally present: it is an unprotected field 1716 that identifies the public key of the key pair that was used to sign 1717 this message. The value of the key identifier "kid" parameter is an 1718 example value. Usually a hash of the public key is used to identify 1719 the public key, but a device serial number may also be used. The 1720 choice of key identifier method is vendor-specific. If "kid" is not 1721 present, then a verifying party needs to use other context 1722 information to retrieve the right public key to verify the COSE_Sign1 1723 object against. For example, this context information may be a 1724 unique serial number encoded in the binary content (CBOR) field. 1726 A Registrar MAY use a "kid" parameter in its RVR to identify its 1727 signing key as used to sign the RVR. The method of generating this 1728 "kid" is vendor-specific and SHOULD be configurable in the Registrar 1729 to support commonly used methods. In order to support future 1730 business cases and supply chain integrations, a Registrar MUST be 1731 configurable, on a per-manufacturer basis, to be able to configure 1732 the "kid" to a particular value. Both binary and string values are 1733 to be supported, each being inserted using a CBOR bstr or tstr. By 1734 default, a Registrar does not include a "kid" parameter in its RVR 1735 since the signing key is already identified by the included signing 1736 certificates in the COSE "x5bag" structure. 1738 A Pledge normally SHOULD NOT use a "kid" parameter in its PVR, 1739 because its signing key is already identified by the Pledge's unique 1740 serial number that is included in the PVR. Still, where needed the 1741 Pledge MAY use a "kid" parameter in its PVR to help the MASA identify 1742 the right public key to verify against. This can occur for example 1743 if a Pledge has multiple IDevID identities. A Registrar normally 1744 SHOULD ignore a "kid" parameter used in a received PVR, as this 1745 information is intended for the MASA. In other words, there is no 1746 need for the Registrar to verify the contents of this field, but it 1747 may include it in an audit log. 1749 In Appendix C a binary COSE_Sign1 object is shown based on the 1750 voucher-request example of Section 9.1.4. 1752 10. Deployment-specific Discovery Considerations 1754 This section details how discovery is done in specific deployment 1755 scenarios. 1757 10.1. 6TSCH Deployments 1759 In 6TISCH networks, the Constrained Join Proxy (CoJP) mechanism is 1760 described in [RFC9031]. Such networks are expected to use a 1761 [I-D.ietf-lake-edhoc] to do key management. This is the subject of 1762 future work. The Enhanced Beacon has been extended in [RFC9032] to 1763 allow for discovery of the Join Proxy. 1765 10.2. Generic networks using GRASP 1767 [RFC8995] defines a mechanism for the Pledge to discover a Join Proxy 1768 by listening for [RFC8990] GRASP messages. This mechanism can be 1769 used on any network which does not have another more specific 1770 mechanism. This mechanism supports mesh networks, and can also be 1771 used over unencrypted WIFI. 1773 10.3. Generic networks using mDNS 1775 [RFC8995] also defines a non-normative mechanism for the Pledge to 1776 discover a Join Proxy by doing mDNS queries. This mechanism can be 1777 used on any network which does not have another recommended 1778 mechanism. This mechanism does not easily support mesh networks. It 1779 can be used over unencrypted WIFI. 1781 10.4. Thread networks using Mesh Link Establishment (MLE) 1783 Thread [Thread] is a wireless mesh network protocol based on 6LoWPAN 1784 [RFC6282] and other IETF protocols. In Thread, a new device 1785 discovers potential Thread networks and Thread routers to join by 1786 using the Mesh Link Establishment (MLE) 1787 [I-D.ietf-6lo-mesh-link-establishment] protocol. MLE uses the UDP 1788 port number 19788. The new device sends discovery requests on 1789 different IEEE 802.15.4 radio channels, to which routers (if any 1790 present) respond with a discovery response containing information 1791 about their respective network. Once a suitable router is selected 1792 the new device initiates a DTLS transport-layer secured connection to 1793 the network's commissioning application, over a link-local single 1794 radio hop to the selected Thread router. This link is not yet 1795 secured at the radio level: link-layer security will be set up once 1796 the new device is approved by the commissioning application to join 1797 the Thread network, and it gets provisioned with network access 1798 credentials. 1800 The Thread router acts here as a Join Proxy. The MLE discovery 1801 response message contains UDP port information to signal the new 1802 device which port to use for its DTLS connection. 1804 10.5. Non-mesh networks using CoAP Discovery 1806 On unencrypted constrained networks such as 802.15.4, CoAP discover 1807 may be done using the mechanism detailed in [I-D.ietf-ace-coap-est] 1808 section 5.1. 1810 11. Design Considerations 1812 The design considerations for the CBOR encoding of vouchers are much 1813 the same as for JSON vouchers in [RFC8366]. One key difference is 1814 that the names of the leaves in the YANG definition do not affect the 1815 size of the resulting CBOR, as the SID translation process assigns 1816 integers to the names. 1818 Any POST request to the Registrar with resource /vs or /es returns a 1819 2.04 Changed response with empty payload. The client should be aware 1820 that the server may use a piggybacked CoAP response (ACK, 2.04) but 1821 may also respond with a separate CoAP response, i.e. first an (ACK, 1822 0.0) that is an acknowledgement of the request reception followed by 1823 a (CON, 2.04) response in a separate CoAP message. 1825 12. Raw Public Key Use Considerations 1827 This section explains techniques to reduce the number of bytes that 1828 are sent over the wire during the BRSKI bootstrap. The use of a raw 1829 public key (RPK) in the pinning process can significantly reduce the 1830 number of bytes and round trips, but it comes with a few significant 1831 operational limitations. 1833 12.1. The Registrar Trust Anchor 1835 When the Pledge first connects to the Registrar, the connection to 1836 the Registrar is provisional, as explained in Section 5.6.2 of 1837 [RFC8995]. The Registrar provides its public key in a 1838 TLSServerCertificate, and the Pledge uses that to validate that 1839 integrity of the (D)TLS connection, but it does not validate the 1840 identity of the provided certificate. 1842 As the TLSServerCertificate object is never verified directly by the 1843 pledge, sending it can be considered superfluous. Instead of using a 1844 (TLSServer)Certificate of type X509 (see section 4.4.2 of [RFC8446]), 1845 a RawPublicKey object is used. 1847 A Registrar operating in a mixed environment can determine whether to 1848 send a Certificate or a Raw Public key: this is determined by the 1849 pledge including the server_certificate_type of RawPublicKey. This 1850 is shown in section 5 of [RFC7250]. 1852 The Pledge continues to send a client_certificate_type of X509, so 1853 that the Registrar can properly identify the pledge and distill the 1854 MASA URI information from its certificate. 1856 12.2. The Pledge Voucher Request 1858 The Pledge puts the Registrar's public key into the proximity- 1859 registrar-pubk field of the voucher-request. (The proximity- 1860 registrar-pubk-sha256 can also be used if the 32-bytes of a SHA256 1861 hash turns out to be smaller than a typical ECDSA key.) 1863 As the format of the pubk field is identical to the TLS Certificate 1864 RawPublicKey, no manipulation at all is needed to insert this into a 1865 voucher-request. 1867 12.3. The Voucher Response 1869 A returned voucher will have a pinned-domain-subk field with the 1870 identical key as was found in the proximity-registrar-pubk field 1871 above, as well as in the TLS connection. 1873 Validation of this key by the pledge is what takes the DTLS 1874 connection out of the provisional state see Section 5.6.2 of 1875 [RFC8995]. 1877 The voucher needs to be validated first. The Pledge needs to have a 1878 public key to validate the signature from the MASA on the voucher. 1880 In certain cases, the MASA's public key counterpart of the (private) 1881 signing key is already installed in the Pledge at manufacturing time. 1882 In other cases, if the MASA signing key is based upon a PKI (see 1883 [I-D.richardson-anima-masa-considerations] Section 2.3), then a 1884 certificate chain may need to be included with the voucher in order 1885 for the pledge to validate the signature. In CMS signed artifacts, 1886 the CMS structure has a place for such certificates. 1888 In the COSE-signed Constrained Vouchers described in this document, 1889 the x5bag attribute from [I-D.ietf-cose-x509] is to be used for this. 1891 13. Use of constrained vouchers with HTTPS 1893 This specification contains two extensions to [RFC8995]: a 1894 constrained voucher format (COSE), and a constrained transfer 1895 protocol (CoAP). 1897 On constrained networks with constrained devices, it make senses to 1898 use both together. However, this document does not mandate that this 1899 be the only way. 1901 A given constrained device design and software may be re-used for 1902 multiple device models, such as a model having only an IEEE 802.15.4 1903 radio, or a model having only an IEEE 802.11 (Wi-Fi) radio, or a 1904 model having both these radios. A manufacturer of such device models 1905 may wish to have code only for the use of the constrained voucher 1906 format (COSE), and use it on all supported radios including the IEEE 1907 802.11 radio. For this radio, the software stack to support HTTP/TLS 1908 may be already integrated into the radio module hence it is 1909 attractive for the manufacturer to reuse this. This type of approach 1910 is supported by this document. In the case that HTTPS is used, the 1911 normal [RFC8995] resource names are used, together with the media 1912 types described in this document. 1914 Other combinations are possible, but they are not enumerated here. 1915 New work such as [I-D.ietf-anima-jws-voucher] provides new formats 1916 that may be useable over a number of different transports. In 1917 general, sending larger payloads over constrained networks makes less 1918 sense, while sending smaller payloads over unconstrained networks is 1919 perfectly acceptable. 1921 The Pledge will in most cases support a single voucher format, which 1922 it uses without negotiation i.e. without discovery of formats 1923 supported. The Registrar, being unconstrained, is expected to 1924 support all voucher formats. There will be cases where a Registrar 1925 does not support a new format that a new Pledge uses, and this is an 1926 unfortunate situation that will result in lack of interoperation. 1928 The responsability for supporting new formats is on the Registrar. 1930 14. Security Considerations 1932 14.1. Duplicate serial-numbers 1934 In the absense of correct use of idevid-issuer by the Registrar as 1935 detailed in Section 8.4, it would be possible for a malicious 1936 Registrar to use an unauthorized voucher for a device. This would 1937 apply only to the case where a Manufacturer Authorized Signing 1938 Authority (MASA) is trusted by different products from the same 1939 manufacturer, and the manufacturer has duplicated serial numbers as a 1940 result of a merge, acquisition or mis-management. 1942 For example, imagine the same manufacturer makes light bulbs as well 1943 as gas centrifuges, and said manufacturer does not uniquely allocate 1944 product serial numbers. This attack only works for nonceless 1945 vouchers. The attacker has obtained a light bulb which happens to 1946 have the same serial-number as a gas centrofuge which it wishes to 1947 obtain access. The attacker performs a normal BRSKI onboarding for 1948 the light bulb, but then uses the resulting voucher to onboard the 1949 gas centrofuge. The attack requires that the gas centrofuge be 1950 returned to a state where it is willing to perform a new onboarding 1951 operation. 1953 This attack is prevented by the mechanism of having the Registrar 1954 include the idevid-issuer in the RVR, and the MASA including it in 1955 the resulting voucher. The idevid-issuer is not included by default: 1956 a MASA needs to be aware if there are parts of the organization which 1957 duplicates serial numbers, and if so, include it. 1959 14.2. IDevID security in Pledge 1961 The security of this protocol depends upon the Pledge identifying 1962 itself to the Registrar using it's manufacturer installed 1963 certificate: the IDevID certificate. Associated with this 1964 certificate is the IDevID private key, known only to the Pledge. 1965 Disclosure of this private key to an attacker would permit the 1966 attacker to impersonate the Pledge towards the Registrar, probably 1967 gaining access credentials to that Registrar's network. 1969 If the IDevID private key disclosure is known to the manufacturer, 1970 there is little recourse other than recall of the relevant part 1971 numbers. The process for communicating this recall would be within 1972 the BRSKI-MASA protocol. Neither this specification nor [RFC8995] 1973 provides for consultation of a Certification Revocation List (CRL) or 1974 Open Certificate Status Protocol (OCSP) by a Registrar when 1975 evaluating an IDevID certificate. However, the BRSKI-MASA protocol 1976 submits the IDevID from the Registrar to the manufacturer's MASA and 1977 a manufacturer would have an opportunity to decline to issue a 1978 voucher for a device which they believe has become compromised. 1980 It may be difficult for a manufacturer to determine when an IDevID 1981 private key has been disclosed. Two situations present themselves: 1982 in the first situation a compromised private key might be reused in a 1983 counterfeit device, which is sold to another customer. This would 1984 present itself as an onboarding of the same device in two different 1985 networks. The manufacturer may become suspicious seeing two voucher 1986 requests for the same device from different Registrars. Such 1987 activity could be indistinguishable from a device which has been 1988 resold from one operator to another, or re-deployed by an operator 1989 from one location to another. 1991 In the second situation, an attacker having compromised the IDevID 1992 private key of a device might then install malware into the same 1993 device and attempt to return it to service. The device, now blank, 1994 would go through a second onboarding process with the original 1995 Registrar. Such a Registrar could notice that the device has been 1996 "factory reset" and alert the operator to this situation. One remedy 1997 against the presence of malware is through the use of Remote 1998 Attestation such as described in [I-D.ietf-rats-architecture]. 1999 Future work will need to specify a background-check Attestation flow 2000 as part of the voucher-request/voucher-response process. Attestation 2001 may still require access to a private key (e.g. IDevID private key) 2002 in order to sign Evidence, so a primary goal should be to keep any 2003 private key safe within the Pledge. 2005 In larger, more expensive, systems there is budget (power, space, and 2006 bill of materials) to include more specific defenses for a private 2007 key. For instance, this includes putting the IDevID private key in a 2008 Trusted Platform Module (TPM), or use of Trusted Execution 2009 Environments (TEE) for access to the key. On smaller IoT devices, 2010 the cost and power budget for an extra part is often prohibitive. 2012 It is becoming more and more common for CPUs to have an internal set 2013 of one-time fuses that can be programmed (often they are "burnt" by a 2014 laser) at the factory. This section of memory is only accessible in 2015 some priviledged CPU state. The use of this kind of CPU is 2016 appropriate as it provides significant resistance against key 2017 disclosure even when the device can be disassembled by an attacker. 2019 In a number of industry verticals, there is increasing concern about 2020 counterfeit parts. These may be look-alike parts created in a 2021 different factory, or parts which are created in the same factory 2022 during an illegal night-shift, but which are not subject to the 2023 appropriate level of quality control. The use of a manufacturer- 2024 signed IDevID certificate provides for discovery of the pedigree of 2025 each part, and this often justifies the cost of the security measures 2026 associated with storing the private key. 2028 14.3. Security of CoAP and UDP protocols 2030 Section 7.1 explains that no CoAPS version of the BRSKI-MASA protocol 2031 is proposed. The connection from the Registrar to the MASA continues 2032 to be HTTPS as in [RFC8995]. This has been done to simplify the MASA 2033 deployment for the manufacturer, because no new protocol needs to be 2034 enabled on the server. 2036 The use of UDP protocols across the open Internet is sometimes 2037 fraught with security challenges. Denial-of-service attacks against 2038 UDP based protocols are trivial as there is no three-way handshake as 2039 done for TCP. The three-way handshake of TCP guarantees that the 2040 node sending the connection request is reachable using the origin IP 2041 address. While DTLS contains an option to do a stateless challenge 2042 -- a process actually stronger than that done by TCP -- it is not yet 2043 common for this mechanism to be available in hardware at multigigabit 2044 speeds. It is for this reason that this document defines using HTTPS 2045 for the Registrar to MASA connection. 2047 14.4. Registrar Certificate may be self-signed 2049 The provisional (D)TLS connection formed by the Pledge with the 2050 Registrar does not authenticate the Registrar's identity. This 2051 Registrar's identity is validated by the [RFC8366] voucher that is 2052 issued by the MASA, signed with an anchor that was built-in to the 2053 Pledge. 2055 The Registrar may therefore use any certificate, including a self- 2056 signed one. The only restrictions on the certificate is that it MUST 2057 have EKU bits set as detailed in Section 7.3.1. 2059 14.5. Use of RPK alternatives to proximity-registrar-cert 2061 In Section 9.1 two compact alternative fields for proximity- 2062 registrar-cert are defined that include an RPK: proximity-registrar- 2063 pubk and proximity-registrar-pubk-sha256. The Pledge can use these 2064 fields in its PVR to identify the Registrar based on its public key 2065 only. Since the full certificate of the proximate Registrar is not 2066 included, use of these fields by a Pledge implies that a Registrar 2067 could insert another certificate with the same public key identity 2068 into the RVR. For example, an older or a newer version of its 2069 certificate. The MASA will not be able to detect such act by the 2070 Registrar. But since any 'other' certificate the Registrar could 2071 insert in this way still encodes its identity the additional risk of 2072 using the RPK alternatives is neglible. 2074 When a Registrar sees a PVR that uses one of proximity-registrar-pubk 2075 or proximity-registrar-pubk-sha256 fields, this implies the Registrar 2076 must include the certificate identified by these fields into its RVR. 2077 Otherwise, the MASA is unable to verify proximity. This requirement 2078 is already implied by the "MUST" requirement in Section 8.1. 2080 14.6. MASA support of CoAPS 2082 The use of CoAP for the BRSKI-MASA connection is not in scope of the 2083 current document. The following security considerations have led to 2084 this choice of scope: 2086 * the technology and experience to build secure Internet-scale HTTPS 2087 responders (which the MASA is) is common, while the experience in 2088 doing the same for CoAP is much less common. 2090 * in many enterprise networks, outgoing UDP connections are often 2091 treated as suspicious, which could effectively block CoAP 2092 connections for some firewall configurations. 2094 * reducing the complexity of MASA (i.e. less protocols supported) 2095 would also reduce its potential attack surface, which is relevant 2096 since the MASA is 24/7 exposed on the Internet and accepting 2097 (untrusted) incoming connections. 2099 15. IANA Considerations 2101 15.1. Resource Type Registry 2103 Additions to the sub-registry "Resource Type Link Target Attribute 2104 Values", within the "CoRE Parameters" IANA registry are specified 2105 below. 2107 Reference: [This RFC] 2109 +===========+==========================================+ 2110 | Attribute | Description | 2111 +===========+==========================================+ 2112 | brski | Root path of Bootstrapping Remote Secure | 2113 | | Key Infrastructure (BRSKI) resources | 2114 +-----------+------------------------------------------+ 2115 | brski.rv | BRSKI request voucher resource | 2116 +-----------+------------------------------------------+ 2117 | brski.vs | BRSKI voucher status telemetry resource | 2118 +-----------+------------------------------------------+ 2119 | brski.es | BRSKI enrollment status telemetry | 2120 | | resource | 2121 +-----------+------------------------------------------+ 2123 Table 4: Resource Type (rt) link target attribute 2124 values for IANA registration 2126 15.2. The IETF XML Registry 2128 This document registers two URIs in the IETF XML registry [RFC3688]. 2129 Following the format in [RFC3688], the following registration is 2130 requested: 2132 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-constrained 2133 Registrant Contact: The ANIMA WG of the IETF. 2134 XML: N/A, the requested URI is an XML namespace. 2136 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request-constrained 2137 Registrant Contact: The ANIMA WG of the IETF. 2138 XML: N/A, the requested URI is an XML namespace. 2140 15.3. The YANG Module Names Registry 2142 This document registers two YANG modules in the YANG Module Names 2143 registry [RFC6020]. Following the format defined in [RFC6020], the 2144 the following registration is requested: 2146 name: ietf-voucher-constrained 2147 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-constrained 2148 prefix: vch 2149 reference: RFC XXXX 2151 name: ietf-voucher-request-constrained 2152 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher- 2153 request-constrained 2154 prefix: vch 2155 reference: RFC XXXX 2157 15.4. The RFC SID range assignment sub-registry 2159 ------------ ------ --------------------------- ------------ 2160 Entry-point | Size | Module name | RFC Number 2161 ------------ ------ --------------------------- ------------ 2162 2450 50 ietf-voucher-constrained [This RFC] 2163 2500 50 ietf-voucher-request [This RFC] 2164 -constrained 2165 ----------- ------ --------------------------- ------------ 2167 Warning: These SID values are defined in [I-D.ietf-core-sid], not as 2168 an Early Allocation. 2170 IANA: please update the names in the Registry to match these revised 2171 names, if they have not already been revised. 2173 15.5. Media Types Registry 2175 This section registers the 'application/voucher-cose+cbor' in the 2176 IANA "Media Types" registry. This media type is used to indicate 2177 that the content is a CBOR voucher or voucher request signed with a 2178 COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct]. 2180 15.5.1. application/voucher-cose+cbor 2182 Type name: application 2183 Subtype name: voucher-cose+cbor 2184 Required parameters: N/A 2185 Optional parameters: N/A 2186 Encoding considerations: binary (CBOR) 2187 Security considerations: Security Considerations of [This RFC]. 2188 Interoperability considerations: The format is designed to be 2189 broadly interoperable. 2190 Published specification: [This RFC] 2191 Applications that use this media type: ANIMA, 6tisch, and other 2192 zero-touch onboarding systems 2193 Fragment identifier considerations: The syntax and semantics of 2194 fragment identifiers specified for application/voucher-cose+cbor 2195 are as specified for application/cbor. (At publication of this 2196 document, there is no fragment identification syntax defined for 2197 application/cbor.) 2198 Additional information: 2199 Deprecated alias names for this type: N/A 2200 Magic number(s): N/A 2201 File extension(s): .vch 2202 Macintosh file type code(s): N/A 2203 Person & email address to contact for further information: IETF 2204 ANIMA Working Group (anima@ietf.org) or IETF Operations and 2205 Management Area Working Group (opsawg@ietf.org) 2206 Intended usage: COMMON 2207 Restrictions on usage: N/A 2208 Author: ANIMA WG 2209 Change controller: IETF 2210 Provisional registration? (standards tree only): NO 2212 15.6. CoAP Content-Format Registry 2214 One addition to the sub-registry "CoAP Content-Formats", within the 2215 "CoRE Parameters" registry is needed for a new content-format. It 2216 can be registered in the Expert Review range (0-255) or the IETF 2217 Review range (256-9999). 2219 Media type Encoding ID Reference 2220 ----------------------------- --------- ---- ---------- 2221 application/voucher-cose+cbor - TBD3 [This RFC] 2223 15.7. Update to BRSKI Parameters Registry 2225 This section updates the BRSKI Well-Known URIs sub-registry of the 2226 IANA Bootstrapping Remote Secure Key Infrastructures (BRSKI) 2227 Parameters Registry by adding a new column "Short URI". The contents 2228 of this field MUST be specified for any newly registered URI as 2229 follows: 2231 Short URI: A short name for the "URI" resource that can be used by a 2232 Constrained BRSKI Pledge in a CoAP request to the Registrar. In case 2233 the "URI" resource is only used between Registrar and MASA, the value 2234 "--" is registered denoting that a short name is not applicable. 2236 The initial contents of the sub-registry including the new column are 2237 as follows: 2239 +=================+=======+=======================+============+ 2240 | URI | Short | Description | Reference | 2241 | | URI | | | 2242 +=================+=======+=======================+============+ 2243 | requestvoucher | rv | Request voucher: | [RFC8995], | 2244 | | | Pledge to Registrar, | [This RFC] | 2245 | | | and Registrar to MASA | | 2246 +-----------------+-------+-----------------------+------------+ 2247 | voucher_status | vs | Voucher status | [RFC8995], | 2248 | | | telemetry: Pledge to | [This RFC] | 2249 | | | Registrar | | 2250 +-----------------+-------+-----------------------+------------+ 2251 | requestauditlog | -- | Request audit log: | [RFC8995] | 2252 | | | Registrar to MASA | | 2253 +-----------------+-------+-----------------------+------------+ 2254 | enrollstatus | es | Enrollment status | [RFC8995], | 2255 | | | telemetry: Pledge to | [This RFC] | 2256 | | | Registrar | | 2257 +-----------------+-------+-----------------------+------------+ 2259 Table 5: Update of the BRSKI Well-Known URI Sub-Registry 2261 16. Acknowledgements 2263 We are very grateful to Jim Schaad for explaining COSE and CMS 2264 choices. Also thanks to Jim Schaad for correcting earlier versions 2265 of the COSE_Sign1 objects. 2267 Michel Veillette did extensive work on _pyang_ to extend it to 2268 support the SID allocation process, and this document was among its 2269 first users. 2271 Daniel Franke and Henk Birkholtz provided review feedback. 2273 The BRSKI design team has met on many Thursdays for document review. 2274 It includes: Aurelio Schellenbaum, David von Oheimb Steffen Fries, 2275 Thomas Werner, Toerless Eckert, 2277 17. Changelog 2279 -11 to -16 (For change details see GitHub issues https://github.com/ 2280 anima-wg/constrained-voucher/issues) 2282 -10 Design considerations extended Examples made consistent 2284 -08 Examples for cose_sign1 are completed and improved. 2286 -06 New SID values assigned; regenerated examples 2288 -04 voucher and request-voucher MUST be signed examples for signed 2289 request are added in appendix IANA SID registration is updated SID 2290 values in examples are aligned signed cms examples aligned with new 2291 SIDs 2293 -03 2295 Examples are inverted. 2297 -02 2299 Example of requestvoucher with unsigned appllication/cbor is added 2300 attributes of voucher "refined" to optional 2301 CBOR serialization of vouchers improved 2302 Discovery port numbers are specified 2304 -01 2306 application/json is optional, application/cbor is compulsory 2307 Cms and cose mediatypes are introduced 2309 18. References 2311 18.1. Normative References 2313 [I-D.ietf-ace-coap-est] 2314 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 2315 Raza, "EST over secure CoAP (EST-coaps)", Work in 2316 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 2317 January 2020, . 2320 [I-D.ietf-core-sid] 2321 Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. 2322 Richardson, "YANG Schema Item iDentifier (YANG SID)", Work 2323 in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 2324 November 2021, . 2327 [I-D.ietf-core-yang-cbor] 2328 Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M. 2329 Richardson, "CBOR Encoding of Data Modeled with YANG", 2330 Work in Progress, Internet-Draft, draft-ietf-core-yang- 2331 cbor-19, 20 March 2022, . 2334 [I-D.ietf-cose-rfc8152bis-algs] 2335 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2336 Initial Algorithms", Work in Progress, Internet-Draft, 2337 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2338 . 2341 [I-D.ietf-cose-rfc8152bis-struct] 2342 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2343 Structures and Process", Work in Progress, Internet-Draft, 2344 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2345 . 2348 [I-D.ietf-cose-x509] 2349 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2350 Header parameters for carrying and referencing X.509 2351 certificates", Work in Progress, Internet-Draft, draft- 2352 ietf-cose-x509-08, 14 December 2020, 2353 . 2356 [I-D.ietf-tls-dtls13] 2357 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2358 Datagram Transport Layer Security (DTLS) Protocol Version 2359 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2360 dtls13-43, 30 April 2021, 2361 . 2364 [ieee802-1AR] 2365 IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 2366 2009, . 2369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2370 Requirement Levels", BCP 14, RFC 2119, 2371 DOI 10.17487/RFC2119, March 1997, 2372 . 2374 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2375 DOI 10.17487/RFC3688, January 2004, 2376 . 2378 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2379 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2380 . 2382 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2383 "Internet X.509 Public Key Infrastructure Certificate 2384 Management Protocol (CMP)", RFC 4210, 2385 DOI 10.17487/RFC4210, September 2005, 2386 . 2388 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2389 Housley, R., and W. Polk, "Internet X.509 Public Key 2390 Infrastructure Certificate and Certificate Revocation List 2391 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2392 . 2394 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2395 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2396 . 2398 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2399 the Network Configuration Protocol (NETCONF)", RFC 6020, 2400 DOI 10.17487/RFC6020, October 2010, 2401 . 2403 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2404 Extensions: Extension Definitions", RFC 6066, 2405 DOI 10.17487/RFC6066, January 2011, 2406 . 2408 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2409 Verification of Domain-Based Application Service Identity 2410 within Internet Public Key Infrastructure Using X.509 2411 (PKIX) Certificates in the Context of Transport Layer 2412 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2413 2011, . 2415 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2416 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2417 Transport Layer Security (TLS) and Datagram Transport 2418 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2419 June 2014, . 2421 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2422 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2423 . 2425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2427 May 2017, . 2429 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2430 "A Voucher Artifact for Bootstrapping Protocols", 2431 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2432 . 2434 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2435 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2436 . 2438 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2439 Definition Language (CDDL): A Notational Convention to 2440 Express Concise Binary Object Representation (CBOR) and 2441 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2442 June 2019, . 2444 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2445 Representation (CBOR)", STD 94, RFC 8949, 2446 DOI 10.17487/RFC8949, December 2020, 2447 . 2449 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2450 and K. Watsen, "Bootstrapping Remote Secure Key 2451 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2452 May 2021, . 2454 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 2455 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 2456 RFC 9031, DOI 10.17487/RFC9031, May 2021, 2457 . 2459 [RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of 2460 6TiSCH Join and Enrollment Information Elements", 2461 RFC 9032, DOI 10.17487/RFC9032, May 2021, 2462 . 2464 18.2. Informative References 2466 [COSE-registry] 2467 IANA, "CBOR Object Signing and Encryption (COSE) 2468 registry", 2017, 2469 . 2471 [I-D.ietf-6lo-mesh-link-establishment] 2472 Kelsey, R., "Mesh Link Establishment", Work in Progress, 2473 Internet-Draft, draft-ietf-6lo-mesh-link-establishment-00, 2474 1 December 2015, . 2477 [I-D.ietf-anima-constrained-join-proxy] 2478 Richardson, M., Stok, P. V. D., and P. Kampanakis, 2479 "Constrained Join Proxy for Bootstrapping Protocols", Work 2480 in Progress, Internet-Draft, draft-ietf-anima-constrained- 2481 join-proxy-09, 25 March 2022, 2482 . 2485 [I-D.ietf-anima-jws-voucher] 2486 Richardson, M. and T. Werner, "JWS signed Voucher 2487 Artifacts for Bootstrapping Protocols", Work in Progress, 2488 Internet-Draft, draft-ietf-anima-jws-voucher-03, 7 March 2489 2022, . 2492 [I-D.ietf-lake-edhoc] 2493 Selander, G., Mattsson, J. P., and F. Palombini, 2494 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 2495 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 2496 October 2021, . 2499 [I-D.ietf-rats-architecture] 2500 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 2501 W. Pan, "Remote Attestation Procedures Architecture", Work 2502 in Progress, Internet-Draft, draft-ietf-rats-architecture- 2503 15, 8 February 2022, . 2506 [I-D.kuehlewind-update-tag] 2507 Kuehlewind, M. and S. Krishnan, "Definition of new tags 2508 for relations between RFCs", Work in Progress, Internet- 2509 Draft, draft-kuehlewind-update-tag-04, 12 July 2021, 2510 . 2513 [I-D.richardson-anima-masa-considerations] 2514 Richardson, M. and W. Pan, "Operatonal Considerations for 2515 Voucher infrastructure for BRSKI MASA", Work in Progress, 2516 Internet-Draft, draft-richardson-anima-masa- 2517 considerations-06, 13 November 2021, 2518 . 2521 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2522 Control Message Protocol (ICMPv6) for the Internet 2523 Protocol Version 6 (IPv6) Specification", STD 89, 2524 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2525 . 2527 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2528 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2529 DOI 10.17487/RFC6282, September 2011, 2530 . 2532 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2533 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2534 . 2536 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2537 "Enrollment over Secure Transport", RFC 7030, 2538 DOI 10.17487/RFC7030, October 2013, 2539 . 2541 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2542 Constrained-Node Networks", RFC 7228, 2543 DOI 10.17487/RFC7228, May 2014, 2544 . 2546 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2547 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2548 . 2550 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 2551 Autonomic Signaling Protocol (GRASP)", RFC 8990, 2552 DOI 10.17487/RFC8990, May 2021, 2553 . 2555 [Thread] Thread Group, Inc, "Thread support page, White Papers", 2556 November 2021, 2557 . 2559 Appendix A. Library Support for BRSKI 2561 For the implementation of BRSKI, the use of a software library to 2562 manipulate certificates and use crypto algorithms is often 2563 beneficial. Two C-based examples are OpenSSL and mbedtls. Others 2564 more targeted to specific platforms or languages exist. It is 2565 important to realize that the library interfaces differ significantly 2566 between libraries. 2568 Libraries do not support all known crypto algorithms. Before 2569 deciding on a library, it is important to look at their supported 2570 crypto algorithms and the roadmap for future support. Apart from 2571 availability, the library footprint, and the required execution 2572 cycles should be investigated beforehand. 2574 The handling of certificates usually includes the checking of a 2575 certificate chain. In some libraries, chains are constructed and 2576 verified on the basis of a set of certificates, the trust anchor 2577 (usually self signed root CA), and the target certificate. In other 2578 libraries, the chain must be constructed beforehand and obey order 2579 criteria. Verification always includes the checking of the 2580 signatures. Less frequent is the checking the validity of the dates 2581 or checking the existence of a revoked certificate in the chain 2582 against a set of revoked certificates. Checking the chain on the 2583 consistency of the certificate extensions which specify the use of 2584 the certificate usually needs to be programmed explicitly. 2586 A libary can be used to construct a (D)TLS connection. It is useful 2587 to realize that differences beetween (D)TLS implementations will 2588 occur due to the differences in the certicate checks supported by the 2589 library. On top of that, checks between client and server 2590 certificates enforced by (D)TLS are not always helpful for a BRSKI 2591 implementation. For example, the certificates of Pledge and 2592 Registrar are usually not related when the BRSKI protocol is started. 2593 It must be verified that checks on the relation between client and 2594 server certificates do not hamper a succeful DTLS connection 2595 establishment. 2597 A.1. OpensSSL 2599 From openssl's apps/verify.c : 2601 2602 X509 *x = NULL; 2603 int i = 0, ret = 0; 2604 X509_STORE_CTX *csc; 2605 STACK_OF(X509) *chain = NULL; 2606 int num_untrusted; 2608 x = load_cert(file, "certificate file"); 2609 if (x == NULL) 2610 goto end; 2612 csc = X509_STORE_CTX_new(); 2613 if (csc == NULL) { 2614 BIO_printf(bio_err, "error %s: X.509 store context" 2615 "allocation failed\n", 2616 (file == NULL) ? "stdin" : file); 2617 goto end; 2618 } 2620 X509_STORE_set_flags(ctx, vflags); 2621 if (!X509_STORE_CTX_init(csc, ctx, x, uchain)) { 2622 X509_STORE_CTX_free(csc); 2623 BIO_printf(bio_err, 2624 "error %s: X.509 store context" 2625 "initialization failed\n", 2626 (file == NULL) ? "stdin" : file); 2627 goto end; 2628 } 2629 if (tchain != NULL) 2630 X509_STORE_CTX_set0_trusted_stack(csc, tchain); 2631 if (crls != NULL) 2632 X509_STORE_CTX_set0_crls(csc, crls); 2634 i = X509_verify_cert(csc); 2635 X509_STORE_CTX_free(csc); 2637 2639 A.2. mbedTLS 2641 2642 mbedtls_x509_crt cert; 2643 mbedtls_x509_crt caCert; 2644 uint32_t certVerifyResultFlags; 2645 ... 2646 int result = mbedtls_x509_crt_verify(&cert, &caCert, NULL, NULL, 2647 &certVerifyResultFlags, NULL, NULL); 2648 2650 Appendix B. Constrained BRSKI-EST Message Examples 2652 This appendix extends the message examples from Appendix A of 2653 [I-D.ietf-ace-coap-est] with constrained BRSKI messages. The CoAP 2654 headers are only fully worked out for the first example, 2655 enrollstatus. 2657 B.1. enrollstatus 2659 A coaps enrollstatus message from Pledge to Registrar can be as 2660 follows: 2662 POST coaps://192.0.2.1:8085/b/es 2663 Content-Format: 60 2664 Payload: 2666 The corresponding CoAP header fields are shown below. 2668 Ver = 1 2669 T = 0 (CON) 2670 TKL = 1 2671 Code = 0x02 (0.02 is POST method) 2672 Message ID = 0xab0f 2673 Token = 0x4d 2674 Options 2675 Option (Uri-Path) 2676 Option Delta = 0xb (option nr = 11) 2677 Option Length = 0x1 2678 Option Value = "b" 2679 Option (Uri-Path) 2680 Option Delta = 0x0 (option nr = 11) 2681 Option Length = 0x2 2682 Option Value = "es" 2683 Option (Content-Format) 2684 Option Delta = 0x1 (option nr = 12) 2685 Option Length = 0x1 2686 Option Value = 60 (application/cbor) 2687 Payload Marker = 0xFF 2688 Payload = A26776657273696F6E0166737461747573F5 (18 bytes binary) 2690 The Uri-Host and Uri-Port Options are omitted because they coincide 2691 with the transport protocol (UDP) destination address and port 2692 respectively. 2694 The above binary CBOR enrollstatus payload looks as follows in CBOR 2695 diagnostic notation, for the case of enrollment success: 2697 { 2698 "version": 1, 2699 "status": true 2700 } 2702 Alternatively the payload could look as follows in case of enrollment 2703 failure, using the reason field to describe the failure: 2705 Payload = A36776657273696F6E0166737461747573F466726561736F6E782A3C 2706 496E666F726D61746976652068756D616E207265616461626C652065 2707 72726F72206D6573736167653E 2709 { 2710 "version": 1, 2711 "status": false, 2712 "reason": "" 2713 } 2715 To indicate successful reception of the enrollmentstatus telemetry 2716 report, a response from the Registrar may then be: 2718 2.04 Changed 2720 With CoAP fields: 2722 Ver=1 2723 T=2 (ACK) 2724 TKL=1 2725 Code = 0x44 (2.04 Changed) 2726 Message ID = 0xab0f 2727 Token = 0x4d 2729 B.2. voucher_status 2731 A coaps voucher_status message from Pledge to Registrar can be as 2732 follows: 2734 POST coaps://[2001:db8::2:1]/.well-known/brski/vs 2735 Content-Format: 60 (application/cbor) 2736 Payload: 2737 a46776657273696f6e0166737461747573f466726561736f6e7828496e66 2738 6f726d61746976652068756d616e2d7265616461626c65206572726f7220 2739 6d6573736167656e726561736f6e2d636f6e74657874a100764164646974 2740 696f6e616c20696e666f726d6174696f6e 2742 The request payload above is binary CBOR but represented here in 2743 hexadecimal for readability. Below is the equivalent CBOR diagnostic 2744 format. 2746 { 2747 "version": 1, 2748 "status": false, 2749 "reason": "Informative human-readable error message", 2750 "reason-context": { 0: "Additional information" } 2751 } 2753 A success response without payload will then be sent by the Registrar 2754 back to the Pledge to indicate reception of the telemetry report: 2756 2.04 Changed 2758 Appendix C. COSE-signed Voucher (Request) Examples 2760 This appendix provides examples of COSE-signed voucher requests and 2761 vouchers. First, the used test keys and certificates are described, 2762 following by examples of a constrained PVR, RVR and voucher. 2764 C.1. Pledge, Registrar and MASA Keys 2766 This section documents the public and private keys used for all 2767 examples in this appendix. These keys are not used in any production 2768 system, and must only be used for testing purposes. 2770 C.1.1. Pledge IDevID private key 2772 2773 Private-Key: (256 bit) 2774 priv: 2775 9b:4d:43:b6:a9:e1:7c:04:93:45:c3:13:d9:b5:f0: 2776 41:a9:6a:9c:45:79:73:b8:62:f1:77:03:3a:fc:c2: 2777 9c:9a 2778 pub: 2779 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 2780 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 2781 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 2782 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 2783 60:eb:95:5c:54 2784 ASN1 OID: prime256v1 2785 NIST CURVE: P-256 2786 2788 C.1.2. Registrar private key 2789 2790 Private-Key: (256 bit) 2791 priv: 2792 81:df:bb:50:a3:45:58:06:b5:56:3b:46:de:f3:e9: 2793 e9:00:ae:98:13:9e:2f:36:68:81:fc:d9:65:24:fb: 2794 21:7e 2795 pub: 2796 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2797 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2798 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2799 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2800 3e:d0:2d:c7:b7 2801 ASN1 OID: prime256v1 2802 NIST CURVE: P-256 2803 2805 C.1.3. MASA private key 2807 2808 Private-Key: (256 bit) 2809 priv: 2810 c6:bb:a5:8f:b6:d3:c4:75:28:d8:d3:d9:46:c3:31: 2811 83:6d:00:0a:9a:38:ce:22:5c:e9:d9:ea:3b:98:32: 2812 ec:31 2813 pub: 2814 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2815 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2816 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2817 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2818 ed:f3:17:5c:f1 2819 ASN1 OID: prime256v1 2820 NIST CURVE: P-256 2821 2823 C.2. Pledge, Registrar and MASA Certificates 2825 All keys and certificates used for the examples have been generated 2826 with OpenSSL - see Appendix D for more details on certificate 2827 generation. Below the certificates are listed that accompany the 2828 keys shown above. Each certificate description is followed by the 2829 hexadecimal representation of the X.509 ASN.1 DER encoded 2830 certificate. This representation can be for example decoded using an 2831 online ASN.1 decoder. 2833 C.2.1. Pledge IDevID Certificate 2834 2835 Certificate: 2836 Data: 2837 Version: 3 (0x2) 2838 Serial Number: 4822678189204992 (0x11223344556600) 2839 Signature Algorithm: ecdsa-with-SHA256 2840 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturer, 2841 CN=masa.stok.nl 2842 Validity 2843 Not Before: Dec 9 10:02:36 2020 GMT 2844 Not After : Dec 31 23:59:59 9999 GMT 2845 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturing, 2846 CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4 2847 Subject Public Key Info: 2848 Public Key Algorithm: id-ecPublicKey 2849 Public-Key: (256 bit) 2850 pub: 2851 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 2852 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 2853 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 2854 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 2855 60:eb:95:5c:54 2856 ASN1 OID: prime256v1 2857 NIST CURVE: P-256 2858 X509v3 extensions: 2859 X509v3 Basic Constraints: 2860 CA:FALSE 2861 X509v3 Authority Key Identifier: 2862 keyid: 2863 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2865 Signature Algorithm: ecdsa-with-SHA256 2866 30:46:02:21:00:d2:e6:45:3b:b0:c3:00:b3:25:8d:f1:83:fe: 2867 d9:37:c1:a2:49:65:69:7f:6b:b9:ef:2c:05:07:06:31:ac:17: 2868 bd:02:21:00:e2:ce:9e:7b:7f:74:50:33:ad:9e:ff:12:4e:e9: 2869 a6:f3:b8:36:65:ab:7d:80:bb:56:88:bc:03:1d:e5:1e:31:6f 2870 2872 Below is the hexadecimal representation: 2874 2875 30820226308201cba003020102020711223344556600300a06082a8648ce3d04 2876 0302306f310b3009060355040613024e4c310b300906035504080c024e423110 2877 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 2878 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 2879 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323031323039313030 2880 3233365a180f39393939313233313233353935395a308190310b300906035504 2881 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 2882 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 2883 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 2884 3a706c656467652e312e322e332e34311730150603550405130e706c65646765 2885 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 2886 420004d6b76f7488bd80ae5f28412c7202ef5f98b481e1d9104cf81b66d43e5c 2887 eada73e6a838a9f1351185b6cde20410befed50b3b14692ee1b06abc554060eb 2888 955c54a32e302c30090603551d1304023000301f0603551d23041830168014e4 2889 0393b4c3d3f42a80a47718f6964903011768a3300a06082a8648ce3d04030203 2890 49003046022100d2e6453bb0c300b3258df183fed937c1a24965697f6bb9ef2c 2891 05070631ac17bd022100e2ce9e7b7f745033ad9eff124ee9a6f3b83665ab7d80 2892 bb5688bc031de51e316f 2893 2895 C.2.2. Registrar Certificate 2896 2897 Certificate: 2898 Data: 2899 Version: 3 (0x2) 2900 Serial Number: 2901 70:56:ea:aa:30:66:d8:82:6a:55:5b:90:88:d4:62:bf:9c:f2:8c:fd 2902 Signature Algorithm: ecdsa-with-SHA256 2903 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 2904 CN=registrar.stok.nl 2905 Validity 2906 Not Before: Dec 9 10:02:36 2020 GMT 2907 Not After : Dec 9 10:02:36 2021 GMT 2908 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 2909 CN=registrar.stok.nl 2910 Subject Public Key Info: 2911 Public Key Algorithm: id-ecPublicKey 2912 Public-Key: (256 bit) 2913 pub: 2914 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2915 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2916 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2917 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2918 3e:d0:2d:c7:b7 2919 ASN1 OID: prime256v1 2920 NIST CURVE: P-256 2921 X509v3 extensions: 2922 X509v3 Subject Key Identifier: 2923 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2924 X509v3 Authority Key Identifier: 2925 keyid: 2926 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2928 X509v3 Basic Constraints: critical 2929 CA:TRUE 2930 X509v3 Extended Key Usage: 2931 CMC Registration Authority, TLS Web Server 2932 Authentication, TLS Web Client Authentication 2933 X509v3 Key Usage: critical 2934 Digital Signature, Non Repudiation, Key Encipherment, 2935 Data Encipherment, Certificate Sign, CRL Sign 2936 Signature Algorithm: ecdsa-with-SHA256 2937 30:44:02:20:74:4c:99:00:85:13:b2:f1:bc:fd:f9:02:1a:46: 2938 fb:17:4c:f8:83:a2:7c:a1:d9:3f:ae:ac:f3:1e:4e:dd:12:c6: 2939 02:20:11:47:14:db:f5:1a:5e:78:f5:81:b9:42:1c:6e:47:02: 2940 ab:53:72:70:c5:ba:fb:2d:16:c3:de:9a:a1:82:c3:5f 2941 2942 Below is the hexadecimal representation which is in (request-)voucher 2943 examples referred to as regis-cert-hex: 2945 2946 308202753082021ca00302010202147056eaaa3066d8826a555b9088d462bf9c 2947 f28cfd300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 2948 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2949 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 2950 73756c74616e6379311a301806035504030c117265676973747261722e73746f 2951 6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030 2952 3233365a3073310b3009060355040613024e4c310b300906035504080c024e42 2953 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 2954 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 2955 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 2956 8648ce3d020106082a8648ce3d03010703420004507ac8491a8c69c7b5c31d03 2957 09ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b8934021898d 2958 a789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d 2959 0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d23 2960 04183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d 2961 130101ff040530030101ff30270603551d250420301e06082b0601050507031c 2962 06082b0601050507030106082b06010505070302300e0603551d0f0101ff0404 2963 030201f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 2964 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf51a5e 2965 78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f 2966 2968 C.2.3. MASA Certificate 2970 2971 Certificate: 2972 Data: 2973 Version: 3 (0x2) 2974 Serial Number: 2975 14:26:b8:1c:ce:d8:c3:e8:14:05:cb:87:67:0d:be:ef:d5:81:25:b4 2976 Signature Algorithm: ecdsa-with-SHA256 2977 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 2978 OU=manufacturer, CN=masa.stok.nl 2980 Validity 2981 Not Before: Dec 9 10:02:36 2020 GMT 2982 Not After : Sep 5 10:02:36 2023 GMT 2983 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 2984 OU=manufacturer, CN=masa.stok.nl 2985 Subject Public Key Info: 2986 Public Key Algorithm: id-ecPublicKey 2987 Public-Key: (256 bit) 2988 pub: 2989 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2991 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2992 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2993 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2994 ed:f3:17:5c:f1 2995 ASN1 OID: prime256v1 2996 NIST CURVE: P-256 2997 X509v3 extensions: 2998 X509v3 Subject Key Identifier: 2999 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 3000 X509v3 Authority Key Identifier: 3001 keyid: 3002 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 3004 X509v3 Basic Constraints: critical 3005 CA:TRUE 3006 X509v3 Extended Key Usage: 3007 CMC Registration Authority, 3008 TLS Web Server Authentication, 3009 TLS Web Client Authentication 3010 X509v3 Key Usage: critical 3011 Digital Signature, Non Repudiation, Key Encipherment, 3012 Data Encipherment, Certificate Sign, CRL Sign 3013 Signature Algorithm: ecdsa-with-SHA256 3014 30:44:02:20:2e:c5:f2:24:72:70:20:ea:6e:74:8b:13:93:67: 3015 8a:e6:fe:fb:8d:56:7f:f5:34:18:a9:ef:a5:0f:c3:99:ca:53: 3016 02:20:3d:dc:91:d0:e9:6a:69:20:01:fb:e4:20:40:de:7c:7d: 3017 98:ed:d8:84:53:61:84:a7:f9:13:06:4c:a9:b2:8f:5c 3018 3020 Below is the hexadecimal representation: 3022 3023 3082026d30820214a00302010202141426b81cced8c3e81405cb87670dbeefd5 3024 8125b4300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 3025 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 3026 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 3027 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 3028 301e170d3230313230393130303233365a170d3233303930353130303233365a 3029 306f310b3009060355040613024e4c310b300906035504080c024e423110300e 3030 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 3031 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 3032 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 3033 2a8648ce3d0301070342000459809466149420303c6608855586dbe7d4d1d77a 3034 d2a31a0c736b010d021215d61ff36ec8d48460433b21c583801efce237857797 3035 94d4aa34b5b6c6edf3175cf1a3818d30818a301d0603551d0e04160414e40393 3036 b4c3d3f42a80a47718f6964903011768a3301f0603551d23041830168014e403 3037 93b4c3d3f42a80a47718f6964903011768a3300f0603551d130101ff04053003 3038 0101ff30270603551d250420301e06082b0601050507031c06082b0601050507 3039 030106082b06010505070302300e0603551d0f0101ff0404030201f6300a0608 3040 2a8648ce3d040302034700304402202ec5f224727020ea6e748b1393678ae6fe 3041 fb8d567ff53418a9efa50fc399ca5302203ddc91d0e96a692001fbe42040de7c 3042 7d98edd884536184a7f913064ca9b28f5c 3043 3045 C.3. COSE-signed Pledge Voucher Request (PVR) 3047 In this COSE example the voucher request has been signed by the 3048 Pledge using the private key of Appendix C.1.1, and has been sent to 3049 the link-local JRC (Registrar) over CoAPS. 3051 POST coaps://[JRC-link-local-address]/b/rv 3052 Content-Format: TBD3 3053 Payload: signed_request_voucher 3055 The payload signed_request_voucher is shown as hexadecimal dump (with 3056 lf added): 3058 3059 d28444a101382ea104582097113db094eee8eae48683e7337875c0372164 3060 be89d023a5f3df52699c0fbfb55902d2a11909c5a60274323032302d3132 3061 2d32335431323a30353a32325a0474323032322d31322d32335431323a30 3062 353a32325a01020750684ca83e27230aff97630cf2c1ec409a0d6e706c65 3063 6467652e312e322e332e340a590279308202753082021ca0030201020214 3064 7056eaaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d04 3065 03023073310b3009060355040613024e4c310b300906035504080c024e42 3066 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76 3067 616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e63 3068 79311a301806035504030c117265676973747261722e73746f6b2e6e6c30 3069 1e170d3230313230393130303233365a170d323131323039313030323336 3070 5a3073310b3009060355040613024e4c310b300906035504080c024e4231 3071 10300e06035504070c0748656c6d6f6e6431133011060355040a0c0a7661 3072 6e64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379 3073 311a301806035504030c117265676973747261722e73746f6b2e6e6c3059 3074 301306072a8648ce3d020106082a8648ce3d03010703420004507ac8491a 3075 8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6beb 3076 b94e02b8934021898da789c711cea71339f50e348edf0d923ed02dc7b7a3 3077 818d30818a301d0603551d0e0416041408c2bf36887f79412185872f16a7 3078 aca6efb3d2b3301f0603551d2304183016801408c2bf36887f7941218587 3079 2f16a7aca6efb3d2b3300f0603551d130101ff040530030101ff30270603 3080 551d250420301e06082b0601050507031c06082b0601050507030106082b 3081 06010505070302300e0603551d0f0101ff0404030201f6300a06082a8648 3082 ce3d04030203470030440220744c99008513b2f1bcfdf9021a46fb174cf8 3083 83a27ca1d93faeacf31e4edd12c60220114714dbf51a5e78f581b9421c6e 3084 4702ab537270c5bafb2d16c3de9aa182c35f58473045022063766c7bbd1b 3085 339dbc398e764af3563e93b25a69104befe9aac2b3336b8f56e1022100cd 3086 0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f2991484 3087 e9 3088 3090 The Pledge uses the "proximity" (SID 2502, enum 2) assertion together 3091 with an included proximity-registrar-cert field (SID 2511) to inform 3092 MASA about its proximity to the specific Registrar. The 3093 representiation of signed_voucher_request in CBOR diagnostic format 3094 is: 3096 3097 Diagnose(signed_request_voucher) = 3098 18([ 3099 h'A101382E', / {"alg": -47} / 3100 {4: h'97113DB094EEE8EAE48683E7337875C0372164B 3101 E89D023A5F3DF52699C0FBFB5'}, 3102 h'', / byte string as detailed below / 3103 h'3045022063766C7BBD1B339DBC398E764AF3563E93B 3104 25A69104BEFE9AAC2B3336B8F56E1022100CD0419559A 3105 D960CCAED4DEE3F436ECA40B7570B25A52EB60332BC1F 3106 2991484E9' 3107 ]) 3109 Diagnose(request_voucher) = 3110 {2501: {2: "2020-12-23T12:05:22Z", 3111 4: "2022-12-23T12:05:22Z", 3112 1: 2, 3113 7: h'684CA83E27230AFF97630CF2C1EC409A', 3114 13: "pledge.1.2.3.4", 3115 10: h'' / byte string as defined in C.2.2 / 3116 }} 3117 3119 C.4. COSE-signed Registrar Voucher Request (RVR) 3121 In this example the Registrar's voucher request has been signed by 3122 the JRC (Registrar) using the private key from Appendix C.1.2. 3123 Contained within this voucher request is the voucher request PVR that 3124 was made by the Pledge to JRC. Note that the RVR uses the HTTPS 3125 protocol (not CoAP) and corresponding long URI path names as defined 3126 in [RFC8995]. The Content-Type and Accept headers indicate the 3127 constrained voucher format that is defined in the present document. 3128 Because the Pledge used this format in the PVR, the JRC must also use 3129 this format in the RVR. 3131 POST https://masa.example.com/.well-known/brski/requestvoucher 3132 Content-Type: application/voucher-cose+cbor 3133 Accept: application/voucher-cose+cbor 3134 Body: signed_masa_request_voucher 3136 The payload signed_masa_voucher_request is shown as hexadecimal dump 3137 (with lf added): 3139 3140 d28444a101382ea1045820e8735bc4b470c3aa6a7aa9aa8ee584c09c1113 3141 1b205efec5d0313bad84c5cd05590414a11909c5a60274323032302d3132 3142 2d32385431303a30333a33355a0474323032322d31322d32385431303a30 3143 333a33355a07501551631f6e0416bd162ba53ea00c2a050d6e706c656467 3144 652e312e322e332e3405587131322d32385431303a30333a33355a075015 3145 51631f6e0416bd162ba53ea00c2a050d6e706c656467652e312e322e332e 3146 3405587131322d32385431303a300000000000000000000000000416bd16 3147 2ba53ea00c2a050d6e706c656467652e312e322e332e3405587131322d32 3148 385431303a09590349d28444a101382ea104582097113db094eee8eae486 3149 83e7337875c0372164be89d023a5f3df52699c0fbfb55902d2a11909c5a6 3150 0274323032302d31322d32385431303a30333a33355a0474323032322d31 3151 322d32385431303a30333a33355a010207501551631f6e0416bd162ba53e 3152 a00c2a050d6e706c656467652e312e322e332e340a590279308202753082 3153 021ca00302010202147056eaaa3066d8826a555b9088d462bf9cf28cfd30 3154 0a06082a8648ce3d0403023073310b3009060355040613024e4c310b3009 3155 06035504080c024e423110300e06035504070c0748656c6d6f6e64311330 3156 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b63 3157 6f6e73756c74616e6379311a301806035504030c11726567697374726172 3158 2e73746f6b2e6e6c301e170d3230313230393130303233365a170d323131 3159 3230393130303233365a3073310b3009060355040613024e4c310b300906 3160 035504080c024e423110300e06035504070c0748656c6d6f6e6431133011 3161 060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f 3162 6e73756c74616e6379311a301806035504030c117265676973747261722e 3163 73746f6b2e6e6c3059301306072a8648ce3d020106082a8648ce3d030107 3164 03420004507ac8491a8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018 3165 154fa059b020ec6bebb94e02b8934021898da789c711cea71339f50e348e 3166 df0d923ed02dc7b7a3818d30818a301d0603551d0e0416041408c2bf3688 3167 7f79412185872f16a7aca6efb3d2b3301f0603551d2304183016801408c2 3168 bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff0405 3169 30030101ff30270603551d250420301e06082b0601050507031c06082b06 3170 01050507030106082b06010505070302300e0603551d0f0101ff04040302 3171 01f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 3172 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf5 3173 1a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f584730 3174 45022063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3 3175 336b8f56e1022100cd0419559ad960ccaed4dee3f436eca40b7570b25a52 3176 eb60332bc1f2991484e958473045022100e6b45558c1b806bba23f4ac626 3177 c9bdb6fd354ef4330d8dfb7c529f29cca934c802203c1f2ccbbac89733d1 3178 7ee7775bc2654c5f1cc96afba2741cc31532444aa8fed8 3179 3181 The representiation of signed_masa_voucher_request in CBOR diagnostic 3182 format is: 3184 3185 Diagnose(signed_registrar_request-voucher) 3186 18([ 3187 h'A101382E', / {"alg": -47} / 3188 h'E8735BC4B470C3AA6A7AA9AA8EE584C09C11131B205EFEC5D0313BAD84 3189 C5CD05'}, 3190 h'', / byte string as detailed below / 3191 h'3045022100E6B45558C1B806BBA23F4AC626C9BDB6FD354EF4330D8DFB 3192 7C529F29CCA934C802203C1F2CCBBAC89733D17EE7775BC2654C5F1CC96A 3193 FBA2741CC31532444AA8FED8' 3194 ]) 3196 Diagnose(registrar_request_voucher) 3197 {2501: 3198 {2: "2020-12-28T10:03:35Z", 3199 4: "2022-12-28T10:03:35Z", 3200 7: h'1551631F6E0416BD162BA53EA00C2A05', 3201 13: "pledge.1.2.3.4", 3202 5: h'31322D32385431303A30333A33355A07501551631F6E0416BD 3203 162BA53EA00C2A050D6E706C656467652E312E322E332E3405 3204 587131322D32385431303A3000000000000000000000000004 3205 16BD162BA53EA00C2A050D6E706C656467652E312E322E332E 3206 3405587131322D32385431303A', / idevid-issuer / 3207 9: h'' / prior-signed-voucher-request = PVR / 3208 } 3209 } 3210 3212 C.5. COSE-signed Voucher from MASA 3214 The resulting voucher is created by the MASA and returned via the JRC 3215 to the Pledge. It is signed by the MASA's private key (see 3216 Appendix C.1.3) and can be verified by the Pledge using the MASA's 3217 public key that it stores. 3219 Below is the binary signed_voucher, encoded in hexadecimal (with lf 3220 added): 3222 3223 d28444a101382ea104582039920a34ee92d3148ab3a729f58611193270c9 3224 029f7784daf112614b19445d5158cfa1190993a70274323032302d31322d 3225 32335431353a30333a31325a0474323032302d31322d32335431353a3233 3226 3a31325a010007506508e06b2959d5089d7a3169ea889a490b6e706c6564 3227 67652e312e322e332e340858753073310b3009060355040613024e4c310b 3228 300906035504080c024e423110300e06035504070c0748656c6d6f6e6431 3229 133011060355040a0c0a76616e64657273746f6b31143012060355040b0c 3230 0b636f6e73756c74616e6379311a301806035504030c1172656769737472 3231 61722e73746f6b2e6e6c03f458473045022022515d96cd12224ee5d3ac67 3232 3237163bba24ad84815699285d9618f463ee73fa022100a6bff9d8585c1c 3233 9256371ece94da3d26264a5dfec0a354fe7b3aef58344c512f 3234 3236 The representiation of signed_voucher in CBOR diagnostic format is: 3238 3239 Diagnose(signed_voucher) = 3240 18([ 3241 h'A101382E', / {"alg": -47} / 3242 {4: h'39920A34EE92D3148AB3A729F58611193270C9029F7784DAF112614B194 3243 45D51'}, 3244 h'', / byte string as detailed below / 3245 h'3045022022515D96CD12224EE5D3AC673237163BBA24AD84815699285D9618F 3246 463EE73FA022100A6BFF9D8585C1C9256371ECE94DA3D26264A5DFEC0A354FE7B 3247 3AEF58344C512F' 3248 ]) 3250 Diagnose(voucher) = 3251 {2451: 3252 {2: "2020-12-23T15:03:12Z", 3253 4: "2020-12-23T15:23:12Z", 3254 1: 0, 3255 7: h'6508E06B2959D5089D7A3169EA889A49', 3256 11: "pledge.1.2.3.4", 3257 8: h'', / as detailed in C.2.2 / 3258 3: false} 3259 } 3260 3262 In above, regis-cert-hex represents the hexadecimal encoding of the 3263 Registrar certificate of Appendix C.2.2. 3265 Appendix D. Generating Certificates with OpenSSL 3267 This informative appendix shows an example of a Bash shell script to 3268 generate test certificates for the Pledge IDevID, the Registrar and 3269 the MASA. This shell script cannot be run stand-alone because it 3270 depends on particular input files which are not included in this 3271 appendix. Nevertheless, this example script may provide guidance on 3272 how OpenSSL can be configured for generating Constrained BRSKI 3273 certificates. 3275 Note: the *-comb.crt certificate files combine the certificate with 3276 the private key. These are generated to be used by libcoap for DTLS 3277 connection establishment. 3279 3280 #!/bin/bash 3281 #try-cert.sh 3282 export dir=./brski/intermediate 3283 export cadir=./brski 3284 export cnfdir=./conf 3285 export format=pem 3286 export default_crl_days=30 3287 sn=8 3289 DevID=pledge.1.2.3.4 3290 serialNumber="serialNumber=$DevID" 3291 export hwType=1.3.6.1.4.1.6715.10.1 3292 export hwSerialNum=01020304 # Some hex 3293 export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" 3294 echo $hwType - $hwSerialNum 3295 echo $serialNumber 3296 OPENSSL_BIN="openssl" 3298 # remove all files 3299 rm -r ./brski/* 3300 # 3301 # initialize file structure 3302 # root level 3303 cd $cadir 3304 mkdir certs crl csr newcerts private 3305 chmod 700 private 3306 touch index.txt 3307 touch serial 3308 echo 11223344556600 >serial 3309 echo 1000 > crlnumber 3310 # intermediate level 3311 mkdir intermediate 3312 cd intermediate 3313 mkdir certs crl csr newcerts private 3314 chmod 700 private 3315 touch index.txt 3316 echo 11223344556600 >serial 3317 echo 1000 > crlnumber 3318 cd ../.. 3320 # file structure is cleaned start filling 3322 echo "#############################" 3323 echo "create registrar keys and certificates " 3324 echo "#############################" 3326 echo "create root registrar certificate using ecdsa with sha 256 key" 3327 $OPENSSL_BIN ecparam -name prime256v1 -genkey \ 3328 -noout -out $cadir/private/ca-regis.key 3330 $OPENSSL_BIN req -new -x509 \ 3331 -config $cnfdir/openssl-regis.cnf \ 3332 -key $cadir/private/ca-regis.key \ 3333 -out $cadir/certs/ca-regis.crt \ 3334 -extensions v3_ca\ 3335 -days 365 \ 3336 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \ 3337 /CN=registrar.stok.nl" 3339 # Combine authority certificate and key 3340 echo "Combine authority certificate and key" 3341 $OPENSSL_BIN pkcs12 -passin pass:watnietWT -passout pass:watnietWT\ 3342 -inkey $cadir/private/ca-regis.key \ 3343 -in $cadir/certs/ca-regis.crt -export \ 3344 -out $cadir/certs/ca-regis-comb.pfx 3346 # converteer authority pkcs12 file to pem 3347 echo "converteer authority pkcs12 file to pem" 3348 $OPENSSL_BIN pkcs12 -passin pass:watnietWT -passout pass:watnietWT\ 3349 -in $cadir/certs/ca-regis-comb.pfx \ 3350 -out $cadir/certs/ca-regis-comb.crt -nodes 3352 #show certificate in registrar combined certificate 3353 $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text 3355 # 3356 # Certificate Authority for MASA 3357 # 3358 echo "#############################" 3359 echo "create MASA keys and certificates " 3360 echo "#############################" 3362 echo "create root MASA certificate using ecdsa with sha 256 key" 3363 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 3364 -out $cadir/private/ca-masa.key 3366 $OPENSSL_BIN req -new -x509 \ 3367 -config $cnfdir/openssl-masa.cnf \ 3368 -days 1000 -key $cadir/private/ca-masa.key \ 3369 -out $cadir/certs/ca-masa.crt \ 3370 -extensions v3_ca\ 3371 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\ 3372 /CN=masa.stok.nl" 3374 # Combine authority certificate and key 3375 echo "Combine authority certificate and key for masa" 3376 $OPENSSL_BIN pkcs12 -passin pass:watnietWT -passout pass:watnietWT\ 3377 -inkey $cadir/private/ca-masa.key \ 3378 -in $cadir/certs/ca-masa.crt -export \ 3379 -out $cadir/certs/ca-masa-comb.pfx 3381 # converteer authority pkcs12 file to pem for masa 3382 echo "converteer authority pkcs12 file to pem for masa" 3383 $OPENSSL_BIN pkcs12 -passin pass:watnietWT -passout pass:watnietWT\ 3384 -in $cadir/certs/ca-masa-comb.pfx \ 3385 -out $cadir/certs/ca-masa-comb.crt -nodes 3387 #show certificate in pledge combined certificate 3388 $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text 3390 # 3391 # Certificate for Pledge derived from MASA certificate 3392 # 3393 echo "#############################" 3394 echo "create pledge keys and certificates " 3395 echo "#############################" 3397 # Pledge derived Certificate 3399 echo "create pledge derived certificate using ecdsa with sha 256 key" 3400 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 3401 -out $dir/private/pledge.key 3403 echo "create pledge certificate request" 3404 $OPENSSL_BIN req -nodes -new -sha256 \ 3405 -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ 3406 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ 3407 /CN=uuid:$DevID/$serialNumber" 3409 # Sign pledge derived Certificate 3410 echo "sign pledge derived certificate " 3411 $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \ 3412 -extensions 8021ar_idevid\ 3413 -days 365 -in $dir/csr/pledge.csr \ 3414 -out $dir/certs/pledge.crt 3416 # Add pledge key and pledge certificate to pkcs12 file 3417 echo "Add derived pledge key and derived pledge \ 3418 certificate to pkcs12 file" 3419 $OPENSSL_BIN pkcs12 -passin pass:watnietWT -passout pass:watnietWT\ 3420 -inkey $dir/private/pledge.key \ 3421 -in $dir/certs/pledge.crt -export \ 3422 -out $dir/certs/pledge-comb.pfx 3424 # converteer pledge pkcs12 file to pem 3425 echo "converteer pledge pkcs12 file to pem" 3426 $OPENSSL_BIN pkcs12 -passin pass:watnietWT -passout pass:watnietWT\ 3427 -in $dir/certs/pledge-comb.pfx \ 3428 -out $dir/certs/pledge-comb.crt -nodes 3430 #show certificate in pledge-comb.crt 3431 $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text 3433 #show private key in pledge-comb.crt 3434 $OPENSSL_BIN ecparam -name prime256v1\ 3435 -in $dir/certs/pledge-comb.crt -text 3437 3439 Appendix E. Pledge Device Class Profiles 3441 This specification allows implementers to select between various 3442 functional options for the Pledge, yielding different code size 3443 footprints and different requirements on Pledge hardware. Thus for 3444 each product an optimal trade-off between functionality, development/ 3445 maintenance cost and hardware cost can be made. 3447 This appendix illustrates different selection outcomes by means of 3448 defining different example "profiles" of constrained Pledges. In the 3449 following subsections, these profiles are defined and a comparison is 3450 provided. 3452 E.1. Minimal Pledge 3454 The Minimal Pledge profile (Min) aims to reduce code size and 3455 hardware cost to a minimum. This comes with some severe functional 3456 restrictions, in particular: 3458 * No support for EST re-enrollment: whenever this would be needed, a 3459 factory reset followed by a new bootstrap process is required. 3461 * No support for change of Registrar: for this case, a factory reset 3462 followed by a new bootstrap process is required. 3464 This profile would be appropriate for single-use devices which must 3465 be replaced rather than re-deployed. That might include medical 3466 devices, but also sensors used during construction, such as concrete 3467 temperature sensors. 3469 E.2. Typical Pledge 3471 The Typical Pledge profile (Typ) aims to support a typical 3472 Constrained BRSKI feature set including EST re-enrollment support and 3473 Registrar changes. 3475 E.3. Full-featured Pledge 3477 The Full-featured Pledge profile (Full) illustrates a Pledge category 3478 that supports multiple bootstrap methods, hardware real-time clock, 3479 BRSKI/EST resource discovery, and CSR Attributes request/response. 3480 It also supports most of the optional features defined in this 3481 specification. 3483 E.4. Comparison Chart of Pledge Classes 3485 The below table specifies the functions implemented in the three 3486 example Pledge classes Min, Typ and Full. 3488 +=============================================+=====+=====+======+ 3489 | Function |====================| Profiles -> | Min | Typ | Full | 3490 +=============================================+=====+=====+======+ 3491 | *General* | === | === | ==== | 3492 +---------------------------------------------+-----+-----+------+ 3493 | Support Constrained BRSKI bootstrap | Y | Y | Y | 3494 +---------------------------------------------+-----+-----+------+ 3495 | Support other bootstrap method(s) | - | - | Y | 3496 +---------------------------------------------+-----+-----+------+ 3497 | Real-time clock and cert time checks | - | - | Y | 3498 +---------------------------------------------+-----+-----+------+ 3499 | *Constrained BRSKI* | === | === | ==== | 3500 +---------------------------------------------+-----+-----+------+ 3501 | Discovery for rt=brski* | - | - | Y | 3502 +---------------------------------------------+-----+-----+------+ 3503 | Support pinned Registrar public key (RPK) | Y | - | Y | 3504 +---------------------------------------------+-----+-----+------+ 3505 | Support pinned Registrar certificate | - | Y | Y | 3506 +---------------------------------------------+-----+-----+------+ 3507 | Support pinned Domain CA | - | Y | Y | 3508 +---------------------------------------------+-----+-----+------+ 3509 | *Constrained EST* | === | === | ==== | 3510 +---------------------------------------------+-----+-----+------+ 3511 | Discovery for rt=ace.est* | - | - | Y | 3512 +---------------------------------------------+-----+-----+------+ 3513 | GET /att and response parsing | - | - | Y | 3514 +---------------------------------------------+-----+-----+------+ 3515 | GET /crts format 281 (multiple CA certs) | - | - | Y | 3516 +---------------------------------------------+-----+-----+------+ 3517 | GET /crts only format TBD287 (one CA cert | Y | Y | - | 3518 | only) | | | | 3519 +---------------------------------------------+-----+-----+------+ 3520 | ETag handling support for GET /crts | - | Y | Y | 3521 +---------------------------------------------+-----+-----+------+ 3522 | Re-enrollment supported | - | Y | Y | 3523 | | (1) | | | 3524 +---------------------------------------------+-----+-----+------+ 3525 | 6.6.1 optimized procedure | Y | Y | - | 3526 +---------------------------------------------+-----+-----+------+ 3527 | Pro-active cert re-enrollment at own | N/A | - | Y | 3528 | initiative | | | | 3529 +---------------------------------------------+-----+-----+------+ 3530 | Periodic trust anchor retrieval GET /crts | - | Y | Y | 3531 | | (1) | | | 3532 +---------------------------------------------+-----+-----+------+ 3533 | Supports change of Registrar identity | - | Y | Y | 3534 | | (1) | | | 3535 +---------------------------------------------+-----+-----+------+ 3537 Table 6 3539 Notes: (1) is possible only by doing a factory-reset followed by a 3540 new bootstrap procedure. 3542 Contributors 3544 Russ Housley 3545 Email: housley@vigilsec.com 3547 Authors' Addresses 3549 Michael Richardson 3550 Sandelman Software Works 3551 Email: mcr+ietf@sandelman.ca 3553 Peter van der Stok 3554 vanderstok consultancy 3555 Email: stokcons@bbhmail.nl 3557 Panos Kampanakis 3558 Cisco Systems 3559 Email: pkampana@cisco.com 3561 Esko Dijk 3562 IoTconsultancy.nl 3563 Email: esko.dijk@iotconsultancy.nl