idnits 2.17.1 draft-ietf-anima-constrained-voucher-15.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 21 characters 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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1281 has weird spacing: '...ndatory false...' == Line 1285 has weird spacing: '...ndatory false...' == Line 1528 has weird spacing: '...ndatory false...' == Line 1532 has weird spacing: '...ndatory false...' == Line 1978 has weird spacing: '... brski nee...' -- The document date (7 December 2021) is 870 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ThisRFC' is mentioned on line 2019, but not defined == Missing Reference: 'This RFC' is mentioned on line 2078, but not defined == Unused Reference: 'RFC5280' is defined on line 2199, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-18 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-17 ** 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: A later version (-09) exists of draft-ietf-cose-x509-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-15) exists of draft-ietf-anima-constrained-join-proxy-06 == Outdated reference: A later version (-09) exists of draft-ietf-anima-jws-voucher-01 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-12 == Outdated reference: A later version (-08) exists of draft-richardson-anima-masa-considerations-06 Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Updates: 8366, 8995 (if approved) P. van der Stok 5 Intended status: Standards Track vanderstok consultancy 6 Expires: 10 June 2022 P. Kampanakis 7 Cisco Systems 8 E. Dijk 9 IoTconsultancy.nl 10 7 December 2021 12 Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) 13 draft-ietf-anima-constrained-voucher-15 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 10 June 2022. 49 Copyright Notice 51 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 5 68 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . 6 69 5. Updates to RFC8366 and RFC8995 . . . . . . . . . . . . . . . 7 70 6. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 9 74 6.3.1. RFC8995 Telemetry Returns . . . . . . . . . . . . . . 12 75 6.4. Join Proxy options . . . . . . . . . . . . . . . . . . . 12 76 6.5. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 12 77 6.5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 12 78 6.5.2. CoAP responses . . . . . . . . . . . . . . . . . . . 13 79 6.6. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 13 80 6.6.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 14 81 6.6.2. EST-client Extensions . . . . . . . . . . . . . . . . 15 82 6.6.3. Registrar Extensions . . . . . . . . . . . . . . . . 18 83 6.7. DTLS handshake fragmentation Considerations . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 22 92 8.3. Pinning of Raw Public Keys . . . . . . . . . . . . . . . 23 93 8.4. Considerations for use of IDevID-Issuer . . . . . . . . . 24 94 9. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 9.1. Voucher Request artifact . . . . . . . . . . . . . . . . 25 96 9.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 25 97 9.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 26 98 9.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 27 99 9.1.4. Example voucher request artifact . . . . . . . . . . 30 100 9.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 31 101 9.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 31 102 9.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 31 103 9.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 32 104 9.2.4. Example voucher artifacts . . . . . . . . . . . . . . 35 105 9.3. Signing voucher and voucher-request artifacts with 106 COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 35 107 10. Deployment-specific Discovery Considerations . . . . . . . . 37 108 10.1. 6TSCH Deployments . . . . . . . . . . . . . . . . . . . 37 109 10.2. Generic networks using GRASP . . . . . . . . . . . . . . 37 110 10.3. Generic networks using mDNS . . . . . . . . . . . . . . 38 111 10.4. Thread networks using Mesh Link Establishment (MLE) . . 38 112 10.5. Non-mesh networks using CoAP Discovery . . . . . . . . . 38 113 11. Design Considerations . . . . . . . . . . . . . . . . . . . . 38 114 12. Raw Public Key Use Considerations . . . . . . . . . . . . . . 39 115 12.1. The Registrar Trust Anchor . . . . . . . . . . . . . . . 39 116 12.2. The Pledge Voucher Request . . . . . . . . . . . . . . . 39 117 12.3. The Voucher Response . . . . . . . . . . . . . . . . . . 40 118 13. Use of constrained vouchers with HTTPS . . . . . . . . . . . 40 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 41 120 14.1. Duplicate serial-numbers . . . . . . . . . . . . . . . . 41 121 14.2. IDevID security in Pledge . . . . . . . . . . . . . . . 42 122 14.3. Security of CoAP and UDP protocols . . . . . . . . . . . 42 123 14.4. Registrar Certificate may be self-signed . . . . . . . . 42 124 14.5. Use of RPK alternatives to proximity-registrar-cert . . 42 125 14.6. MASA support of CoAPS . . . . . . . . . . . . . . . . . 43 126 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 127 15.1. Resource Type Registry . . . . . . . . . . . . . . . . . 43 128 15.2. The IETF XML Registry . . . . . . . . . . . . . . . . . 43 129 15.3. The YANG Module Names Registry . . . . . . . . . . . . . 44 130 15.4. The RFC SID range assignment sub-registry . . . . . . . 44 131 15.5. Media Types Registry . . . . . . . . . . . . . . . . . . 44 132 15.5.1. application/voucher-cose+cbor . . . . . . . . . . . 45 133 15.6. CoAP Content-Format Registry . . . . . . . . . . . . . . 45 134 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 135 17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 46 136 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 137 18.1. Normative References . . . . . . . . . . . . . . . . . . 46 138 18.2. Informative References . . . . . . . . . . . . . . . . . 50 139 Appendix A. Library support for BRSKI . . . . . . . . . . . . . 52 140 A.1. OpensSSL . . . . . . . . . . . . . . . . . . . . . . . . 52 141 A.2. mbedTLS . . . . . . . . . . . . . . . . . . . . . . . . . 53 142 Appendix B. Constrained BRSKI-EST messages . . . . . . . . . . . 54 143 B.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 54 144 B.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 55 146 Appendix C. COSE examples . . . . . . . . . . . . . . . . . . . 55 147 C.1. Pledge, Registrar and MASA keys . . . . . . . . . . . . . 59 148 C.1.1. Pledge private key . . . . . . . . . . . . . . . . . 59 149 C.1.2. Registrar private key . . . . . . . . . . . . . . . . 59 150 C.1.3. MASA private key . . . . . . . . . . . . . . . . . . 60 151 C.2. Pledge, Registrar and MASA certificates . . . . . . . . . 60 152 C.2.1. Pledge IDevID certificate . . . . . . . . . . . . . . 60 153 C.2.2. Registrar Certificate . . . . . . . . . . . . . . . . 62 154 C.2.3. MASA Certificate . . . . . . . . . . . . . . . . . . 64 155 C.3. COSE signed voucher request from Pledge to Registrar . . 66 156 C.4. COSE signed voucher request from Registrar to MASA . . . 68 157 C.5. COSE signed voucher from MASA to Pledge via Registrar . . 70 158 Appendix D. Pledge Device Class Profiles . . . . . . . . . . . . 71 159 D.1. Minimal Pledge . . . . . . . . . . . . . . . . . . . . . 72 160 D.2. Typical Pledge . . . . . . . . . . . . . . . . . . . . . 72 161 D.3. Full-featured Pledge . . . . . . . . . . . . . . . . . . 72 162 D.4. Comparison chart of Pledge Classes . . . . . . . . . . . 72 163 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 74 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 166 1. Introduction 168 Secure enrollment of new nodes into constrained networks with 169 constrained nodes presents unique challenges. As explained in 170 [RFC7228], the networks are challenged and the nodes are constrained 171 by energy, memory space, and code size. 173 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 174 described in [RFC8995] provides a solution for secure zero-touch 175 (automated) bootstrap of new (unconfigured) devices. In it, new 176 devices, such as IoT devices, are called "pledges", and equipped with 177 a factory-installed Initial Device Identifier (IDevID) (see 178 [ieee802-1AR]), are enrolled into a network. 180 The BRSKI solution described in [RFC8995] was designed to be modular, 181 and this document describes a version scaled to the constraints of 182 IoT deployments. 184 Therefore, this document defines a constrained version of the voucher 185 artifact (described in [RFC8366]), along with a constrained version 186 of BRSKI. This constrained-BRSKI protocol makes use of the 187 constrained CoAP-based version of EST (EST-coaps from 188 [I-D.ietf-ace-coap-est]) rather than the EST over HTTPS [RFC7030]. 189 Constrained-BRSKI is itself scalable to multiple resource levels 190 through the definition of optional functions. Appendix D illustrates 191 this. 193 In BRSKI, the [RFC8366] voucher is by default serialized to JSON with 194 a signature in CMS [RFC5652]. This document defines a new voucher 195 serialization to CBOR [RFC8949] with a signature in COSE 196 [I-D.ietf-cose-rfc8152bis-struct]. 198 This COSE-signed CBOR-encoded voucher is transported using both 199 secured CoAP and HTTPS. The CoAP connection (between Pledge and 200 Registrar) is to be protected by either OSCORE+EDHOC 201 [I-D.ietf-lake-edhoc] or DTLS (CoAPS). The HTTP connection (between 202 Registrar and MASA) is to be protected using TLS (HTTPS). 204 This document specifies a constrained voucher-request artifact based 205 on Section 3 of [RFC8995], and voucher(-request) transport over CoAP 206 based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est]. 208 The CBOR definitions for the constrained voucher format are defined 209 using the mechanism described in [I-D.ietf-core-yang-cbor] using the 210 SID mechanism explained in [I-D.ietf-core-sid]. As the tooling to 211 convert YANG documents into a list of SID keys is still in its 212 infancy, the table of SID values presented here MUST be considered 213 normative rather than the output of the tool specified in 214 [I-D.ietf-core-sid]. 216 2. Terminology 218 The following terms are defined in [RFC8366], and are used 219 identically as in that document: artifact, domain, imprint, Join 220 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 221 Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and 222 Voucher. 224 The following terms from [RFC8995] are used identically as in that 225 document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, 226 manufacturer, nonced, nonceless, PKIX. 228 The term Pledge Voucher Request, or acronym PVR, is introduced to 229 refer to the voucher request between the pledge and the Registrar. 231 The term Registrar Voucher Request, or acronym RVR, is introduced to 232 refer to the voucher request between the Registrar and the MASA. 234 3. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in 239 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 4. Overview of Protocol 244 [RFC8366] provides for vouchers that assert proximity, authenticate 245 the Registrar, and can offer varying levels of anti-replay 246 protection. 248 The proximity proof provided for in [RFC8366], is an assertion that 249 the Pledge and the Registrar are believed to be close together, from 250 a network topology point of view. Like in [RFC8995], proximity is 251 shown by making TLS connections between the Pledge and Registrar 252 using IPv6 Link-Local addresses. 254 The TLS connection is used to make a Voucher Request. This request 255 is verified by an agent of the Pledge's manufacturer, which then 256 issues a voucher. The voucher provides an authorization statement 257 from the manufacturer indicating that the Registrar is the intended 258 owner of the device. The voucher refers to the Registrar through 259 pinning of the Registrar's identity. 261 This document does not make any extensions to the semantic meaning of 262 vouchers, only the encoding has been changed to optimize for 263 constrained devices and networks. The two main parts of the BRSKI 264 protocol are named separately in this document: BRSKI-EST for the 265 protocol between Pledge and Registrar, and BRSKI-MASA for the 266 protocol between the Registrar and the MASA. 268 Time-based vouchers are supported in this definition, but given that 269 constrained devices are extremely unlikely to have accurate time, 270 their use will be uncommon. Most Pledges using constrained vouchers 271 will be online during enrollment and will use live nonces to provide 272 anti-replay protection rather than expiry times. 274 [RFC8366] defines the voucher artifact, while the Voucher Request 275 artifact was defined in [RFC8995]. This document defines both a 276 constrained voucher and a constrained voucher-request. They are 277 presented in the order "voucher-request", followed by a "voucher" 278 response as this is the order that they occur in the protocol. 280 The constrained voucher request MUST be signed by the Pledge. It 281 signs using the private key associated with its IDevID X.509 282 certificate, or if an IDevID is not available, then the private key 283 associated with its manufacturer-installed raw public key (RPK). 284 Section 12 provides additional details on PKIX-less operations. 286 The constrained voucher MUST be signed by the MASA. 288 For the constrained voucher request this document defines two 289 distinct methods for the Pledge to identify the Registrar: using 290 either the Registrar's X.509 certificate, or using a raw public key 291 (RPK) of the Registrar. 293 For the constrained voucher both methods are supported to indicate 294 (pin) a trusted domain identity: using either a pinned domain X.509 295 certificate, or a pinned raw public key (RPK). 297 The BRSKI architectures mandates that the MASA be aware of the 298 capabilities of the pledge. This is not a drawback as the pledges 299 are constructed by a manufacturer which also arranges for the MASA to 300 be aware of the inventory of devices. 302 The MASA therefore knows if the pledge supports PKIX operations, PKIX 303 format certificates, or if the pledge is limited to Raw Public Keys 304 (RPK). Based upon this, the MASA can select which attributes to use 305 in the voucher for certain operations, like the pinning of the 306 Registrar identity. This is described in more detail in 307 Section 9.2.3, Section 8 and Section 8.3 (for RPK specifically). 309 5. Updates to RFC8366 and RFC8995 311 This section details the ways in which this document updates other 312 RFCs. The terminology for Updates is taken from 313 [I-D.kuehlewind-update-tag]. 315 This document Updates [RFC8366]. It Extends [RFC8366] by creating a 316 new serialization format. 318 This document Updates [RFC8995]. It Amends [RFC8995] by clarifying 319 how pinning is done, and ???. 321 6. BRSKI-EST Protocol 323 This section describes the constrained BRSKI extensions to EST-coaps 324 [I-D.ietf-ace-coap-est] to transport the voucher between Registrar 325 and Pledge (optionally via a Join Proxy) over CoAP. The extensions 326 are targeting low-resource networks with small packets. 328 The constrained BRSKI-EST protocol described in this section is 329 between the Pledge and the Registrar only. 331 6.1. Registrar and the Server Name Indicator (SNI) 333 A DTLS connection is established between the Pledge and the 334 Registrar, similar to the TLS connection described in Section 5.1 of 335 [RFC8995]. This may occur via a Join Proxy as described in 336 Section 6.4. Regardless of the Join Proxy mechanism, the DTLS 337 connection should operate identically. 339 The SNI issue described below affects [RFC8995] as well, and is 340 reported in errata: https://www.rfc-editor.org/errata/eid6648 342 As the Registrar is discovered by IP address, and typically connected 343 via a Join Proxy, the name of the Registrar is not known to the 344 Pledge. The Pledge will not know what the hostname for the Registrar 345 is, so it cannot do RFC6125 DNS-ID validation on the Registrar's 346 certificate. Instead, it must do validation using the RFC8366 347 voucher. 349 As the Pledge does not know the name of the Registrar, the Pledge 350 cannot put any reasonable value into the [RFC6066] Server Name 351 Indicator (SNI). Threfore the Pledge SHOULD omit the SNI extension 352 as per Section 9.2 of [RFC8446]. 354 In some cases, particularly while testing BRSKI, a Pledge may be 355 given the hostname of a particular Registrar to connect to directly. 356 Such a bypass of the discovery process may result in the Pledge 357 taking a different code branch to establish a DTLS connection, and 358 may result in the SNI being inserted by a library. The Registrar 359 MUST ignore any SNI seen. 361 A primary motivation for making the SNI ubiquitous in the public web 362 is because it allows for multi-tenant hosting of HTTPS sites on a 363 single (scarce) IPv4 address. This consideration does not apply to 364 the server function in the Registrar because: 366 * it uses DTLS and CoAP, not HTTPS 368 * it typically uses IPv6, often [RFC4193] Unique Local Address, 369 which are plentiful 371 * the server port number is typically discovered, so multiple 372 tenants can be accomodated via unique port numbers. 374 As per Section 3.6.1 of [RFC7030], the Registrar certificate MUST 375 have the Extended Key Usage (EKU) id-kp-cmcRA. This certificate is 376 also used as a TLS Server Certificate, so it MUST also have the EKU 377 id-kp-serverAuth. 379 6.2. TLS Client Certificates: IDevID authentication 381 As described in Section 5.1 of [RFC8995], the Pledge makes a 382 connection to the Registrar using a TLS Client Certificate for 383 authentication. 385 Subsequently the Pledge will send a Pledge Voucher Request (PVR). 387 As explained below in Section 8.1, the "x5bag" element may be used in 388 the RVR to communicate identity of the Registrar to MASA. The Pledge 389 SHOULD NOT use the x5bag attribute in this way in the PVR. A 390 Registrar that processes a PVR with an x5bag attribute MUST ignore 391 it, and MUST use only the TLS Client Certificate extension for 392 authentication of the Pledge. 394 A situation where the Pledge MAY use the x5bag is for communication 395 of certificate chains to the MASA. This would arise in some vendor- 396 specific situations involving outsourcing of MASA functionality, or 397 rekeying of the IDevID certification authority. 399 6.3. Discovery, URIs and Content Formats 401 To keep the protocol messages small the EST-coaps and constrained- 402 BRSKI URIs are shorter than the respective EST and BRSKI URIs. 404 The EST-coaps server URIs differ from the EST URIs by replacing the 405 scheme https by coaps and by specifying shorter resource path names. 406 Below are some examples; the first two using a discovered short path 407 name and the last one using the well-known URI of EST which requires 408 no discovery. 410 coaps://server.example.com/est/ 411 coaps://server.example.com/e/ 412 coaps://server.example.com/.well-known/est/ 414 Similarly the constrained BRSKI server URIs differ from the BRSKI 415 URIs by replacing the scheme https by coaps and by specifying shorter 416 resource path names. Below are some examples; the first two using a 417 discovered short path name and the last one using the well-known URI 418 prefix which requires no discovery. This is the same "/.well-known/ 419 brski" prefix as defined in Section 5 of [RFC8995]. 421 coaps://server.example.com/brski/ 422 coaps://server.example.com/b/ 423 coaps://server.example.com/.well-known/brski/ 425 Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations 426 supported by EST, for which Table 1 in Section 5.1 of 427 [I-D.ietf-ace-coap-est] enumerates the corresponding EST-coaps short 428 path names. Similarly, Table 1 provides the mapping from the 429 supported BRSKI extension URI paths to the constrained-BRSKI URI 430 paths. 432 +=================+============================+ 433 | BRSKI resource | constrained-BRSKI resource | 434 +=================+============================+ 435 | /requestvoucher | /rv | 436 +-----------------+----------------------------+ 437 | /voucher_status | /vs | 438 +-----------------+----------------------------+ 439 | /enrollstatus | /es | 440 +-----------------+----------------------------+ 442 Table 1: BRSKI URI paths mapping to 443 constrained BRSKI URI paths 445 Note that /requestvoucher indicated above occurs between the Pledge 446 and Registrar (in scope of the BRSKI-EST protocol), but it also 447 occurs between Registrar and MASA. However, as described in 448 Section 6, this section and above table addresses only the BRSKI-EST 449 protocol. 451 Pledges that wish to discover the available BRSKI bootstrap options/ 452 formats, or reduce the size of the CoAP headers by eliminating the 453 "/.well-known/brski" path, can do a discovery operation using 454 [RFC6690] Section 4 by sending a discovery query to the Registrar. 456 For example, if the Registrar supports a short BRSKI URL (/b) and 457 supports the voucher format "application/voucher-cose+cbor" (TBD3), 458 and status reporting in both CBOR and JSON formats: 460 REQ: GET /.well-known/core?rt=brski* 462 RES: 2.05 Content 463 Content-Format: 40 464 Payload: 465 ;rt=brski, 466 ;rt=brski.rv;ct=TBD3, 467 ;rt=brski.vs;ct="50 60", 468 ;rt=brski.es;ct="50 60" 470 The Registrar is under no obligation to provide shorter URLs, and MAY 471 respond to this query with only the "/.well-known/brski/" 472 resources for the short names as defined in Table 1. 474 Registrars that have implemented shorter URLs MUST also respond in 475 equivalent ways to the corresponding "/.well-known/brski/" URLs, and MUST NOT distinguish between them. In particular, a 477 Pledge MAY use the longer and shorter URLs in any combination. 479 When responding to a discovery request for BRSKI resources, the 480 server MAY in addition return the full resource paths and the content 481 types which are supported by these resources as shown in above 482 example. This is useful when multiple content types are specified 483 for a particular resource on the server. The server responds with 484 only the root path for the BRSKI resource (rt=brski, resource /b in 485 above example) and no others in case the client queries for only 486 rt=brski type resources. (So, a query for rt=brski, without the 487 wildcard character.) 489 Without discovery, a longer well-known URL can only be used, such as: 491 REQ: GET /.well-known/brski/rv 493 while with discovery of shorter URLs, a request such as: 495 REQ: GET /b/rv 497 is possible. 499 The return of multiple content-types in the "ct" attribute allows the 500 Pledge to choose the most appropriate one. Note that Content-Format 501 TBD3 ("application/voucher-cose+cbor") is defined in this document. 503 Content-Format TBD3 MUST be supported by the Registrar for the /rv 504 resource. If the "ct" attribute is not indicated for the /rv 505 resource in the link format description, this implies that at least 506 TBD3 is supported. 508 Note that this specification allows for voucher-cose+cbor format 509 requests and vouchers to be transmitted over HTTPS, as well as for 510 voucher-cms+json and other formats yet to be defined over CoAP. The 511 burden for this flexibility is placed upon the Registrar. A Pledge 512 on constrained hardware is expected to support a single format only. 514 The Pledge and MASA need to support one or more formats (at least 515 TBD3) for the voucher and for the voucher request. The MASA needs to 516 support all formats that the Pledge supports. 518 Section 10 details how the Pledge discovers the Registrar and Join 519 Proxy in different deployment scenarios. 521 6.3.1. RFC8995 Telemetry Returns 523 [RFC8995] defines two telemetry returns from the Pledge which are 524 sent to the Registrar. These are the BRSKI Status Telemetry 525 [RFC8995], Section 5.7 and the Enrollment Status Telemetry [RFC8995], 526 Section 5.9.4. These are two POST operations made the by Pledge at 527 two key steps in the process. 529 [RFC8995] defines the content of these POST operations in CDDL, which 530 are serialized as JSON. This document extends the list of acceptable 531 formats to CBOR as well as JSON, using the rules from [RFC8610]. 533 The existing JSON format is described as CoAP Content-Format 50 534 ("application/json"), and it MAY be supported. The new CBOR format 535 described as CoAP Content-Format 60 ("application/cbor"), MUST be 536 supported by the Registrar for both the /vs and /es resources. 538 6.4. Join Proxy options 540 [I-D.ietf-anima-constrained-join-proxy] specifies a constrained Join 541 Proxy that is optionally placed between Pledge and Registrar. This 542 includes methods for discovery of the Join Proxy by the Pledge and 543 discovery of the Registrar by the Join Proxy. 545 6.5. Extensions to BRSKI 547 6.5.1. Discovery 549 The Pledge discovers an IP address and port number that connects to 550 the Registrar (possibly via a Join Proxy), and it establishes a DTLS 551 connection. 553 No further discovery of hosts or port numbers is required, but a 554 pledge that can do more than one kind of enrollment (future work 555 offers protocols other than [I-D.ietf-ace-coap-est]), then a pledge 556 may need to use CoAP Discovery to determine what other protocols are 557 available. 559 A Pledge that only supports the EST-coaps enrollment method SHOULD 560 NOT use discovery for BRSKI resources. It is more efficient to just 561 try the supported enrollment method via the well-known BRSKI/EST- 562 coaps resources. This also avoids the Pledge doing any CoRE Link 563 Format parsing, which is specified in [I-D.ietf-ace-coap-est], 564 Section 4.1. 566 The Registrar MUST support all of the EST resources at their default 567 ".well-known" locations (on the specified port) as well as any 568 server-specific shorter form that might also be supported. 570 However, when discovery is being done by the Pledge, it is possible 571 for the Registrar to return references to resources which are on 572 different port numbers. The Registrar SHOULD NOT use different ports 573 numbers by default, because a Pledge that is connected via a Join 574 Proxy can only access a single UDP port. A Registrar configured to 575 never use Join Proxies MAY be configured to use multiple port 576 numbers. Therefore a Registrar MUST host all discoverable BRSKI 577 resources on the same (UDP) server port that the Pledge's DTLS 578 connection is using. Using the same UDP server port for all 579 resources allows the Pledge to continue via the same DTLS connection 580 which is more efficient. 582 6.5.2. CoAP responses 584 [RFC8995], Section 5 defines a number of HTTP response codes that the 585 Registrar is to return when certain conditions occur. 587 The 401, 403, 404, 406 and 415 response codes map directly to CoAP 588 codes 4.01, 4.03, 4.04, 4.06 and 4.15. 590 The 202 Retry process which occurs in the voucher request, is to be 591 handled in the same way as Section 5.7 of [I-D.ietf-ace-coap-est] 592 process for Delayed Responses. 594 6.6. Extensions to EST-coaps 596 This document extends [I-D.ietf-ace-coap-est], and it inherits the 597 functions described in that document: specifically, the mandatory 598 Simple (Re-)Enrollment (/sen and /sren) and Certification Authority 599 certificates request (/crts). Support for CSR Attributes Request 600 (/att) and server-side key generation (/skg, /skc) remains optional 601 for the EST server. 603 Collecting the resource definitions from both [RFC8995], [RFC7030], 604 and [I-D.ietf-ace-coap-est] results in the following shorter forms of 605 URI paths for the commonly used resources: 607 +------------------+-------------------+----------------+ 608 | EST + BRSKI | Constrained-BRSKI | Well-known URI + 609 | | | namespace + 610 +------------------+-------------------+----------------+ 611 | /requestvoucher | /rv | brski + 612 | /voucher_status | /vs | brski + 613 | /csrattrs | /att | est + 614 | /simpleenroll | /sen | est + 615 | /cacerts | /crts | est + 616 | /enrollstatus | /es | brski + 617 | /simplereenroll | /sren | est + 618 +------------------+-------------------+----------------+ 620 6.6.1. Pledge Extensions 622 This section defines extensions to the BRSKI Pledge, which are 623 applicable during the BRSKI bootstrap procedure. A Pledge which only 624 supports the EST-coaps enrollment method, SHOULD NOT use discovery 625 for EST-coaps resources, because it is more efficient to enroll (e.g. 626 /sen) via the well-known EST resource on the current DTLS connection. 627 This avoids an additional round-trip of packets and avoids the Pledge 628 having to unnecessarily implement CoRE Link Format parsing. 630 A constrained Pledge SHOULD NOT perform the optional EST "CSR 631 attributes request" (/att) to minimize network traffic. The Pledge 632 selects which attributes to include in the CSR. 634 One or more Subject Distinguished Name fields MUST be included. If 635 the Pledge has no specific information on what attributes/fields are 636 desired in the CSR, it MUST use the Subject Distinguished Name fields 637 from its IDevID unmodified. The Pledge can receive such information 638 via the voucher (encoded in a vendor-specific way) or via some other, 639 out-of-band means. 641 A constrained Pledge MAY use the following optimized EST-coaps 642 procedure to minimize network traffic. 644 1. if the voucher, that validates the current Registrar, contains a 645 single pinned domain CA certificate, the Pledge provisionally 646 considers this certificate as the EST trust anchor, as if it were 647 the result of "CA certificates request" (/crts) to the Registrar. 649 2. Using this CA certificate as trust anchor it proceeds with EST 650 simple enrollment (/sen) to obtain its provisionally trusted 651 LDevID certificate. 653 3. If the Pledge validates that the trust anchor CA was used to sign 654 its LDevID certificate, the Pledge accepts the pinned domain CA 655 certificate as the legitimate trust anchor CA for the Registrar's 656 domain and accepts the associated LDevID certificate. 658 4. If the trust anchor CA was NOT used to sign its LDevID 659 certificate, the Pledge MUST perform an actual "CA certificates 660 request" (/crts) to the EST server to obtain the EST CA trust 661 anchor(s) since these can differ from the (temporary) pinned 662 domain CA. 664 5. When doing this /crts request, the Pledge MAY use a CoAP Accept 665 Option with value TBD287 ("application/pkix-cert") to limit the 666 number of returned EST CA trust anchors to only one. A 667 constrained Pledge MAY support only this format in a /crts 668 response, per Section 5.3 of [I-D.ietf-ace-coap-est]. 670 6. If the Pledge cannot obtain the single CA certificate or the 671 finally validated CA certificate cannot be chained to the LDevID 672 certificate, then the Pledge MUST abort the enrollment process 673 and report the error using the enrollment status telemetry (/es). 675 Note that even though the Pledge may avoid performing any /crts 676 request using the above EST-coaps procedure during bootstrap, it 677 SHOULD support retrieval of the trust anchor CA periodically as 678 detailed in the next section. 680 6.6.2. EST-client Extensions 682 This section defines extensions to EST-coaps clients, used after the 683 BRSKI bootstrap procedure is completed. (Note that such client is 684 not called "Pledge" in this section, since it is already enrolled 685 into the domain.) A constrained EST-coaps client MAY support only 686 the Content-Format TBD287 ("application/pkix-cert") in a /crts 687 response, per Section 5.3 of [I-D.ietf-ace-coap-est]. In this case, 688 it can only store one trust anchor of the domain. 690 An EST-coaps client that has an idea of the current time (internally, 691 or via NTP) SHOULD consider the validity time of the trust anchor CA, 692 and MAY begin requesting a new trust anchor CA using the /crts 693 request when the CA has 50% of it's validity time (notAfter - 694 notBefore) left. A client without access to the current time cannot 695 decide if the trust anchor CA has expired, and SHOULD poll 696 periodically for a new trust anchor using the /crts request at an 697 interval of approximately 1 month. An EST-coaps server SHOULD 698 include the CoAP ETag Option in every response to a /crts request, to 699 enable clients to perform low-overhead validation whether their trust 700 anchor CA is still valid. The EST-coaps client SHOULD store the ETag 701 resulting from a /crts response in memory and SHOULD use this value 702 in an ETag Option in its next GET /crts request. 704 The above-mentioned limitation that an EST-coaps client may support 705 only one trust anchor CA is not an issue in case the domain trust 706 anchor remains stable. However, special consideration is needed for 707 cases where the domain trust anchor can change over time. Such a 708 change may happen due to relocation of the client device to a new 709 domain, or due to key update of the trust anchor as described in 710 [RFC4210], Section 4.4. 712 From the client's viewpoint, a trust anchor change typically happens 713 during EST re-enrollment: a change of domain CA requires all devices 714 operating under the old domain CA to acquire a new LDevID issued by 715 the new domain CA. A client's re-enrollment may be triggered by 716 various events, such as an instruction to re-enroll sent by a domain 717 entity, or an imminent expiry of its LDevID certificate. How the re- 718 enrollment is explicitly triggered on the client by a domain entity, 719 such as a commissioner or a Registrar, is out of scope of this 720 specification. 722 The mechanism described in [RFC4210], Section 4.4 for Root CA key 723 update requires four certificates: OldWithOld, OldWithNew, 724 NewWithOld, and NewWithNew. The OldWithOld certificate is already 725 stored in the EST client's trust store. The NewWithNew certificate 726 will be distributed as the single certificate in a /crts response, 727 during EST re-enrollment. Since the EST client can only accept a 728 single certificate in a /crts response it implies that the EST client 729 cannot obtain the certificates OldWithNew and NewWithOld in this way, 730 to perform the complete verification of the new domain CA. Instead, 731 the client only verifies the EST server (Registrar) using its old 732 domain CA certificate in its trust store as detailed below, and based 733 on this trust in the active and valid DTLS connection it 734 automatically trusts the new (NewWithNew) domain CA certificate that 735 the EST server provides in the /crts response. 737 In this manner, even during rollover of trust anchors, it is possible 738 to have only a single trust anchor provided in a /crts response. 740 During the period of the certificate renewal, it is not possible to 741 create new communication channels between devices with NewCA 742 certificates devices with OldCA certificates. One option is that 743 devices should avoid restarting existing DTLS or OSCORE connections 744 during this interval that new certificates are being deployed. The 745 recommended period for certificate renewal is 24 hours. For re- 746 enrollment, the constrained EST-coaps client MUST support the 747 following EST-coaps procedure, where optional re-enrollment to a new 748 domain is under control of the Registrar: 750 1. The client connects with DTLS to the Registrar, and authenticates 751 with its present domain certificate (LDevID certificate) as 752 usual. The Registrar authenticates itself with its domain 753 certificate that is trusted by the client, i.e. it chains to the 754 single trust anchor that the client has stored. This is the 755 "old" trust anchor, the one that will be eventually replaced in 756 case the Registrar decides to re-enroll the client into a new 757 domain. 759 2. The client performs the simple re-enrollment request (/sren) and 760 upon success it obtains a new LDevID. 762 3. The client verifies the new LDevID against its (single) existing 763 domain trust anchor. If it chains successfully, this means the 764 trust anchor did not change and the client MAY skip retrieving 765 the current CA certificate using the "CA certificates request" 766 (/crts). If it does not chain successfully, this means the trust 767 anchor was changed/updated and the client then MUST retrieve the 768 new domain trust anchor using the "CA certificates request" 769 (/crts). 771 4. If the client retrieved a new trust anchor in step 3, then it 772 MUST verify that the new trust anchor chains with the new LDevID 773 certificate it obtained in step 2. If it chains successfully, 774 the client stores both, accepts the new LDevID certificate and 775 stops using it prior LDevID certificate. If it does not chain 776 successfully, the client MUST NOT update its LDevID certificate, 777 it MUST NOT update its (single) domain trust anchor, and the 778 client MUST abort the enrollment process and report the error to 779 the Registrar using enrollment status telemetry (/es). 781 Note that even though the EST-coaps client may skip the /crts request 782 in step 3, it SHOULD support retrieval of the trust anchor CA 783 periodically as detailed earlier in this section. 785 6.6.3. Registrar Extensions 787 A Registrar SHOULD host any discoverable EST-coaps resources on the 788 same (UDP) server port that the Pledge's DTLS initial connection is 789 using. This avoids the overhead of the Pledge reconnecting using 790 DTLS, when it performs EST enrollment after the BRSKI voucher 791 request. 793 The Content-Format 50 (application/json) MUST be supported and 60 794 (application/cbor) MUST be supported by the Registrar for the /vs and 795 /es resources. 797 Content-Format TBD3 MUST be supported by the Registrar for the /rv 798 resource. 800 When a Registrar receives a "CA certificates request" (/crts) request 801 with a CoAP Accept Option with value TBD287 ("application/pkix-cert") 802 it SHOULD return only the single CA certificate that is the 803 envisioned or actual authority for the current, authenticated Pledge 804 making the request. 806 If the Pledge included in its request an Accept Option for only the 807 TBD287 ("application/pkix-cert") Content Format, but the domain has 808 been configured to operate with multiple CA trust anchors only, then 809 the Registrar returns a 4.06 Not Acceptable error to signal that the 810 Pledge needs to use the Content Format 281 ("application/pkcs7-mime; 811 smime-type=certs-only") to retrieve all the certificates. 813 If the current authenticated client is an EST-coaps client that was 814 already enrolled in the domain, and the Registrar is configured to 815 assign this client to a new domain CA trust anchor during the next 816 EST re-enrollment procedure, then the Registrar MUST respond with the 817 new domain CA certificate in case the client performs the "CA 818 Certificates request" (/crts) with an Accept Option for TBD287 only. 819 This signals the client that a new domain is assigned to it. The 820 client follows the procedure as defined in Section 6.6.2. 822 6.7. DTLS handshake fragmentation Considerations 824 DTLS includes a mechanism to fragment the handshake messages. This 825 is described in Section 4.4 of [I-D.ietf-tls-dtls13]. The protocol 826 described in this document will often be used with a Join Proxy 827 described in [I-D.ietf-anima-constrained-join-proxy]. The Join Proxy 828 will need some overhead, while the maximum packet sized guaranteed on 829 802.15.4 networks is 1280 bytes. It is RECOMMENDED that a PMTU of 830 1024 bytes be assumed for the DTLS handshake. It is unlikely that 831 any Packet Too Big indications [RFC4443] will be relayed by the Join 832 Proxy. 834 During the operation of the constrained BRSKI-EST protocol, the CoAP 835 Blockwise transfer mechanism will be used when message sizes exceed 836 the PMTU. A Pledge/EST-client on a constrained network MUST use the 837 (D)TLS maximum fragment length extension ("max_fragment_length") 838 defined in Section 4 of [RFC6066] with the maximum fragment length 839 set to a value of either 2^9 or 2^10. 841 7. BRSKI-MASA Protocol 843 This section describes extensions to and clarifications of the BRSKI- 844 MASA protocol between Registrar and MASA. 846 7.1. Protocol and Formats 848 Section 5.4 of [RFC8995] describes a connection between the Registrar 849 and the MASA as being a normal TLS connection using HTTPS. This 850 document does not change that. The Registrar MUST use the format 851 "application/voucher-cose+cbor" in its voucher request to MASA, when 852 the Pledge uses this format in its reauqtes to the Registrar 853 [RFC8995]. 855 The MASA only needs to support formats for which there are Pledges 856 that use that format. 858 The Registrar MUST use the same format for the RVR as the Pledge used 859 for its PVR. 861 The Registrar indicates the voucher format it wants to receive from 862 MASA using the HTTP Accept header. This format MUST be the same as 863 the format of the PVR, so that the Pledge can parse it. 865 At the moment of writing the creation of coaps based MASAs is deemed 866 unrealistic. The use of CoAP for the BRSKI-MASA connection can be 867 the subject of another document. Some consideration was made to 868 specify CoAP support for consistency, but: 870 * the Registrar is not expected to be so constrained that it cannot 871 support HTTPS client connections. 873 * the technology and experience to build Internet-scale HTTPS 874 responders (which the MASA is) is common, while the experience 875 doing the same for CoAP is much less common. 877 * a Registrar is likely to provide onboarding services to both 878 constrained and non-constrained devices. Such a Registrar would 879 need to speak HTTPS anyway. 881 * a manufacturer is likely to offer both constrained and non- 882 constrained devices, so there may in practice be no situation in 883 which the MASA could be CoAP-only. Additionally, as the MASA is 884 intended to be a function that can easily be oursourced to a 885 third-party service provider, reducing the complexity would also 886 seem to reduce the cost of that function. 888 * security-related considerations: see Section 14.6. 890 7.2. Registrar Voucher Request 892 If the PVR contains a proximity assertion, the Registrar MUST 893 propagate this assertion into the RVR by including the "assertion" 894 field with the value "proximity". This conforms to the example in 895 Section 3.3 of [RFC8995] of carrying the assertion forward. 897 7.3. MASA and the Server Name Indicator (SNI) 899 A TLS/HTTPS connection is established between the Registrar and MASA. 901 Section 5.4 of [RFC8995] explains this process, and there are no 902 externally visible changes. A MASA that supports the unconstrained 903 voucher formats should be able to support constrained voucher formats 904 equally well. 906 There is no requirement that a single MASA be used for both 907 constrained and unconstrained voucher requests: the choice of MASA is 908 determined by the id-mod-MASAURLExtn2016 extension contained in the 909 IDevID. 911 The Registrar MUST do [RFC6125] DNS-ID checks on the contents of the 912 certificate provided by the MASA. 914 In constrast to the Pledge/Registrar situation, the Registrar always 915 knows the name of the MASA, and MUST always include an [RFC6066] 916 Server Name Indicator. The SNI is optional in TLS1.2, but common. 917 The SNI it considered mandatory with TLS1.3. 919 The presence of the SNI is needed by the MASA, in order for the 920 MASA's server to host multiple tenants (for different customers). 922 The Registrar SHOULD use a TLS Client Certificate to authenticate to 923 the MASA per Section 5.4.1 of [RFC8995]. If the certificate that the 924 Registrar uses is marked as a id-kp-cmcRA certificate, via Extended 925 Key Usage, then it MUST also have the id-kp-clientAuth EKU attribute 926 set. 928 7.3.1. Registrar Certificate Requirement 930 In summary for typical Registrar use, where a single Registrar 931 certificate is used, then the certificate MUST have EKU of: id-kp- 932 cmcRA, id-kp-serverAuth, id-kp-clientAuth. 934 8. Pinning in Voucher Artifacts 936 The voucher is a statement by the MASA for use by the Pledge that 937 provides the identity of the Pledge's owner. This section describes 938 how the owner's identity is determined and how it is specified within 939 the voucher. 941 8.1. Registrar Identity Selection and Encoding 943 Section 5.5 of [RFC8995] describes BRSKI policies for selection of 944 the owner identity. It indicates some of the flexibility that is 945 possible for the Registrar, and recommends the Registrar to include 946 only certificates in the voucher request (CMS) signing structure that 947 participate in the certificate chain that is to be pinned. 949 The MASA is expected to evaluate the certificates included by the 950 Registrar in its voucher request, forming them into a chain with the 951 Registrar's (signing) identity on one end. Then, it pins a 952 certificate selected from the chain. For instance, for a domain with 953 a two-level certification authority (see Figure 1), where the 954 voucher-request has been signed by "Registrar", its signing structure 955 includes two additional CA certificates. The arrows in the figure 956 indicate the issuing of a certificate, i.e. author of (1) issued (2) 957 and author of (2) issued (3). 959 .------------------. 960 | domain CA (1) | 961 | trust anchor | 962 '------------------' 963 | 964 v 965 .------------. 966 | domain (2) | 967 | Sub-CA | 968 '------------' 969 | 970 | 971 v 972 .----------------. 973 | domain | 974 | Registrar (3) | 975 | EE certificate | 976 '----------------' 978 Figure 1: Two-Level CA PKI 980 When the Registrar is using a COSE-signed constrained voucher request 981 towards MASA, instead of a regular CMS-signed voucher request, the 982 COSE_Sign1 object contains a protected and an unprotected header. 983 The Registrar MUST place all the certificates needed to validate the 984 signature chain from the Registrar on the RVR in an "x5bag" attribute 985 in the unprotected header [I-D.ietf-cose-x509]. 987 The "x5bag" attribute is very important as it provides the required 988 signals from the Registrar to control what identity is pinned in the 989 resulting voucher. This is explained in the next section. 991 8.2. MASA Pinning Policy 993 The MASA, having assembled and verified the chain in the signing 994 structure of the voucher request needs to select a certificate to 995 pin. (For the case that only the Registrar's End-Entity certificate 996 is included, only this certificate can be selected and this section 997 does not apply.) The BRSKI policy for pinning by the MASA as 998 described in Section 5.5.2 of [RFC8995] leaves much flexibility to 999 the manufacturer. 1001 The present document adds the following rules to the MASA pinning 1002 policy to reduce the network load: 1004 1. for a voucher containing a nonce, it SHOULD select the most 1005 specific (lowest-level) CA certificate in the chain. 1007 2. for a nonceless voucher, it SHOULD select the least-specific 1008 (highest-level) CA certificate in the chain that is allowed under 1009 the MASA's policy for this specific domain. 1011 The rationale for 1. is that in case of a voucher with nonce, the 1012 voucher is valid only in scope of the present DTLS connection between 1013 Pledge and Registrar anyway, so there is no benefit to pin a higher- 1014 level CA. By pinning the most specific CA the constrained Pledge can 1015 validate its DTLS connection using less crypto operations. The 1016 rationale for pinning a CA instead of the Registrar's End-Entity 1017 certificate directly is based on the following benefit on constrained 1018 networks: the pinned certificate in the voucher can in common cases 1019 be re-used as a Domain CA trust anchor during the EST enrollment and 1020 during the operational phase that follows after EST enrollment, as 1021 explained in Section 6.6.1. 1023 The rationale for 2. follows from the flexible BRSKI trust model for, 1024 and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of 1025 [RFC8995]). 1027 Refering to Figure 1 of a domain with a two-level certification 1028 authority, the most specific CA ("Sub-CA") is the identity that is 1029 pinned by MASA in a nonced voucher. A Registrar that wished to have 1030 only the Registrar's End-Entity certificate pinned would omit the 1031 "domain CA" and "Sub-CA" certificates from the voucher-request. 1033 In case of a nonceless voucher, depending on the trust level, the 1034 MASA pins the "Registrar" certificate (low trust in customer), or the 1035 "Sub-CA" certificate (in case of medium trust, implying that any 1036 Registrar of that sub-domain is acceptable), or even the "domain CA" 1037 certificate (in case of high trust in the customer, and possibly a 1038 pre-agreed need of the customer to obtain flexible long-lived 1039 vouchers). 1041 8.3. Pinning of Raw Public Keys 1043 Specifically for constrained use cases, the pinning of the raw public 1044 key (RPK) of the Registrar is also supported in the constrained 1045 voucher, instead of an X.509 certificate. If an RPK is pinned it 1046 MUST be the RPK of the Registrar. 1048 When the Pledge is known by MASA to support RPK but not X.509 1049 certificates, the voucher produced by the MASA pins the RPK of the 1050 Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk- 1051 sha256" field of a voucher. This is described in more detail in 1052 Section 9.2.3. A Pledge that does not support X.509 certificates 1053 cannot use EST to enroll; it has to use another method for enrollment 1054 without certificates and the Registrar has to support this method 1055 also. It is possible that the Pledge will not enroll, but instead 1056 only a network join operation will occur (See [RFC9031]). How the 1057 Pledge discovers this method and details of the enrollment method are 1058 out of scope of this document. 1060 When the Pledge is known by MASA to support PKIX format certificates, 1061 the "pinned-domain-cert" field present in a voucher typically pins a 1062 domain certificate. That can be either the End-Entity certificate of 1063 the Registrar, or the certificate of a domain CA of the Registrar's 1064 domain as specified in Section 8.2. However, if the Pledge is known 1065 to also support RPK pinning and the MASA intends to identify the 1066 Registrar in the voucher (not the CA), then MASA MUST pin the RPK 1067 (RPK3 in Figure 2) of the Registrar instead of the Registrar's End- 1068 Entity certificate to save space in the voucher. 1070 .------------. 1071 | pub-CA (1) | 1072 '------------' 1073 | 1074 v 1075 .------------. 1076 | sub-CA (2) | 1077 '------------' 1078 | 1079 v 1080 .--------------. 1081 | Registrar(3) | 1082 | RPK3 | 1083 '--------------' 1085 Figure 2: Raw Public Key pinning 1087 8.4. Considerations for use of IDevID-Issuer 1089 [RFC8366] and [RFC8995] defines the idevid-issuer attribute for 1090 voucher and voucher-request (respectively), but they summarily 1091 explain when to use it. 1093 The use of idevid-issuer is provided so that the serial-number to 1094 which the issued voucher pertains can be relative to the entity that 1095 issued the devices' IDevID. In most cases there is a one to one 1096 relationship between the trust anchor that signs vouchers (and is 1097 trusted by the pledge), and the Certification Authority that signs 1098 the IDevID. In that case, the serial-number in the voucher must 1099 refer to the same device as the serial-number that is in IDevID 1100 certificate. 1102 However, there situations where the one to one relationship may be 1103 broken. This occurs whenever a manufacturer has a common MASA, but 1104 different products (on different assembly lines) are produced with 1105 identical serial numbers. A system of serial numbers which is just a 1106 simple counter is a good example of this. A system of serial numbers 1107 where there is some prefix relating the product type does not fit 1108 into this, even if the lower digits are a counter. 1110 It is not possible for the Pledge or the Registrar to know which 1111 situation applies. The question to be answered is whether or not to 1112 include the idevid-issuer in the PVR and the RVR. A second question 1113 arisews as to what the format of the idevid-issuer contents are. 1115 Analysis of the situation shows that the pledge never needs to 1116 include the idevid-issuer in it's PVR, because the pledge's IDevID 1117 certificate is available to the Registrar, and the Authority Key 1118 Identifier is contained within that. The pledge therefore has no 1119 need to repeat this. 1121 For the RVR, the Registrar has to examine the pledge's IDevID 1122 certificate to discover the serial number for the Registrar's Voucher 1123 Request (RVR). This is clear in Section 5.5 of [RFC8995]. That 1124 section also clarifies that the idevid-issuer is to be included in 1125 the RVR. 1127 Concerning the Authority Key Identifier, [RFC8366] specifies that the 1128 entire object i.e. the extnValue OCTET STRING is to be included: 1129 comprising the AuthorityKeyIdentifier, SEQUENCE, Choice as well as 1130 the OCTET STRING that is the keyIdentifier. 1132 9. Artifacts 1134 This section describes for both the voucher request and the voucher 1135 first the abstract (tree) definition as explained in [RFC8340]. This 1136 provides a high-level view of the contents of each artifact. 1138 Then the assigned SID values are presented. These have been assigned 1139 using the rules in [I-D.ietf-core-sid]. 1141 9.1. Voucher Request artifact 1143 9.1.1. Tree Diagram 1145 The following diagram is largely a duplicate of the contents of 1146 [RFC8366], with the addition of the fields proximity-registrar-pubk, 1147 proximity-registrar-pubk-sha256, proximity-registrar-cert, and prior- 1148 signed-voucher-request. 1150 prior-signed-voucher-request is only used between the Registrar and 1151 the MASA. proximity-registrar-pubk or proximity-registrar-pubk-sha256 1152 optionally replaces proximity-registrar-cert for the most constrained 1153 cases where RPK is used by the Pledge. 1155 module: ietf-voucher-request-constrained 1157 grouping voucher-request-constrained-grouping 1158 +-- voucher 1159 +-- created-on? yang:date-and-time 1160 +-- expires-on? yang:date-and-time 1161 +-- assertion enumeration 1162 +-- serial-number string 1163 +-- idevid-issuer? binary 1164 +-- pinned-domain-cert? binary 1165 +-- domain-cert-revocation-checks? boolean 1166 +-- nonce? binary 1167 +-- last-renewal-date? yang:date-and-time 1168 +-- proximity-registrar-pubk? binary 1169 +-- proximity-registrar-pubk-sha256? binary 1170 +-- proximity-registrar-cert? binary 1171 +-- prior-signed-voucher-request? binary 1173 9.1.2. SID values 1175 SID Assigned to 1176 --------- -------------------------------------------------- 1177 2501 data /ietf-voucher-request-constrained:voucher 1178 2502 data .../assertion 1179 2503 data .../created-on 1180 2504 data .../domain-cert-revocation-checks 1181 2505 data .../expires-on 1182 2506 data .../idevid-issuer 1183 2507 data .../last-renewal-date 1184 2508 data /ietf-voucher-request-constrained:voucher/nonce 1185 2509 data .../pinned-domain-cert 1186 2510 data .../prior-signed-voucher-request 1187 2511 data .../proximity-registrar-cert 1188 2513 data .../proximity-registrar-pubk 1189 2512 data .../proximity-registrar-pubk-sha256 1190 2514 data .../serial-number 1192 WARNING, obsolete definitions 1194 9.1.3. YANG Module 1196 In the constrained-voucher-request YANG module, the voucher is 1197 "augmented" within the "used" grouping statement such that one 1198 continuous set of SID values is generated for the constrained- 1199 voucher-request module name, all voucher attributes, and the 1200 constrained-voucher-request attributes. Two attributes of the 1201 voucher are "refined" to be optional. 1203 file "ietf-voucher-request-constrained@2021-04-15.yang" 1204 module ietf-voucher-request-constrained { 1205 yang-version 1.1; 1207 namespace 1208 "urn:ietf:params:xml:ns:yang:ietf-voucher-request-constrained"; 1209 prefix "constrained"; 1211 import ietf-restconf { 1212 prefix rc; 1213 description 1214 "This import statement is only present to access 1215 the yang-data extension defined in RFC 8040."; 1216 reference "RFC 8040: RESTCONF Protocol"; 1217 } 1219 import ietf-voucher { 1220 prefix "v"; 1221 } 1223 organization 1224 "IETF ANIMA Working Group"; 1226 contact 1227 "WG Web: 1228 WG List: 1229 Author: Michael Richardson 1230 1231 Author: Peter van der Stok 1232 1233 Author: Panos Kampanakis 1234 "; 1236 description 1237 "This module defines the format for a voucher request, 1238 which is produced by a pledge to request a voucher. 1239 The voucher-request is sent to the potential owner's 1240 Registrar, which in turn sends the voucher request to 1241 the manufacturer or its delegate (MASA). 1243 A voucher is then returned to the pledge, binding the 1244 pledge to the owner. This is a constrained version of the 1245 voucher-request present in 1246 {{I-D.ietf-anima-bootstrap-keyinfra}} 1248 This version provides a very restricted subset appropriate 1249 for very constrained devices. 1250 In particular, it assumes that nonce-ful operation is 1251 always required, that expiration dates are rather weak, as no 1252 clocks can be assumed, and that the Registrar is identified 1253 by either a pinned Raw Public Key of the Registrar, or by a 1254 pinned X.509 certificate of the Registrar or domain CA. 1256 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1257 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1258 and 'OPTIONAL' in the module text are to be interpreted as 1259 described in RFC 2119."; 1261 revision "2021-04-15" { 1262 description 1263 "Initial version"; 1264 reference 1265 "RFC XXXX: Voucher Profile for Constrained Devices"; 1266 } 1268 rc:yang-data voucher-request-constrained-artifact { 1269 // YANG data template for a voucher. 1270 uses voucher-request-constrained-grouping; 1271 } 1273 // Grouping defined for future usage 1274 grouping voucher-request-constrained-grouping { 1275 description 1276 "Grouping to allow reuse/extensions in future work."; 1278 uses v:voucher-artifact-grouping { 1280 refine voucher/created-on { 1281 mandatory false; 1282 } 1284 refine voucher/pinned-domain-cert { 1285 mandatory false; 1286 } 1288 augment "voucher" { 1289 description "Base the constrained voucher-request upon the 1290 regular one"; 1292 leaf proximity-registrar-pubk { 1293 type binary; 1294 description 1295 "The proximity-registrar-pubk replaces 1296 the proximity-registrar-cert in constrained uses of 1297 the voucher-request. 1298 The proximity-registrar-pubk is the 1299 Raw Public Key of the Registrar. This field is encoded 1300 as specified in RFC7250, section 3. 1301 The ECDSA algorithm MUST be supported. 1302 The EdDSA algorithm as specified in 1303 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1304 Support for the DSA algorithm is not recommended. 1305 Support for the RSA algorithm is a MAY, but due to 1306 size is discouraged."; 1307 } 1309 leaf proximity-registrar-pubk-sha256 { 1310 type binary; 1311 description 1312 "The proximity-registrar-pubk-sha256 1313 is an alternative to both 1314 proximity-registrar-pubk and pinned-domain-cert. 1315 In many cases the public key of the domain has already 1316 been transmitted during the key agreement protocol, 1317 and it is wasteful to transmit the public key another 1318 two times. 1319 The use of a hash of public key info, at 32-bytes for 1320 sha256 is a significant savings compared to an RSA 1321 public key, but is only a minor savings compared to 1322 a 256-bit ECDSA public-key. 1323 Algorithm agility is provided by extensions to this 1324 specification which may define a new leaf for another 1325 hash type."; 1326 } 1328 leaf proximity-registrar-cert { 1329 type binary; 1330 description 1331 "An X.509 v3 certificate structure as specified by 1332 RFC 5280, 1333 Section 4 encoded using the ASN.1 distinguished encoding 1334 rules (DER), as specified in ITU-T X.690. 1336 The first certificate in the Registrar TLS server 1337 certificate_list sequence (see [RFC5246]) presented by 1338 the Registrar to the Pledge. This field or one of its 1339 alternatives MUST be populated in a 1340 Pledge's voucher request if the proximity assertion is 1341 populated."; 1342 } 1344 leaf prior-signed-voucher-request { 1345 type binary; 1346 description 1347 "If it is necessary to change a voucher, or re-sign and 1348 forward a voucher that was previously provided along a 1349 protocol path, then the previously signed voucher 1350 SHOULD be included in this field. 1352 For example, a pledge might sign a proximity voucher, 1353 which an intermediate registrar then re-signs to 1354 make its own proximity assertion. This is a simple 1355 mechanism for a chain of trusted parties to change a 1356 voucher, while maintaining the prior signature 1357 information. 1359 The pledge MUST ignore all prior voucher information 1360 when accepting a voucher for imprinting. Other 1361 parties MAY examine the prior signed voucher 1362 information for the purposes of policy decisions. 1363 For example, this information could be useful to a 1364 MASA to determine that both pledge and registrar 1365 agree on proximity assertions. The MASA SHOULD 1366 remove all prior-signed-voucher-request information when 1367 signing a voucher for imprinting so as to minimize the 1368 final voucher size."; 1369 } 1370 } 1371 } 1372 } 1373 } 1374 1376 9.1.4. Example voucher request artifact 1378 Below is a CBOR serialization of an example constrained voucher 1379 request from a Pledge to a Registrar, shown in CBOR diagnostic 1380 notation. The enum value of the assertion field is calculated to be 1381 2 by following the algorithm described in section 9.6.4.2 of 1382 [RFC7950]. Four dots ("....") in a CBOR byte string denotes a 1383 sequence of bytes that are not shown for brevity. 1385 { 1386 2501: { 1387 +2 : "2016-10-07T19:31:42Z", / SID=2503, created-on / 1388 +4 : "2016-10-21T19:31:42Z", / SID=2505, expires-on / 1389 +1 : 2, / SID=2502, assertion "proximity" / 1390 +13: "JADA123456789", / SID=2514, serial-number / 1391 +5 : h'08C2BF36....B3D2B3', / SID=2506, idevid-issuer / 1392 +10: h'30820275....82c35f', / SID=2511, proximity-registrar-cert/ 1393 +3 : true, / SID=2504, domain-cert 1394 -revocation-checks/ 1395 +6 : "2017-10-07T19:31:42Z" / SID=2507, last-renewal-date / 1396 } 1397 } 1398 1400 9.2. Voucher artifact 1402 The voucher's primary purpose is to securely assign a Pledge to an 1403 owner. The voucher informs the Pledge which entity it should 1404 consider to be its owner. 1406 9.2.1. Tree Diagram 1408 The following diagram is largely a duplicate of the contents of 1409 [RFC8366], with only the addition of the fields pinned-domain-pubk 1410 and pinned-domain-pubk-sha256. 1412 module: ietf-voucher-constrained 1414 grouping voucher-constrained-grouping 1415 +-- voucher 1416 +-- created-on? yang:date-and-time 1417 +-- expires-on? yang:date-and-time 1418 +-- assertion enumeration 1419 +-- serial-number string 1420 +-- idevid-issuer? binary 1421 +-- pinned-domain-cert? binary 1422 +-- domain-cert-revocation-checks? boolean 1423 +-- nonce? binary 1424 +-- last-renewal-date? yang:date-and-time 1425 +-- pinned-domain-pubk? binary 1426 +-- pinned-domain-pubk-sha256? binary 1427 1429 9.2.2. SID values 1430 SID Assigned to 1431 --------- -------------------------------------------------- 1432 2451 data /ietf-voucher-constrained:voucher 1433 2452 data /ietf-voucher-constrained:voucher/assertion 1434 2453 data /ietf-voucher-constrained:voucher/created-on 1435 2454 data .../domain-cert-revocation-checks 1436 2455 data /ietf-voucher-constrained:voucher/expires-on 1437 2456 data /ietf-voucher-constrained:voucher/idevid-issuer 1438 2457 data .../last-renewal-date 1439 2458 data /ietf-voucher-constrained:voucher/nonce 1440 2459 data .../pinned-domain-cert 1441 2460 data .../pinned-domain-pubk 1442 2461 data .../pinned-domain-pubk-sha256 1443 2462 data /ietf-voucher-constrained:voucher/serial-number 1445 WARNING, obsolete definitions 1446 1448 9.2.3. YANG Module 1450 In the constrained-voucher YANG module, the voucher is "augmented" 1451 within the "used" grouping statement such that one continuous set of 1452 SID values is generated for the constrained-voucher module name, all 1453 voucher attributes, and the constrained-voucher attributes. Two 1454 attributes of the voucher are "refined" to be optional. 1456 file "ietf-voucher-constrained@2021-04-15.yang" 1457 module ietf-voucher-constrained { 1458 yang-version 1.1; 1460 namespace 1461 "urn:ietf:params:xml:ns:yang:ietf-voucher-constrained"; 1462 prefix "constrained"; 1464 import ietf-restconf { 1465 prefix rc; 1466 description 1467 "This import statement is only present to access 1468 the yang-data extension defined in RFC 8040."; 1469 reference "RFC 8040: RESTCONF Protocol"; 1470 } 1472 import ietf-voucher { 1473 prefix "v"; 1474 } 1476 organization 1477 "IETF ANIMA Working Group"; 1479 contact 1480 "WG Web: 1481 WG List: 1482 Author: Michael Richardson 1483 1484 Author: Peter van der Stok 1485 1486 Author: Panos Kampanakis 1487 "; 1489 description 1490 "This module defines the format for a voucher, which 1491 is produced by a pledge's manufacturer or its delegate 1492 (MASA) to securely assign one or more pledges to an 'owner', 1493 so that a pledge may establish a secure connection to the 1494 owner's network infrastructure. 1496 This version provides a very restricted subset appropriate 1497 for very constrained devices. 1498 In particular, it assumes that nonce-ful operation is 1499 always required, that expiration dates are rather weak, as no 1500 clocks can be assumed, and that the Registrar is identified 1501 by either a pinned Raw Public Key of the Registrar, or by a 1502 pinned X.509 certificate of the Registrar or domain CA. 1504 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1505 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 1506 and 'OPTIONAL' in the module text are to be interpreted as 1507 described in RFC 2119."; 1509 revision "2021-04-15" { 1510 description 1511 "Initial version"; 1512 reference 1513 "RFC XXXX: Voucher Profile for Constrained Devices"; 1514 } 1516 rc:yang-data voucher-constrained-artifact { 1517 // YANG data template for a voucher. 1518 uses voucher-constrained-grouping; 1519 } 1521 // Grouping defined for future usage 1522 grouping voucher-constrained-grouping { 1523 description 1524 "Grouping to allow reuse/extensions in future work."; 1526 uses v:voucher-artifact-grouping { 1527 refine voucher/created-on { 1528 mandatory false; 1529 } 1531 refine voucher/pinned-domain-cert { 1532 mandatory false; 1533 } 1535 augment "voucher" { 1536 description "Base the constrained voucher 1537 upon the regular one"; 1538 leaf pinned-domain-pubk { 1539 type binary; 1540 description 1541 "The pinned-domain-pubk may replace the 1542 pinned-domain-cert in constrained uses of 1543 the voucher. The pinned-domain-pubk 1544 is the Raw Public Key of the Registrar. 1545 This field is encoded as a Subject Public Key Info block 1546 as specified in RFC7250, in section 3. 1547 The ECDSA algorithm MUST be supported. 1548 The EdDSA algorithm as specified in 1549 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 1550 Support for the DSA algorithm is not recommended. 1551 Support for the RSA algorithm is a MAY."; 1552 } 1554 leaf pinned-domain-pubk-sha256 { 1555 type binary; 1556 description 1557 "The pinned-domain-pubk-sha256 is a second 1558 alternative to pinned-domain-cert. In many cases the 1559 public key of the domain has already been transmitted 1560 during the key agreement process, and it is wasteful 1561 to transmit the public key another two times. 1562 The use of a hash of public key info, at 32-bytes for 1563 sha256 is a significant savings compared to an RSA 1564 public key, but is only a minor savings compared to 1565 a 256-bit ECDSA public-key. 1566 Algorithm agility is provided by extensions to this 1567 specification which can define a new leaf for another 1568 hash type."; 1569 } 1570 } 1571 } 1572 } 1573 } 1574 1576 9.2.4. Example voucher artifacts 1578 Below the CBOR serialization of an example constrained voucher is 1579 shown in CBOR diagnostic notation. The enum value of the assertion 1580 field is calculated to be zero by following the algorithm described 1581 in section 9.6.4.2 of [RFC7950]. 1583 { 1584 2451: { 1585 +2 : "2016-10-07T19:31:42Z", / SID = 2453, created-on / 1586 +4 : "2016-10-21T19:31:42Z", / SID = 2455, expires-on / 1587 +1 : 0, / SID = 2452, assertion "verified" / 1588 +11: "JADA123456789", / SID = 2462, serial-number / 1589 +5 : h'E40393B4....68A3', / SID = 2456, idevid-issuer / 1590 +8 : h'30820275....C35F', / SID = 2459, pinned-domain-cert/ 1591 +3 : true, / SID = 2454, domain-cert / 1592 / -revocation-checks / 1593 +6 : "2017-10-07T19:31:42Z" / SID = 2457, last-renewal-date / 1594 } 1595 } 1597 1599 9.3. Signing voucher and voucher-request artifacts with COSE 1601 The COSE_Sign1 structure is discussed in Section 4.2 of 1602 [I-D.ietf-cose-rfc8152bis-struct]. The CBOR object that carries the 1603 body, the signature, and the information about the body and signature 1604 is called the COSE_Sign1 structure. It is used when only one 1605 signature is used on the body. 1607 Support for ECDSA with SHA2-256 using curve secp256r1 (aka 1608 prime256k1) is RECOMMENDED. Most current low power hardware has 1609 support for acceleration of this algorithm. Future hardware designs 1610 could omit this in favour of a newer algorithms. This is the ES256 1611 keytype from Table 1 of [I-D.ietf-cose-rfc8152bis-algs]. Support for 1612 curve secp256k1 is OPTIONAL. 1614 Support for EdDSA using Curve 25519 is RECOMMENDED in new designs if 1615 hardware support is available. This is keytype EDDSA (-8) from 1616 Table 2 of [I-D.ietf-cose-rfc8152bis-algs]. A "crv" parameter is 1617 necessary to specify the Curve, which from Table 18. The 'kty' field 1618 MUST be present, and it MUST be 'OKP'. (Table 17) 1619 A transition towards EdDSA is occuring in the industry. Some 1620 hardware can accelerate only some algorithms with specific curves, 1621 other hardware can accelerate any curve, and still other kinds of 1622 hardware provide a tool kit for acceleration of any eliptic curve 1623 algorithm. 1625 In general, the Pledge is expected to support only a single 1626 algorithm, while the Registrar, usually not constrained, is expected 1627 to support a wide variety of algorithms: both legacy ones and up-and- 1628 coming ones via regular software updates. 1630 An example of the supported COSE_Sign1 object structure is shown in 1631 Figure 3. 1633 COSE_Sign1( 1634 [ 1635 h'A101382E', # protected header encoding: {1: -47} , which means { "alg": ES256K } 1636 { 1637 4 : h'7890A03F1234' # 4 is the "kid" binary key identifier 1638 }, 1639 h'1234....5678', #voucher-request binary content (CBOR) 1640 h'4567....1234' #voucher-request binary public signature 1641 ] 1642 ) 1644 Figure 3: COSE_Sign1 example in CBOR diagnostic notation 1646 The [COSE-registry] specifies the integers/encoding for the "alg" and 1647 "kid" fields in Figure 3. The "alg" field restricts the key usage 1648 for verification of this COSE object to a particular cryptographic 1649 algorithm. 1651 The "kid" field is optionally present: it is an unprotected field 1652 that identifies the public key of the key pair that was used to sign 1653 this message. The value of the key identifier "kid" parameter is an 1654 example value. Usually a hash of the public key is used to identify 1655 the public key, but a device serial number may also be used. The 1656 choice of key identifier method is vendor-specific. If "kid" is not 1657 present, then a verifying party needs to use other context 1658 information to retrieve the right public key to verify the COSE_Sign1 1659 object against. For example, this context information may be a 1660 unique serial number encoded in the binary content (CBOR) field. 1662 A Registrar MAY use a "kid" parameter in its RVR to identify its 1663 signing key as used to sign the RVR. The method of generating this 1664 "kid" is vendor-specific and SHOULD be configurable in the Registrar 1665 to support commonly used methods. In order to support future 1666 business cases and supply chain integrations, a Registrar MUST be 1667 configurable, on a per-manufacturer basis, to be able to configure 1668 the "kid" to a particular value. Both binary and string values are 1669 to be supported, each being inserted using a CBOR bstr or tstr. By 1670 default, a Registrar does not include a "kid" parameter in its RVR 1671 since the signing key is already identified by the included signing 1672 certificates in the COSE "x5bag" structure. 1674 A Pledge normally SHOULD NOT use a "kid" parameter in its PVR, 1675 because its signing key is already identified by the Pledge's unique 1676 serial number that is included in the PVR. Still, where needed the 1677 Pledge MAY use a "kid" parameter in its PVR to help the MASA identify 1678 the right public key to verify against. This can occur for example 1679 if a Pledge has multiple IDevID identities. A Registrar normally 1680 SHOULD ignore a "kid" parameter used in a received PVR, as this 1681 information is intended for the MASA. In other words, there is no 1682 need for the Registrar to verify the contents of this field, but it 1683 may include it in an audit log. 1685 In Appendix C a binary COSE_Sign1 object is shown based on the 1686 voucher-request example of Section 9.1.4. 1688 10. Deployment-specific Discovery Considerations 1690 This section details how discovery is done in specific deployment 1691 scenarios. 1693 10.1. 6TSCH Deployments 1695 In 6TISCH networks, the Constrained Join Proxy (CoJP) mechanism is 1696 described in [RFC9031]. Such networks are expected to use a 1697 [I-D.ietf-lake-edhoc] to do key management. This is the subject of 1698 future work. The Enhanced Beacon has been extended in [RFC9032] to 1699 allow for discovery of the Join Proxy. 1701 10.2. Generic networks using GRASP 1703 [RFC8995] defines a mechanism for the Pledge to discover a Join Proxy 1704 by listening for [RFC8990] GRASP messages. This mechanism can be 1705 used on any network which does not have another more specific 1706 mechanism. This mechanism supports mesh networks, and can also be 1707 used over unencrypted WIFI. 1709 10.3. Generic networks using mDNS 1711 [RFC8995] also defines a non-normative mechanism for the Pledge to 1712 discover a Join Proxy by doing mDNS queries. This mechanism can be 1713 used on any network which does not have another recommended 1714 mechanism. This mechanism does not easily support mesh networks. It 1715 can be used over unencrypted WIFI. 1717 10.4. Thread networks using Mesh Link Establishment (MLE) 1719 Thread [Thread] is a wireless mesh network protocol based on 6LoWPAN 1720 [RFC6282] and other IETF protocols. In Thread, a new device 1721 discovers potential Thread networks and Thread routers to join by 1722 using the Mesh Link Establishment (MLE) 1723 [I-D.ietf-6lo-mesh-link-establishment] protocol. MLE uses the UDP 1724 port number 19788. The new device sends discovery requests on 1725 different IEEE 802.15.4 radio channels, to which routers (if any 1726 present) respond with a discovery response containing information 1727 about their respective network. Once a suitable router is selected 1728 the new device initiates a DTLS transport-layer secured connection to 1729 the network's commissioning application, over a link-local single 1730 radio hop to the selected Thread router. This link is not yet 1731 secured at the radio level: link-layer security will be set up once 1732 the new device is approved by the commissioning application to join 1733 the Thread network, and it gets provisioned with network access 1734 credentials. 1736 The Thread router acts here as a Join Proxy. The MLE discovery 1737 response message contains UDP port information to signal the new 1738 device which port to use for its DTLS connection. 1740 10.5. Non-mesh networks using CoAP Discovery 1742 On unencrypted constrained networks such as 802.15.4, CoAP discover 1743 may be done using the mechanism detailed in [I-D.ietf-ace-coap-est] 1744 section 5.1. 1746 11. Design Considerations 1748 The design considerations for the CBOR encoding of vouchers are much 1749 the same as for JSON vouchers in [RFC8366]. One key difference is 1750 that the names of the leaves in the YANG definition do not affect the 1751 size of the resulting CBOR, as the SID translation process assigns 1752 integers to the names. 1754 Any POST request to the Registrar with resource /vs or /es returns a 1755 2.04 Changed response with empty payload. The client should be aware 1756 that the server may use a piggybacked CoAP response (ACK, 2.04) but 1757 may also respond with a separate CoAP response, i.e. first an (ACK, 1758 0.0) that is an acknowledgement of the request reception followed by 1759 a (CON, 2.04) response in a separate CoAP message. 1761 12. Raw Public Key Use Considerations 1763 This section explains techniques to reduce the number of bytes that 1764 are sent over the wire during the BRSKI bootstrap. The use of a raw 1765 public key (RPK) in the pinning process can significantly reduce the 1766 number of bytes and round trips, but it comes with a few significant 1767 operational limitations. 1769 12.1. The Registrar Trust Anchor 1771 When the Pledge first connects to the Registrar, the connection to 1772 the Registrar is provisional, as explained in Section 5.6.2 of 1773 [RFC8995]. The Registrar provides its public key in a 1774 TLSServerCertificate, and the Pledge uses that to validate that 1775 integrity of the (D)TLS connection, but it does not validate the 1776 identity of the provided certificate. 1778 As the TLSServerCertificate object is never verified directly by the 1779 pledge, sending it can be considered superfluous. Instead of using a 1780 (TLSServer)Certificate of type X509 (see section 4.4.2 of [RFC8446]), 1781 a RawPublicKey object is used. 1783 A Registrar operating in a mixed environment can determine whether to 1784 send a Certificate or a Raw Public key: this is determined by the 1785 pledge including the server_certificate_type of RawPublicKey. This 1786 is shown in section 5 of [RFC7250]. 1788 The Pledge continues to send a client_certificate_type of X509, so 1789 that the Registrar can properly identify the pledge and distill the 1790 MASA URI information from its certificate. 1792 12.2. The Pledge Voucher Request 1794 The Pledge puts the Registrar's public key into the proximity- 1795 registrar-pubk field of the voucher-request. (The proximity- 1796 registrar-pubk-sha256 can also be used if the 32-bytes of a SHA256 1797 hash turns out to be smaller than a typical ECDSA key.) 1799 As the format of the pubk field is identical to the TLS Certificate 1800 RawPublicKey, no manipulation at all is needed to insert this into a 1801 voucher-request. 1803 12.3. The Voucher Response 1805 A returned voucher will have a pinned-domain-subk field with the 1806 identical key as was found in the proximity-registrar-pubk field 1807 above, as well as in the TLS connection. 1809 Validation of this key by the pledge is what takes the DTLS 1810 connection out of the provisional state see Section 5.6.2 of 1811 [RFC8995]. 1813 The voucher needs to be validated first. The Pledge needs to have a 1814 public key to validate the signature from the MASA on the voucher. 1816 In certain cases, the MASA's public key counterpart of the (private) 1817 signing key is already installed in the Pledge at manufacturing time. 1818 In other cases, if the MASA signing key is based upon a PKI (see 1819 [I-D.richardson-anima-masa-considerations] Section 2.3), then a 1820 certificate chain may need to be included with the voucher in order 1821 for the pledge to validate the signature. In CMS signed artifacts, 1822 the CMS structure has a place for such certificates. 1824 In the COSE-signed Constrained Vouchers described in this document, 1825 the x5bag attribute from [I-D.ietf-cose-x509] is to be used for this. 1827 13. Use of constrained vouchers with HTTPS 1829 This specification contains two extensions to [RFC8995]: a 1830 constrained voucher format (COSE), and a constrained transfer 1831 protocol (CoAP). 1833 On constrained networks with constrained devices, it make senses to 1834 use both together. However, this document does not mandate that this 1835 be the only way. 1837 A given constrained device design and software may be re-used for 1838 multiple device models, such as a model having only an IEEE 802.15.4 1839 radio, or a model having only an IEEE 802.11 (Wi-Fi) radio, or a 1840 model having both these radios. A manufacturer of such device models 1841 may wish to have code only for the use of the constrained voucher 1842 format (COSE), and use it on all supported radios including the IEEE 1843 802.11 radio. For this radio, the software stack to support HTTP/TLS 1844 may be already integrated into the radio module hence it is 1845 attractive for the manufacturer to reuse this. This type of approach 1846 is supported by this document. In the case that HTTPS is used, the 1847 normal [RFC8995] resource names are used, together with the media 1848 types described in this document. 1850 Other combinations are possible, but they are not enumerated here. 1851 New work such as [I-D.ietf-anima-jws-voucher] provides new formats 1852 that may be useable over a number of different transports. In 1853 general, sending larger payloads over constrained networks makes less 1854 sense, while sending smaller payloads over unconstrained networks is 1855 perfectly acceptable. 1857 The Pledge will in most cases support a single voucher format, which 1858 it uses without negotiation i.e. without discovery of formats 1859 supported. The Registrar, being unconstrained, is expected to 1860 support all voucher formats. There will be cases where a Registrar 1861 does not support a new format that a new Pledge uses, and this is an 1862 unfortunate situation that will result in lack of interoperation. 1864 The responsability for supporting new formats is on the Registrar. 1866 14. Security Considerations 1868 14.1. Duplicate serial-numbers 1870 In the absense of correct use of idevid-issuer by the Registrar as 1871 detailed in Section 8.4, it would be possible for a malicious 1872 Registrar to use an unauthorized voucher for a device. This would 1873 apply only to the case where a Manufacturer Authorized Signing 1874 Authority (MASA) is trusted by different products from the same 1875 manufacturer, and the manufacturer has duplicated serial numbers as a 1876 result of a merge, acquisition or mis-management. 1878 For example, imagine the same manufacturer makes light bulbs as well 1879 as gas centrofuges, and said manufacturer does not uniquely allocate 1880 product serial numbers. This attack only works for nonceless 1881 vouchers. The attacker has obtained a light bulb which happens to 1882 have the same serial-number as a gas centrofuge which it wishes to 1883 obtain access. The attacker performs a normal BRSKI onboarding for 1884 the light bulb, but then uses the resulting voucher to onboard the 1885 gas centrofuge. The attack requires that the gas centrofuge be 1886 returned to a state where it is willing to perform a new onboarding 1887 operation. 1889 This attack is prevented by the mechanism of having the Registrar 1890 include the idevid-issuer in the RVR, and the MASA including it in 1891 the resulting voucher. The idevid-issuer is not included by default: 1892 a MASA needs to be aware if there are parts of the organization which 1893 duplicates serial numbers, and if so, include it. 1895 14.2. IDevID security in Pledge 1897 TBD. 1899 14.3. Security of CoAP and UDP protocols 1901 Section 7.1 explains that no CoAPS version of the BRSKI-MASA protocol 1902 is proposed. The connection from the Registrar to the MASA continues 1903 to be HTTPS as in [RFC8995]. This has been done to simplify the MASA 1904 deployment for the manufacturer, because no new protocol needs to be 1905 enabled on the server. 1907 The use of UDP protocols across the open Internet is sometimes 1908 fraught with security challenges. Denial-of-service attacks against 1909 UDP based protocols are trivial as there is no three-way handshake as 1910 done for TCP. The three-way handshake of TCP guarantees that the 1911 node sending the connection request is reachable using the origin IP 1912 address. While DTLS contains an option to do a stateless challenge 1913 -- a process actually stronger than that done by TCP -- it is not yet 1914 common for this mechanism to be available in hardware at multigigabit 1915 speeds. It is for this reason that this document defines using HTTPS 1916 for the Registrar to MASA connection. 1918 14.4. Registrar Certificate may be self-signed 1920 The provisional (D)TLS connection formed by the Pledge with the 1921 Registrar does not authenticate the Registrar's identity. This 1922 Registrar's identity is validated by the [RFC8366] voucher that is 1923 issued by the MASA, signed with an anchor that was built-in to the 1924 Pledge. 1926 The Registrar may therefore use any certificate, including a self- 1927 signed one. The only restrictions on the certificate is that it MUST 1928 have EKU bits set as detailed in Section 7.3.1. 1930 14.5. Use of RPK alternatives to proximity-registrar-cert 1932 In Section 9.1 two compact alternative fields for proximity- 1933 registrar-cert are defined that include an RPK: proximity-registrar- 1934 pubk and proximity-registrar-pubk-sha256. The Pledge can use these 1935 fields in its PVR to identify the Registrar based on its public key 1936 only. Since the full certificate of the proximate Registrar is not 1937 included, use of these fields by a Pledge implies that a Registrar 1938 could insert another certificate with the same public key identity 1939 into the RVR. For example, an older or a newer version of its 1940 certificate. The MASA will not be able to detect such act by the 1941 Registrar. But since any 'other' certificate the Registrar could 1942 insert in this way still encodes its identity the additional risk of 1943 using the RPK alternatives is neglible. 1945 When a Registrar sees a PVR that uses one of proximity-registrar-pubk 1946 or proximity-registrar-pubk-sha256 fields, this implies the Registrar 1947 must include the certificate identified by these fields into its RVR. 1948 Otherwise, the MASA is unable to verify proximity. This requirement 1949 is already implied by the "MUST" requirement in Section 8.1. 1951 14.6. MASA support of CoAPS 1953 The use of CoAP for the BRSKI-MASA connection is not in scope of the 1954 current document. The following security considerations have led to 1955 this choice of scope: 1957 * the technology and experience to build secure Internet-scale HTTPS 1958 responders (which the MASA is) is common, while the experience in 1959 doing the same for CoAP is much less common. 1961 * in many enterprise networks, outgoing UDP connections are often 1962 treated as suspicious, which could effectively block CoAP 1963 connections for some firewall configurations. 1965 * reducing the complexity of MASA (i.e. less protocols supported) 1966 would also reduce its potential attack surface, which is relevant 1967 since the MASA is 24/7 exposed on the Internet and accepting 1968 (untrusted) incoming connections. 1970 15. IANA Considerations 1972 15.1. Resource Type Registry 1974 Additions to the sub-registry "Resource Type Link Target Attribute 1975 Values", within the "CoRE parameters" IANA registry are specified 1976 below. 1978 brski needs registration with IANA 1979 brski.rv needs registration with IANA 1980 brski.vs needs registration with IANA 1981 brski.es needs registration with IANA 1983 15.2. The IETF XML Registry 1985 This document registers two URIs in the IETF XML registry [RFC3688]. 1986 Following the format in [RFC3688], the following registration is 1987 requested: 1989 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-constrained 1990 Registrant Contact: The ANIMA WG of the IETF. 1991 XML: N/A, the requested URI is an XML namespace. 1993 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request-constrained 1994 Registrant Contact: The ANIMA WG of the IETF. 1995 XML: N/A, the requested URI is an XML namespace. 1997 15.3. The YANG Module Names Registry 1999 This document registers two YANG modules in the YANG Module Names 2000 registry [RFC6020]. Following the format defined in [RFC6020], the 2001 the following registration is requested: 2003 name: ietf-voucher-constrained 2004 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-constrained 2005 prefix: vch 2006 reference: RFC XXXX 2008 name: ietf-voucher-request-constrained 2009 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher- 2010 request-constrained 2011 prefix: vch 2012 reference: RFC XXXX 2014 15.4. The RFC SID range assignment sub-registry 2016 ------------ ------ --------------------------- ------------ 2017 Entry-point | Size | Module name | RFC Number 2018 ------------ ------ --------------------------- ------------ 2019 2450 50 ietf-voucher-constrained [ThisRFC] 2020 2500 50 ietf-voucher-request [ThisRFC} 2021 -constrained 2022 ----------- ------ --------------------------- ------------ 2024 Warning: These SID values are defined in [I-D.ietf-core-sid], not as 2025 an Early Allocation. 2027 IANA: please update the names in the Registry to match these revised 2028 names, if they have not already been revised. 2030 15.5. Media Types Registry 2032 This section registers the 'application/voucher-cose+cbor' in the 2033 IANA "Media Types" registry. This media type is used to indicate 2034 that the content is a CBOR voucher or voucher request signed with a 2035 COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct]. 2037 15.5.1. application/voucher-cose+cbor 2039 Type name: application 2040 Subtype name: voucher-cose+cbor 2041 Required parameters: N/A 2042 Optional parameters: N/A 2043 Encoding considerations: binary (CBOR) 2044 Security considerations: Security Considerations of THIS RFC. 2045 Interoperability considerations: The format is designed to be 2046 broadly interoperable. 2047 Published specification: THIS RFC. 2048 Applications that use this media type: ANIMA, 6tisch, and other 2049 zero-touch onboarding systems 2050 Fragment identifier considerations: The syntax and semantics of 2051 fragment identifiers specified for application/voucher-cose+cbor 2052 are as specified for application/cbor. (At publication of this 2053 document, there is no fragment identification syntax defined for 2054 application/cbor.) 2055 Additional information: 2056 Deprecated alias names for this type: N/A 2057 Magic number(s): N/A 2058 File extension(s): .vch 2059 Macintosh file type code(s): N/A 2060 Person & email address to contact for further information: IETF 2061 ANIMA Working Group (anima@ietf.org) or IETF Operations and 2062 Management Area Working Group (opsawg@ietf.org) 2063 Intended usage: COMMON 2064 Restrictions on usage: N/A 2065 Author: ANIMA WG 2066 Change controller: IETF 2067 Provisional registration? (standards tree only): NO 2069 15.6. CoAP Content-Format Registry 2071 One addition to the sub-registry "CoAP Content-Formats", within the 2072 "CoRE Parameters" registry is needed for a new content-format. It 2073 can be registered in the Expert Review range (0-255) or the IETF 2074 Review range (256-9999). 2076 Media type Encoding ID Reference 2077 ----------------------------- --------- ---- ---------- 2078 application/voucher-cose+cbor - TBD3 [This RFC] 2080 16. Acknowledgements 2082 We are very grateful to Jim Schaad for explaining COSE and CMS 2083 choices. Also thanks to Jim Schaad for correcting earlier versions 2084 of the COSE_Sign1 objects. 2086 Michel Veillette did extensive work on _pyang_ to extend it to 2087 support the SID allocation process, and this document was among its 2088 first users. 2090 17. Changelog 2092 -10 Design considerations extended Examples made consistent 2094 -08 Examples for cose_sign1 are completed and improved. 2096 -06 New SID values assigned; regenerated examples 2098 -04 voucher and request-voucher MUST be signed examples for signed 2099 request are added in appendix IANA SID registration is updated SID 2100 values in examples are aligned signed cms examples aligned with new 2101 SIDs 2103 -03 2105 Examples are inverted. 2107 -02 2109 Example of requestvoucher with unsigned appllication/cbor is added 2110 attributes of voucher "refined" to optional 2111 CBOR serialization of vouchers improved 2112 Discovery port numbers are specified 2114 -01 2116 application/json is optional, application/cbor is compulsory 2117 Cms and cose mediatypes are introduced 2119 18. References 2121 18.1. Normative References 2123 [I-D.ietf-ace-coap-est] 2124 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 2125 Raza, "EST over secure CoAP (EST-coaps)", Work in 2126 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 2127 January 2020, . 2130 [I-D.ietf-core-sid] 2131 Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. 2132 Richardson, "YANG Schema Item iDentifier (YANG SID)", Work 2133 in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 2134 November 2021, . 2137 [I-D.ietf-core-yang-cbor] 2138 Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M. 2139 Richardson, "CBOR Encoding of Data Modeled with YANG", 2140 Work in Progress, Internet-Draft, draft-ietf-core-yang- 2141 cbor-17, 25 October 2021, 2142 . 2145 [I-D.ietf-cose-rfc8152bis-algs] 2146 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2147 Initial Algorithms", Work in Progress, Internet-Draft, 2148 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2149 . 2152 [I-D.ietf-cose-rfc8152bis-struct] 2153 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2154 Structures and Process", Work in Progress, Internet-Draft, 2155 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2156 . 2159 [I-D.ietf-cose-x509] 2160 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2161 Header parameters for carrying and referencing X.509 2162 certificates", Work in Progress, Internet-Draft, draft- 2163 ietf-cose-x509-08, 14 December 2020, 2164 . 2167 [I-D.ietf-tls-dtls13] 2168 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2169 Datagram Transport Layer Security (DTLS) Protocol Version 2170 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2171 dtls13-43, 30 April 2021, 2172 . 2175 [ieee802-1AR] 2176 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 2177 2009, . 2180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2181 Requirement Levels", BCP 14, RFC 2119, 2182 DOI 10.17487/RFC2119, March 1997, 2183 . 2185 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2186 DOI 10.17487/RFC3688, January 2004, 2187 . 2189 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2190 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2191 . 2193 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2194 "Internet X.509 Public Key Infrastructure Certificate 2195 Management Protocol (CMP)", RFC 4210, 2196 DOI 10.17487/RFC4210, September 2005, 2197 . 2199 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2200 Housley, R., and W. Polk, "Internet X.509 Public Key 2201 Infrastructure Certificate and Certificate Revocation List 2202 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2203 . 2205 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2206 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2207 . 2209 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2210 the Network Configuration Protocol (NETCONF)", RFC 6020, 2211 DOI 10.17487/RFC6020, October 2010, 2212 . 2214 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2215 Extensions: Extension Definitions", RFC 6066, 2216 DOI 10.17487/RFC6066, January 2011, 2217 . 2219 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2220 Verification of Domain-Based Application Service Identity 2221 within Internet Public Key Infrastructure Using X.509 2222 (PKIX) Certificates in the Context of Transport Layer 2223 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2224 2011, . 2226 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2227 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2228 Transport Layer Security (TLS) and Datagram Transport 2229 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2230 June 2014, . 2232 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2233 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2234 . 2236 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2237 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2238 May 2017, . 2240 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2241 "A Voucher Artifact for Bootstrapping Protocols", 2242 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2243 . 2245 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2246 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2247 . 2249 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2250 Definition Language (CDDL): A Notational Convention to 2251 Express Concise Binary Object Representation (CBOR) and 2252 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2253 June 2019, . 2255 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2256 Representation (CBOR)", STD 94, RFC 8949, 2257 DOI 10.17487/RFC8949, December 2020, 2258 . 2260 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2261 and K. Watsen, "Bootstrapping Remote Secure Key 2262 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2263 May 2021, . 2265 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 2266 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 2267 RFC 9031, DOI 10.17487/RFC9031, May 2021, 2268 . 2270 [RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of 2271 6TiSCH Join and Enrollment Information Elements", 2272 RFC 9032, DOI 10.17487/RFC9032, May 2021, 2273 . 2275 18.2. Informative References 2277 [COSE-registry] 2278 IANA, ., "CBOR Object Signing and Encryption (COSE) 2279 registry", 2017, 2280 . 2282 [I-D.ietf-6lo-mesh-link-establishment] 2283 Kelsey, R., "Mesh Link Establishment", Work in Progress, 2284 Internet-Draft, draft-ietf-6lo-mesh-link-establishment-00, 2285 1 December 2015, . 2288 [I-D.ietf-anima-constrained-join-proxy] 2289 Richardson, M., Stok, P. V. D., and P. Kampanakis, 2290 "Constrained Join Proxy for Bootstrapping Protocols", Work 2291 in Progress, Internet-Draft, draft-ietf-anima-constrained- 2292 join-proxy-06, 3 December 2021, 2293 . 2296 [I-D.ietf-anima-jws-voucher] 2297 Richardson, M. and T. Werner, "JWS signed Voucher 2298 Artifacts for Bootstrapping Protocols", Work in Progress, 2299 Internet-Draft, draft-ietf-anima-jws-voucher-01, 25 2300 October 2021, . 2303 [I-D.ietf-lake-edhoc] 2304 Selander, G., Mattsson, J. P., and F. Palombini, 2305 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 2306 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 2307 October 2021, . 2310 [I-D.kuehlewind-update-tag] 2311 Kuehlewind, M. and S. Krishnan, "Definition of new tags 2312 for relations between RFCs", Work in Progress, Internet- 2313 Draft, draft-kuehlewind-update-tag-04, 12 July 2021, 2314 . 2317 [I-D.richardson-anima-masa-considerations] 2318 Richardson, M. and W. Pan, "Operatonal Considerations for 2319 Voucher infrastructure for BRSKI MASA", Work in Progress, 2320 Internet-Draft, draft-richardson-anima-masa- 2321 considerations-06, 13 November 2021, 2322 . 2325 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2326 Control Message Protocol (ICMPv6) for the Internet 2327 Protocol Version 6 (IPv6) Specification", STD 89, 2328 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2329 . 2331 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2332 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2333 DOI 10.17487/RFC6282, September 2011, 2334 . 2336 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2337 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2338 . 2340 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2341 "Enrollment over Secure Transport", RFC 7030, 2342 DOI 10.17487/RFC7030, October 2013, 2343 . 2345 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2346 Constrained-Node Networks", RFC 7228, 2347 DOI 10.17487/RFC7228, May 2014, 2348 . 2350 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2351 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2352 . 2354 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 2355 Autonomic Signaling Protocol (GRASP)", RFC 8990, 2356 DOI 10.17487/RFC8990, May 2021, 2357 . 2359 [Thread] Thread Group, Inc, ., "Thread support page, White Papers", 2360 November 2021, 2361 . 2363 Appendix A. Library support for BRSKI 2365 For the implementation of BRSKI, the use of a software library to 2366 manipulate certificates and use crypto algorithms is often 2367 beneficial. Two C-based examples are OPENSSL and mbedtls. Others 2368 more targeted to specific platforms or languages exist. It is 2369 important to realize that the library interfaces differ significantly 2370 between libraries. 2372 Libraries do not support all known crypto algorithms. Before 2373 deciding on a library, it is important to look at their supported 2374 crypto algorithms and the roadmap for future support. Apart from 2375 availability, the library footprint, and the required execution 2376 cycles should be investigated beforehand. 2378 The handling of certificates usually includes the checking of a 2379 certificate chain. In some libraries, chains are constructed and 2380 verified on the basis of a set of certificates, the trust anchor 2381 (usually self signed root CA), and the target certificate. In other 2382 libraries, the chain must be constructed beforehand and obey order 2383 criteria. Verification always includes the checking of the 2384 signatures. Less frequent is the checking the validity of the dates 2385 or checking the existence of a revoked certificate in the chain 2386 against a set of revoked certificates. Checking the chain on the 2387 consistency of the certificate extensions which specify the use of 2388 the certificate usually needs to be programmed explicitly. 2390 A libary can be used to construct a (D)TLS connection. It is useful 2391 to realize that differences beetween (D)TLS implementations will 2392 occur due to the differences in the certicate checks supported by the 2393 library. On top of that, checks between client and server 2394 certificates enforced by (D)TLS are not always helpful for a BRSKI 2395 implementation. For example, the certificates of Pledge and 2396 Registrar are usually not related when the BRSKI protocol is started. 2397 It must be verified that checks on the relation between client and 2398 server certificates do not hamper a succeful DTLS connection 2399 establishment. 2401 A.1. OpensSSL 2403 from openssl's apps/verify.c 2404 X509 *x = NULL; 2405 int i = 0, ret = 0; 2406 X509_STORE_CTX *csc; 2407 STACK_OF(X509) *chain = NULL; 2408 int num_untrusted; 2410 x = load_cert(file, "certificate file"); 2411 if (x == NULL) 2412 goto end; 2414 csc = X509_STORE_CTX_new(); 2415 if (csc == NULL) { 2416 BIO_printf(bio_err, "error %s: X.509 store context" 2417 "allocation failed\n", 2418 (file == NULL) ? "stdin" : file); 2419 goto end; 2420 } 2422 X509_STORE_set_flags(ctx, vflags); 2423 if (!X509_STORE_CTX_init(csc, ctx, x, uchain)) { 2424 X509_STORE_CTX_free(csc); 2425 BIO_printf(bio_err, 2426 "error %s: X.509 store context" 2427 "initialization failed\n", 2428 (file == NULL) ? "stdin" : file); 2429 goto end; 2430 } 2431 if (tchain != NULL) 2432 X509_STORE_CTX_set0_trusted_stack(csc, tchain); 2433 if (crls != NULL) 2434 X509_STORE_CTX_set0_crls(csc, crls); 2436 i = X509_verify_cert(csc); 2437 X509_STORE_CTX_free(csc); 2438 2440 A.2. mbedTLS 2442 mbedtls_x509_crt cert; 2443 mbedtls_x509_crt caCert; 2444 uint32_t certVerifyResultFlags; 2445 ... 2446 int result = mbedtls_x509_crt_verify(&cert, &caCert, NULL, NULL, 2447 &certVerifyResultFlags, NULL, NULL); 2449 Appendix B. Constrained BRSKI-EST messages 2451 This section extends the examples from Appendix A of 2452 [I-D.ietf-ace-coap-est] with the constrained BRSKI requests. The 2453 CoAP headers are only worked out for the enrollstatus example. 2455 B.1. enrollstatus 2457 A coaps enrollstatus message can be : 2459 POST coaps://192.0.2.1:8085/b/es 2461 The corresponding CoAP header fields are shown below. 2463 Ver = 1 2464 T = 0 (CON) 2465 Code = 0x02 (0.02 is POST) 2466 Options 2467 Option (Uri-Path) 2468 Option Delta = 0xb (option nr = 11) 2469 Option Length = 0x1 2470 Option Value = "b" 2471 Option (Uri-Path) 2472 Option Delta = 0x0 (option nr = 11) 2473 Option Length = 0x2 2474 Option Value = "es" 2475 Option (Content-Format) 2476 Option Delta = 0x1 (option nr = 12) 2477 Option Length = 0x1 2478 Option Value = 60 (application/cbor) 2479 Payload Marker = 0xFF 2480 Payload = 2482 The Uri-Host and Uri-Port Options are omitted because they coincide 2483 with the transport protocol destination address and port 2484 respectively. TBD - Show the binary CBOR payload of this example. 2486 A 2.04 Changed response from the Registrar will then be: 2488 2.04 Changed 2490 With CoAP fields: 2492 Ver=1 2493 T=2 (ACK) 2494 Code = 0x44 (2.04 Changed) 2496 B.2. voucher_status 2498 A coaps voucher_status message can be: 2500 POST coaps://[2001:db8::2:1]:61616/b/vs 2501 Content-Format: 60 (application/cbor) 2502 Payload = 2503 a46776657273696f6e0166737461747573f466726561736f6e7828496e66 2504 6f726d61746976652068756d616e2d7265616461626c65206572726f7220 2505 6d6573736167656e726561736f6e2d636f6e74657874a100764164646974 2506 696f6e616c20696e666f726d6174696f6e 2507 2509 The request payload above is binary CBOR but represented here in 2510 hexadecimal for readability. Below is the equivalent CBOR diagnostic 2511 format. 2513 {"version": 1, "status": false, 2514 "reason": "Informative human-readable error message", 2515 "reason-context": { 0: "Additional information" } } 2517 2519 A 2.04 Changed response without payload will then be sent by the 2520 Registrar back to the Pledge. 2522 2.04 Changed 2524 Appendix C. COSE examples 2526 These examples are generated on a Pi 4 and a PC running BASH. Keys 2527 and Certificates have been generated with openssl with the following 2528 shell script: 2530 #!/bin/bash 2531 #try-cert.sh 2532 export dir=./brski/intermediate 2533 export cadir=./brski 2534 export cnfdir=./conf 2535 export format=pem 2536 export default_crl_days=30 2537 sn=8 2539 DevID=pledge.1.2.3.4 2540 serialNumber="serialNumber=$DevID" 2541 export hwType=1.3.6.1.4.1.6715.10.1 2542 export hwSerialNum=01020304 # Some hex 2543 export subjectAltName="otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname" 2544 echo $hwType - $hwSerialNum 2545 echo $serialNumber 2546 OPENSSL_BIN="openssl" 2548 # remove all files 2549 rm -r ./brski/* 2550 # 2551 # initialize file structure 2552 # root level 2553 cd $cadir 2554 mkdir certs crl csr newcerts private 2555 chmod 700 private 2556 touch index.txt 2557 touch serial 2558 echo 11223344556600 >serial 2559 echo 1000 > crlnumber 2560 # intermediate level 2561 mkdir intermediate 2562 cd intermediate 2563 mkdir certs crl csr newcerts private 2564 chmod 700 private 2565 touch index.txt 2566 echo 11223344556600 >serial 2567 echo 1000 > crlnumber 2568 cd ../.. 2570 # file structure is cleaned start filling 2572 echo "#############################" 2573 echo "create registrar keys and certificates " 2574 echo "#############################" 2576 echo "create root registrar certificate using ecdsa with sha 256 key" 2577 $OPENSSL_BIN ecparam -name prime256v1 -genkey \ 2578 -noout -out $cadir/private/ca-regis.key 2580 $OPENSSL_BIN req -new -x509 \ 2581 -config $cnfdir/openssl-regis.cnf \ 2582 -key $cadir/private/ca-regis.key \ 2583 -out $cadir/certs/ca-regis.crt \ 2584 -extensions v3_ca\ 2585 -days 365 \ 2586 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \ 2587 /CN=registrar.stok.nl" 2588 # Combine authority certificate and key 2589 echo "Combine authority certificate and key" 2590 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2591 -inkey $cadir/private/ca-regis.key \ 2592 -in $cadir/certs/ca-regis.crt -export \ 2593 -out $cadir/certs/ca-regis-comb.pfx 2595 # converteer authority pkcs12 file to pem 2596 echo "converteer authority pkcs12 file to pem" 2597 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2598 -in $cadir/certs/ca-regis-comb.pfx \ 2599 -out $cadir/certs/ca-regis-comb.crt -nodes 2601 #show certificate in registrar combined certificate 2602 $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text 2604 # 2605 # Certificate Authority for MASA 2606 # 2607 echo "#############################" 2608 echo "create MASA keys and certificates " 2609 echo "#############################" 2611 echo "create root MASA certificate using ecdsa with sha 256 key" 2612 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 2613 -out $cadir/private/ca-masa.key 2615 $OPENSSL_BIN req -new -x509 \ 2616 -config $cnfdir/openssl-masa.cnf \ 2617 -days 1000 -key $cadir/private/ca-masa.key \ 2618 -out $cadir/certs/ca-masa.crt \ 2619 -extensions v3_ca\ 2620 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\ 2621 /CN=masa.stok.nl" 2623 # Combine authority certificate and key 2624 echo "Combine authority certificate and key for masa" 2625 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2626 -inkey $cadir/private/ca-masa.key \ 2627 -in $cadir/certs/ca-masa.crt -export \ 2628 -out $cadir/certs/ca-masa-comb.pfx 2630 # converteer authority pkcs12 file to pem for masa 2631 echo "converteer authority pkcs12 file to pem for masa" 2632 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2633 -in $cadir/certs/ca-masa-comb.pfx \ 2634 -out $cadir/certs/ca-masa-comb.crt -nodes 2636 #show certificate in pledge combined certificate 2637 $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text 2639 # 2640 # Certificate for Pledge derived from MASA certificate 2641 # 2642 echo "#############################" 2643 echo "create pledge keys and certificates " 2644 echo "#############################" 2646 # Pledge derived Certificate 2648 echo "create pledge derived certificate using ecdsa with sha 256 key" 2649 $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ 2650 -out $dir/private/pledge.key 2652 echo "create pledge certificate request" 2653 $OPENSSL_BIN req -nodes -new -sha256 \ 2654 -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ 2655 -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ 2656 /CN=uuid:$DevID/$serialNumber" 2658 # Sign pledge derived Certificate 2659 echo "sign pledge derived certificate " 2660 $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \ 2661 -extensions 8021ar_idevid\ 2662 -days 365 -in $dir/csr/pledge.csr \ 2663 -out $dir/certs/pledge.crt 2665 # Add pledge key and pledge certificate to pkcs12 file 2666 echo "Add derived pledge key and derived pledge \ 2667 certificate to pkcs12 file" 2668 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2669 -inkey $dir/private/pledge.key \ 2670 -in $dir/certs/pledge.crt -export \ 2671 -out $dir/certs/pledge-comb.pfx 2673 # converteer pledge pkcs12 file to pem 2674 echo "converteer pledge pkcs12 file to pem" 2675 $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ 2676 -in $dir/certs/pledge-comb.pfx \ 2677 -out $dir/certs/pledge-comb.crt -nodes 2679 #show certificate in pledge-comb.crt 2680 $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text 2681 #show private key in pledge-comb.crt 2682 $OPENSSL_BIN ecparam -name prime256v1\ 2683 -in $dir/certs/pledge-comb.crt -text 2684 2686 The xxxx-comb certificates have been generated as required by libcoap 2687 for the DTLS connection generation. 2689 C.1. Pledge, Registrar and MASA keys 2691 This first section documents the public and private keys used in the 2692 subsequent test vectors below. These keys come from test code and 2693 are not used in any production system, and should only be used only 2694 to validate implementations. 2696 C.1.1. Pledge private key 2698 Private-Key: (256 bit) 2699 priv: 2700 9b:4d:43:b6:a9:e1:7c:04:93:45:c3:13:d9:b5:f0: 2701 41:a9:6a:9c:45:79:73:b8:62:f1:77:03:3a:fc:c2: 2702 9c:9a 2703 pub: 2704 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 2705 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 2706 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 2707 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 2708 60:eb:95:5c:54 2709 ASN1 OID: prime256v1 2710 NIST CURVE: P-256 2711 2713 C.1.2. Registrar private key 2715 Private-Key: (256 bit) 2716 priv: 2717 81:df:bb:50:a3:45:58:06:b5:56:3b:46:de:f3:e9: 2718 e9:00:ae:98:13:9e:2f:36:68:81:fc:d9:65:24:fb: 2719 21:7e 2720 pub: 2721 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2722 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2723 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2724 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2725 3e:d0:2d:c7:b7 2726 ASN1 OID: prime256v1 2727 NIST CURVE: P-256 2728 2730 C.1.3. MASA private key 2732 Private-Key: (256 bit) 2733 priv: 2734 c6:bb:a5:8f:b6:d3:c4:75:28:d8:d3:d9:46:c3:31: 2735 83:6d:00:0a:9a:38:ce:22:5c:e9:d9:ea:3b:98:32: 2736 ec:31 2737 pub: 2738 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2739 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2740 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2741 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2742 ed:f3:17:5c:f1 2743 ASN1 OID: prime256v1 2744 NIST CURVE: P-256 2745 2747 C.2. Pledge, Registrar and MASA certificates 2749 Below the certificates that accompany the keys. The certificate 2750 description is followed by the hexadecimal DER of the certificate 2752 C.2.1. Pledge IDevID certificate 2753 Certificate: 2754 Data: 2755 Version: 3 (0x2) 2756 Serial Number: 4822678189204992 (0x11223344556600) 2757 Signature Algorithm: ecdsa-with-SHA256 2758 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturer, 2759 CN=masa.stok.nl 2760 Validity 2761 Not Before: Dec 9 10:02:36 2020 GMT 2762 Not After : Dec 31 23:59:59 9999 GMT 2763 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=manufacturing, 2764 CN=uuid:pledge.1.2.3.4/serialNumber=pledge.1.2.3.4 2765 Subject Public Key Info: 2766 Public Key Algorithm: id-ecPublicKey 2767 Public-Key: (256 bit) 2768 pub: 2769 04:d6:b7:6f:74:88:bd:80:ae:5f:28:41:2c:72:02: 2770 ef:5f:98:b4:81:e1:d9:10:4c:f8:1b:66:d4:3e:5c: 2771 ea:da:73:e6:a8:38:a9:f1:35:11:85:b6:cd:e2:04: 2772 10:be:fe:d5:0b:3b:14:69:2e:e1:b0:6a:bc:55:40: 2773 60:eb:95:5c:54 2774 ASN1 OID: prime256v1 2775 NIST CURVE: P-256 2776 X509v3 extensions: 2777 X509v3 Basic Constraints: 2778 CA:FALSE 2779 X509v3 Authority Key Identifier: 2780 keyid: 2781 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2783 Signature Algorithm: ecdsa-with-SHA256 2784 30:46:02:21:00:d2:e6:45:3b:b0:c3:00:b3:25:8d:f1:83:fe: 2785 d9:37:c1:a2:49:65:69:7f:6b:b9:ef:2c:05:07:06:31:ac:17: 2786 bd:02:21:00:e2:ce:9e:7b:7f:74:50:33:ad:9e:ff:12:4e:e9: 2787 a6:f3:b8:36:65:ab:7d:80:bb:56:88:bc:03:1d:e5:1e:31:6f 2789 2791 This is the hexadecimal representation in (request-)voucher examples 2792 referred to as pledge-cert-hex. 2794 30820226308201cba003020102020711223344556600300a06082a8648ce3d04 2795 0302306f310b3009060355040613024e4c310b300906035504080c024e423110 2796 300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e6465 2797 7273746f6b31153013060355040b0c0c6d616e75666163747572657231153013 2798 06035504030c0c6d6173612e73746f6b2e6e6c3020170d323031323039313030 2799 3233365a180f39393939313233313233353935395a308190310b300906035504 2800 0613024e4c310b300906035504080c024e423110300e06035504070c0748656c 2801 6d6f6e6431133011060355040a0c0a76616e64657273746f6b31163014060355 2802 040b0c0d6d616e75666163747572696e67311c301a06035504030c1375756964 2803 3a706c656467652e312e322e332e34311730150603550405130e706c65646765 2804 2e312e322e332e343059301306072a8648ce3d020106082a8648ce3d03010703 2805 420004d6b76f7488bd80ae5f28412c7202ef5f98b481e1d9104cf81b66d43e5c 2806 eada73e6a838a9f1351185b6cde20410befed50b3b14692ee1b06abc554060eb 2807 955c54a32e302c30090603551d1304023000301f0603551d23041830168014e4 2808 0393b4c3d3f42a80a47718f6964903011768a3300a06082a8648ce3d04030203 2809 49003046022100d2e6453bb0c300b3258df183fed937c1a24965697f6bb9ef2c 2810 05070631ac17bd022100e2ce9e7b7f745033ad9eff124ee9a6f3b83665ab7d80 2811 bb5688bc031de51e316f 2813 C.2.2. Registrar Certificate 2814 Certificate: 2815 Data: 2816 Version: 3 (0x2) 2817 Serial Number: 2818 70:56:ea:aa:30:66:d8:82:6a:55:5b:90:88:d4:62:bf:9c:f2:8c:fd 2819 Signature Algorithm: ecdsa-with-SHA256 2820 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 2821 CN=registrar.stok.nl 2822 Validity 2823 Not Before: Dec 9 10:02:36 2020 GMT 2824 Not After : Dec 9 10:02:36 2021 GMT 2825 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, OU=consultancy, 2826 CN=registrar.stok.nl 2827 Subject Public Key Info: 2828 Public Key Algorithm: id-ecPublicKey 2829 Public-Key: (256 bit) 2830 pub: 2831 04:50:7a:c8:49:1a:8c:69:c7:b5:c3:1d:03:09:ed: 2832 35:ba:13:f5:88:4c:e6:2b:88:cf:30:18:15:4f:a0: 2833 59:b0:20:ec:6b:eb:b9:4e:02:b8:93:40:21:89:8d: 2834 a7:89:c7:11:ce:a7:13:39:f5:0e:34:8e:df:0d:92: 2835 3e:d0:2d:c7:b7 2836 ASN1 OID: prime256v1 2837 NIST CURVE: P-256 2838 X509v3 extensions: 2839 X509v3 Subject Key Identifier: 2840 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2841 X509v3 Authority Key Identifier: 2842 keyid: 2843 08:C2:BF:36:88:7F:79:41:21:85:87:2F:16:A7:AC:A6:EF:B3:D2:B3 2845 X509v3 Basic Constraints: critical 2846 CA:TRUE 2847 X509v3 Extended Key Usage: 2848 CMC Registration Authority, TLS Web Server 2849 Authentication, TLS Web Client Authentication 2850 X509v3 Key Usage: critical 2851 Digital Signature, Non Repudiation, Key Encipherment, 2852 Data Encipherment, Certificate Sign, CRL Sign 2853 Signature Algorithm: ecdsa-with-SHA256 2854 30:44:02:20:74:4c:99:00:85:13:b2:f1:bc:fd:f9:02:1a:46: 2855 fb:17:4c:f8:83:a2:7c:a1:d9:3f:ae:ac:f3:1e:4e:dd:12:c6: 2856 02:20:11:47:14:db:f5:1a:5e:78:f5:81:b9:42:1c:6e:47:02: 2857 ab:53:72:70:c5:ba:fb:2d:16:c3:de:9a:a1:82:c3:5f 2859 2860 This the hexadecimal representation, in (request-)voucher examples 2861 referred to as regis-cert-hex 2863 308202753082021ca00302010202147056eaaa3066d8826a555b9088d462bf9c 2864 f28cfd300a06082a8648ce3d0403023073310b3009060355040613024e4c310b 2865 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2866 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f6e 2867 73756c74616e6379311a301806035504030c117265676973747261722e73746f 2868 6b2e6e6c301e170d3230313230393130303233365a170d323131323039313030 2869 3233365a3073310b3009060355040613024e4c310b300906035504080c024e42 2870 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e 2871 64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379311a30 2872 1806035504030c117265676973747261722e73746f6b2e6e6c3059301306072a 2873 8648ce3d020106082a8648ce3d03010703420004507ac8491a8c69c7b5c31d03 2874 09ed35ba13f5884ce62b88cf3018154fa059b020ec6bebb94e02b8934021898d 2875 a789c711cea71339f50e348edf0d923ed02dc7b7a3818d30818a301d0603551d 2876 0e0416041408c2bf36887f79412185872f16a7aca6efb3d2b3301f0603551d23 2877 04183016801408c2bf36887f79412185872f16a7aca6efb3d2b3300f0603551d 2878 130101ff040530030101ff30270603551d250420301e06082b0601050507031c 2879 06082b0601050507030106082b06010505070302300e0603551d0f0101ff0404 2880 030201f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 2881 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf51a5e 2882 78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f 2884 C.2.3. MASA Certificate 2886 Certificate: 2887 Data: 2888 Version: 3 (0x2) 2889 Serial Number: 2890 14:26:b8:1c:ce:d8:c3:e8:14:05:cb:87:67:0d:be:ef:d5:81:25:b4 2891 Signature Algorithm: ecdsa-with-SHA256 2892 Issuer: C=NL, ST=NB, L=Helmond, O=vanderstok, 2893 OU=manufacturer, CN=masa.stok.nl 2895 Validity 2896 Not Before: Dec 9 10:02:36 2020 GMT 2897 Not After : Sep 5 10:02:36 2023 GMT 2898 Subject: C=NL, ST=NB, L=Helmond, O=vanderstok, 2899 OU=manufacturer, CN=masa.stok.nl 2900 Subject Public Key Info: 2901 Public Key Algorithm: id-ecPublicKey 2902 Public-Key: (256 bit) 2903 pub: 2904 04:59:80:94:66:14:94:20:30:3c:66:08:85:55:86: 2905 db:e7:d4:d1:d7:7a:d2:a3:1a:0c:73:6b:01:0d:02: 2906 12:15:d6:1f:f3:6e:c8:d4:84:60:43:3b:21:c5:83: 2907 80:1e:fc:e2:37:85:77:97:94:d4:aa:34:b5:b6:c6: 2909 ed:f3:17:5c:f1 2910 ASN1 OID: prime256v1 2911 NIST CURVE: P-256 2912 X509v3 extensions: 2913 X509v3 Subject Key Identifier: 2914 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2915 X509v3 Authority Key Identifier: 2916 keyid: 2917 E4:03:93:B4:C3:D3:F4:2A:80:A4:77:18:F6:96:49:03:01:17:68:A3 2919 X509v3 Basic Constraints: critical 2920 CA:TRUE 2921 X509v3 Extended Key Usage: 2922 CMC Registration Authority, 2923 TLS Web Server Authentication, 2924 TLS Web Client Authentication 2925 X509v3 Key Usage: critical 2926 Digital Signature, Non Repudiation, Key Encipherment, 2927 Data Encipherment, Certificate Sign, CRL Sign 2928 Signature Algorithm: ecdsa-with-SHA256 2929 30:44:02:20:2e:c5:f2:24:72:70:20:ea:6e:74:8b:13:93:67: 2930 8a:e6:fe:fb:8d:56:7f:f5:34:18:a9:ef:a5:0f:c3:99:ca:53: 2931 02:20:3d:dc:91:d0:e9:6a:69:20:01:fb:e4:20:40:de:7c:7d: 2932 98:ed:d8:84:53:61:84:a7:f9:13:06:4c:a9:b2:8f:5c 2934 2936 This is the hexadecimal representation, in (request-)voucher examples 2937 referred to as masa-cert-hex. 2939 3082026d30820214a00302010202141426b81cced8c3e81405cb87670dbeefd5 2940 8125b4300a06082a8648ce3d040302306f310b3009060355040613024e4c310b 2941 300906035504080c024e423110300e06035504070c0748656c6d6f6e64311330 2942 11060355040a0c0a76616e64657273746f6b31153013060355040b0c0c6d616e 2943 7566616374757265723115301306035504030c0c6d6173612e73746f6b2e6e6c 2944 301e170d3230313230393130303233365a170d3233303930353130303233365a 2945 306f310b3009060355040613024e4c310b300906035504080c024e423110300e 2946 06035504070c0748656c6d6f6e6431133011060355040a0c0a76616e64657273 2947 746f6b31153013060355040b0c0c6d616e756661637475726572311530130603 2948 5504030c0c6d6173612e73746f6b2e6e6c3059301306072a8648ce3d02010608 2949 2a8648ce3d0301070342000459809466149420303c6608855586dbe7d4d1d77a 2950 d2a31a0c736b010d021215d61ff36ec8d48460433b21c583801efce237857797 2951 94d4aa34b5b6c6edf3175cf1a3818d30818a301d0603551d0e04160414e40393 2952 b4c3d3f42a80a47718f6964903011768a3301f0603551d23041830168014e403 2953 93b4c3d3f42a80a47718f6964903011768a3300f0603551d130101ff04053003 2954 0101ff30270603551d250420301e06082b0601050507031c06082b0601050507 2955 030106082b06010505070302300e0603551d0f0101ff0404030201f6300a0608 2956 2a8648ce3d040302034700304402202ec5f224727020ea6e748b1393678ae6fe 2957 fb8d567ff53418a9efa50fc399ca5302203ddc91d0e96a692001fbe42040de7c 2958 7d98edd884536184a7f913064ca9b28f5c 2960 C.3. COSE signed voucher request from Pledge to Registrar 2962 In this example the voucher request has been signed by the Pledge, 2963 and has been sent to the JRC over CoAPS. The Pledge uses the 2964 proximity assertion together with an included proximity-registrar- 2965 cert field to inform MASA about its proximity to the specific 2966 Registrar. 2968 POST coaps://registrar.example.com/b/rv 2969 (Content-Format: application/voucher-cose+cbor) 2970 signed_request_voucher 2972 The payload signed_request_voucher is shown as hexadecimal dump (with 2973 lf added): 2975 d28444a101382ea104582097113db094eee8eae48683e7337875c0372164 2976 be89d023a5f3df52699c0fbfb55902d2a11909c5a60274323032302d3132 2977 2d32335431323a30353a32325a0474323032322d31322d32335431323a30 2978 353a32325a01020750684ca83e27230aff97630cf2c1ec409a0d6e706c65 2979 6467652e312e322e332e340a590279308202753082021ca0030201020214 2980 7056eaaa3066d8826a555b9088d462bf9cf28cfd300a06082a8648ce3d04 2981 03023073310b3009060355040613024e4c310b300906035504080c024e42 2982 3110300e06035504070c0748656c6d6f6e6431133011060355040a0c0a76 2983 616e64657273746f6b31143012060355040b0c0b636f6e73756c74616e63 2984 79311a301806035504030c117265676973747261722e73746f6b2e6e6c30 2985 1e170d3230313230393130303233365a170d323131323039313030323336 2986 5a3073310b3009060355040613024e4c310b300906035504080c024e4231 2987 10300e06035504070c0748656c6d6f6e6431133011060355040a0c0a7661 2988 6e64657273746f6b31143012060355040b0c0b636f6e73756c74616e6379 2989 311a301806035504030c117265676973747261722e73746f6b2e6e6c3059 2990 301306072a8648ce3d020106082a8648ce3d03010703420004507ac8491a 2991 8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018154fa059b020ec6beb 2992 b94e02b8934021898da789c711cea71339f50e348edf0d923ed02dc7b7a3 2993 818d30818a301d0603551d0e0416041408c2bf36887f79412185872f16a7 2994 aca6efb3d2b3301f0603551d2304183016801408c2bf36887f7941218587 2995 2f16a7aca6efb3d2b3300f0603551d130101ff040530030101ff30270603 2996 551d250420301e06082b0601050507031c06082b0601050507030106082b 2997 06010505070302300e0603551d0f0101ff0404030201f6300a06082a8648 2998 ce3d04030203470030440220744c99008513b2f1bcfdf9021a46fb174cf8 2999 83a27ca1d93faeacf31e4edd12c60220114714dbf51a5e78f581b9421c6e 3000 4702ab537270c5bafb2d16c3de9aa182c35f58473045022063766c7bbd1b 3001 339dbc398e764af3563e93b25a69104befe9aac2b3336b8f56e1022100cd 3002 0419559ad960ccaed4dee3f436eca40b7570b25a52eb60332bc1f2991484 3003 e9 3004 3006 The representiation of signed_voucher_request in CBOR diagnostic 3007 format is: 3009 Diagnose(signed_request_voucher) = 3010 18([ 3011 h'A101382E', // {"alg": -47} 3012 {4: h'97113DB094EEE8EAE48683E7337875C0372164B 3013 E89D023A5F3DF52699C0FBFB5'}, 3014 h'1234', // request_voucher 3015 h'3045022063766C7BBD1B339DBC398E764AF3563E93B 3016 25A69104BEFE9AAC2B3336B8F56E1022100CD0419559A 3017 D960CCAED4DEE3F436ECA40B7570B25A52EB60332BC1F 3018 2991484E9' 3019 ]) 3021 Diagnose(request_voucher) = 3022 {2501: {2: "2020-12-23T12:05:22Z", 3023 4: "2022-12-23T12:05:22Z", 3024 1: 2, 3025 7: h'684CA83E27230AFF97630CF2C1EC409A', 3026 13: "pledge.1.2.3.4", 3027 10: h'1234' // regis-cert-hex 3028 }} 3029 3031 C.4. COSE signed voucher request from Registrar to MASA 3033 TBD - modify example to use full paths to MASA, not short-names. 3034 Also not use CoAP but HTTP protocol. 3036 In this example the voucher request has been signed by the JRC using 3037 the private key from Appendix C.1.2. Contained within this voucher 3038 request is the voucher request from the Pledge to JRC. 3040 POST coaps://masa.example.com/b/rv 3041 (Content-Format: application/voucher-cose+cbor) 3042 signed_masa_request_voucher 3044 The payload signed_masa_voucher_request is shown as hexadecimal dump 3045 (with lf added): 3047 d28444a101382ea1045820e8735bc4b470c3aa6a7aa9aa8ee584c09c1113 3048 1b205efec5d0313bad84c5cd05590414a11909c5a60274323032302d3132 3049 2d32385431303a30333a33355a0474323032322d31322d32385431303a30 3050 333a33355a07501551631f6e0416bd162ba53ea00c2a050d6e706c656467 3051 652e312e322e332e3405587131322d32385431303a30333a33355a075015 3052 51631f6e0416bd162ba53ea00c2a050d6e706c656467652e312e322e332e 3053 3405587131322d32385431303a300000000000000000000000000416bd16 3054 2ba53ea00c2a050d6e706c656467652e312e322e332e3405587131322d32 3055 385431303a09590349d28444a101382ea104582097113db094eee8eae486 3056 83e7337875c0372164be89d023a5f3df52699c0fbfb55902d2a11909c5a6 3057 0274323032302d31322d32385431303a30333a33355a0474323032322d31 3058 322d32385431303a30333a33355a010207501551631f6e0416bd162ba53e 3059 a00c2a050d6e706c656467652e312e322e332e340a590279308202753082 3060 021ca00302010202147056eaaa3066d8826a555b9088d462bf9cf28cfd30 3061 0a06082a8648ce3d0403023073310b3009060355040613024e4c310b3009 3062 06035504080c024e423110300e06035504070c0748656c6d6f6e64311330 3063 11060355040a0c0a76616e64657273746f6b31143012060355040b0c0b63 3064 6f6e73756c74616e6379311a301806035504030c11726567697374726172 3065 2e73746f6b2e6e6c301e170d3230313230393130303233365a170d323131 3066 3230393130303233365a3073310b3009060355040613024e4c310b300906 3067 035504080c024e423110300e06035504070c0748656c6d6f6e6431133011 3068 060355040a0c0a76616e64657273746f6b31143012060355040b0c0b636f 3069 6e73756c74616e6379311a301806035504030c117265676973747261722e 3070 73746f6b2e6e6c3059301306072a8648ce3d020106082a8648ce3d030107 3071 03420004507ac8491a8c69c7b5c31d0309ed35ba13f5884ce62b88cf3018 3072 154fa059b020ec6bebb94e02b8934021898da789c711cea71339f50e348e 3073 df0d923ed02dc7b7a3818d30818a301d0603551d0e0416041408c2bf3688 3074 7f79412185872f16a7aca6efb3d2b3301f0603551d2304183016801408c2 3075 bf36887f79412185872f16a7aca6efb3d2b3300f0603551d130101ff0405 3076 30030101ff30270603551d250420301e06082b0601050507031c06082b06 3077 01050507030106082b06010505070302300e0603551d0f0101ff04040302 3078 01f6300a06082a8648ce3d04030203470030440220744c99008513b2f1bc 3079 fdf9021a46fb174cf883a27ca1d93faeacf31e4edd12c60220114714dbf5 3080 1a5e78f581b9421c6e4702ab537270c5bafb2d16c3de9aa182c35f584730 3081 45022063766c7bbd1b339dbc398e764af3563e93b25a69104befe9aac2b3 3082 336b8f56e1022100cd0419559ad960ccaed4dee3f436eca40b7570b25a52 3083 eb60332bc1f2991484e958473045022100e6b45558c1b806bba23f4ac626 3084 c9bdb6fd354ef4330d8dfb7c529f29cca934c802203c1f2ccbbac89733d1 3085 7ee7775bc2654c5f1cc96afba2741cc31532444aa8fed8 3087 3089 The representiation of signed_masa_voucher_request in CBOR diagnostic 3090 format is: 3092 Diagnose(signed_registrar_request-voucher) 3093 18([ 3094 h'A101382E', // {"alg": -47} 3095 h'E8735BC4B470C3AA6A7AA9AA8EE584C09C11131B205EFEC5D0313BAD84 3096 C5CD05'}, 3097 h'1234', // registrar_request_voucher', 3098 h'3045022100E6B45558C1B806BBA23F4AC626C9BDB6FD354EF4330D8DFB 3099 7C529F29CCA934C802203C1F2CCBBAC89733D17EE7775BC2654C5F1CC96A 3100 FBA2741CC31532444AA8FED8' 3101 ]) 3103 Diagnose(registrar_request_voucher) 3104 {2501: 3105 {2: "2020-12-28T10:03:35Z", 3106 4: "2022-12-28T10:03:35Z", 3107 7: h'1551631F6E0416BD162BA53EA00C2A05', 3108 13: "pledge.1.2.3.4", 3109 5: h'31322D32385431303A30333A33355A07501551631F6E0416BD 3110 162BA53EA00C2A050D6E706C656467652E312E322E332E3405 3111 587131322D32385431303A3000000000000000000000000004 3112 16BD162BA53EA00C2A050D6E706C656467652E312E322E332E 3113 3405587131322D32385431303A', 3114 9: h'1234' // signature 3115 }} 3116 3118 C.5. COSE signed voucher from MASA to Pledge via Registrar 3120 The resulting voucher is created by the MASA and returned via the JRC 3121 to the Pledge. It is signed by the MASA's private key Appendix C.1.3 3122 and can be verified by the Pledge using the MASA's public key 3123 contained within the MASA certificate. 3125 This is the raw binary signed_voucher, encoded in hexadecimal (with 3126 lf added): 3128 d28444a101382ea104582039920a34ee92d3148ab3a729f58611193270c9 3129 029f7784daf112614b19445d5158cfa1190993a70274323032302d31322d 3130 32335431353a30333a31325a0474323032302d31322d32335431353a3233 3131 3a31325a010007506508e06b2959d5089d7a3169ea889a490b6e706c6564 3132 67652e312e322e332e340858753073310b3009060355040613024e4c310b 3133 300906035504080c024e423110300e06035504070c0748656c6d6f6e6431 3134 133011060355040a0c0a76616e64657273746f6b31143012060355040b0c 3135 0b636f6e73756c74616e6379311a301806035504030c1172656769737472 3136 61722e73746f6b2e6e6c03f458473045022022515d96cd12224ee5d3ac67 3137 3237163bba24ad84815699285d9618f463ee73fa022100a6bff9d8585c1c 3138 9256371ece94da3d26264a5dfec0a354fe7b3aef58344c512f 3140 3142 The representiation of signed_voucher in CBOR diagnostic format is: 3144 Diagnose(signed_voucher) = 3145 18([ 3146 h'A101382E', # {"alg": -47} 3147 {4: h'39920A34EE92D3148AB3A729F58611193270C9029F7784DAF112614B194 3148 45D51'}, 3149 h'voucher', 3150 h'3045022022515D96CD12224EE5D3AC673237163BBA24AD84815699285D9618F 3151 463EE73FA022100A6BFF9D8585C1C9256371ECE94DA3D26264A5DFEC0A354FE7B 3152 3AEF58344C512F' 3153 ]) 3155 Diagnose(voucher) = 3156 {2451: 3157 {2: "2020-12-23T15:03:12Z", 3158 4: "2020-12-23T15:23:12Z", 3159 1: 0, 3160 7: h'6508E06B2959D5089D7A3169EA889A49', 3161 11: "pledge.1.2.3.4", 3162 8: h'regis-cert-hex', 3163 3: false}} 3164 3166 Appendix D. Pledge Device Class Profiles 3168 This specification allows implementers to select between various 3169 functional options for the Pledge, yielding different code size 3170 footprints and different requirements on Pledge hardware. Thus for 3171 each product an optimal trade-off between functionality, development/ 3172 maintenance cost and hardware cost can be made. 3174 This appendix illustrates different selection outcomes by means of 3175 defining different example "profiles" of constrained Pledges. In the 3176 following subsections, these profiles are defined and a comparison is 3177 provided. 3179 D.1. Minimal Pledge 3181 The Minimal Pledge profile (Min) aims to reduce code size and 3182 hardware cost to a minimum. This comes with some severe functional 3183 restrictions, in particular: 3185 * No support for EST re-enrollment: whenever this would be needed, a 3186 factory reset followed by a new bootstrap process is required. 3188 * No support for change of Registrar: for this case, a factory reset 3189 followed by a new bootstrap process is required. 3191 This profile would be appropriate for single-use devices which must 3192 be replaced rather than re-deployed. That might include medical 3193 devices, but also sensors used during construction, such as concrete 3194 temperature sensors. 3196 D.2. Typical Pledge 3198 The Typical Pledge profile (Typ) aims to support a typical 3199 Constrained BRSKI feature set including EST re-enrollment support and 3200 Registrar changes. 3202 D.3. Full-featured Pledge 3204 The Full-featured Pledge profile (Full) illustrates a Pledge category 3205 that supports multiple bootstrap methods, hardware real-time clock, 3206 BRSKI/EST resource discovery, and CSR Attributes request/response. 3207 It also supports most of the optional features defined in this 3208 specification. 3210 D.4. Comparison chart of Pledge Classes 3212 The below table specifies the functions implemented in the three 3213 example Pledge classes Min, Typ and Full. 3215 +=============================================+=====+=====+======+ 3216 | Function |====================| Profiles -> | Min | Typ | Full | 3217 +=============================================+=====+=====+======+ 3218 | *General* | === | === | ==== | 3219 +---------------------------------------------+-----+-----+------+ 3220 | Support Constrained BRSKI bootstrap | Y | Y | Y | 3221 +---------------------------------------------+-----+-----+------+ 3222 | Support other bootstrap method(s) | - | - | Y | 3223 +---------------------------------------------+-----+-----+------+ 3224 | Real-time clock and cert time checks | - | - | Y | 3225 +---------------------------------------------+-----+-----+------+ 3226 | *Constrained BRSKI* | === | === | ==== | 3227 +---------------------------------------------+-----+-----+------+ 3228 | Discovery for rt=brski* | - | - | Y | 3229 +---------------------------------------------+-----+-----+------+ 3230 | Support pinned Registrar public key (RPK) | Y | - | Y | 3231 +---------------------------------------------+-----+-----+------+ 3232 | Support pinned Registrar certificate | - | Y | Y | 3233 +---------------------------------------------+-----+-----+------+ 3234 | Support pinned Domain CA | - | Y | Y | 3235 +---------------------------------------------+-----+-----+------+ 3236 | *Constrained EST* | === | === | ==== | 3237 +---------------------------------------------+-----+-----+------+ 3238 | Discovery for rt=ace.est* | - | - | Y | 3239 +---------------------------------------------+-----+-----+------+ 3240 | GET /att and response parsing | - | - | Y | 3241 +---------------------------------------------+-----+-----+------+ 3242 | GET /crts format 281 (multiple CA certs) | - | - | Y | 3243 +---------------------------------------------+-----+-----+------+ 3244 | GET /crts only format TBD287 (one CA cert | Y | Y | - | 3245 | only) | | | | 3246 +---------------------------------------------+-----+-----+------+ 3247 | ETag handling support for GET /crts | - | Y | Y | 3248 +---------------------------------------------+-----+-----+------+ 3249 | Re-enrollment supported | - | Y | Y | 3250 | | (1) | | | 3251 +---------------------------------------------+-----+-----+------+ 3252 | 6.6.1 optimized procedure | Y | Y | - | 3253 +---------------------------------------------+-----+-----+------+ 3254 | Pro-active cert re-enrollment at own | N/A | - | Y | 3255 | initiative | | | | 3256 +---------------------------------------------+-----+-----+------+ 3257 | Periodic trust anchor retrieval GET /crts | - | Y | Y | 3258 | | (1) | | | 3259 +---------------------------------------------+-----+-----+------+ 3260 | Supports change of Registrar identity | - | Y | Y | 3261 | | (1) | | | 3262 +---------------------------------------------+-----+-----+------+ 3264 Table 2 3266 Notes: (1) is possible only by doing a factory-reset followed by a 3267 new bootstrap procedure. 3269 Contributors 3271 Russ Housley 3273 Email: housley@vigilsec.com 3275 Authors' Addresses 3277 Michael Richardson 3278 Sandelman Software Works 3280 Email: mcr+ietf@sandelman.ca 3282 Peter van der Stok 3283 vanderstok consultancy 3285 Email: stokcons@bbhmail.nl 3287 Panos Kampanakis 3288 Cisco Systems 3290 Email: pkampana@cisco.com 3292 Esko Dijk 3293 IoTconsultancy.nl 3295 Email: esko.dijk@iotconsultancy.nl