idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-38.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 200 instances of too long lines in the document, the longest one being 29 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 March 2020) is 1506 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GRASP' is mentioned on line 1605, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1891, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC2131' is mentioned on line 4550, but not defined == Missing Reference: 'HEX DUMP' is mentioned on line 5598, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-22 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'REST' ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 8368 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-07 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-15 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-02 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Richardson 5 Expires: 12 September 2020 Sandelman 6 T.T.E. Eckert 7 Futurewei USA 8 M.H. Behringer 10 K.W. Watsen 11 Watsen Networks 12 11 March 2020 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-38 17 Abstract 19 This document specifies automated bootstrapping of an Autonomic 20 Control Plane. To do this a Secure Key Infrastructure is 21 bootstrapped. This is done using manufacturer-installed X.509 22 certificates, in combination with a manufacturer's authorizing 23 service, both online and offline. We call this process the 24 Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. 25 Bootstrapping a new device can occur using a routable address and a 26 cloud service, or using only link-local connectivity, or on limited/ 27 disconnected networks. Support for deployment models with less 28 stringent security requirements is included. Bootstrapping is 29 complete when the cryptographic identity of the new key 30 infrastructure is successfully deployed to the device. The 31 established secure connection can be used to deploy a locally issued 32 certificate to the device as well. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 12 September 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 69 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 11 70 1.3.1. Support environment . . . . . . . . . . . . . . . . . 11 71 1.3.2. Constrained environments . . . . . . . . . . . . . . 11 72 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 73 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 74 1.4. Leveraging the new key infrastructure / next steps . . . 12 75 1.5. Requirements for Autonomic Network Infrastructure (ANI) 76 devices . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 78 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 79 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 80 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 81 2.3.1. Identification of the Pledge . . . . . . . . . . . . 18 82 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18 83 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20 84 2.5. Architectural Components . . . . . . . . . . . . . . . . 23 85 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 86 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 87 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 88 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 89 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24 90 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 91 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 92 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 93 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25 94 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 95 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 96 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27 97 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 98 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 99 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29 100 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 32 101 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33 102 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35 103 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36 104 4.3. Proxy discovery and communication of Registrar . . . . . 36 105 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38 106 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39 107 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40 108 5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 42 109 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43 110 5.4.1. MASA authentication of customer Registrar . . . . . . 43 111 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44 112 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46 113 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 46 114 5.5.3. MASA checking of voucher request signature . . . . . 46 115 5.5.4. MASA verification of domain registrar . . . . . . . . 47 116 5.5.5. MASA verification of pledge 117 prior-signed-voucher-request . . . . . . . . . . . . 48 118 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 48 119 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 48 120 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 51 121 5.6.2. Pledge authentication of provisional TLS 122 connection . . . . . . . . . . . . . . . . . . . . . 52 123 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 53 124 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54 125 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55 126 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58 127 5.8.3. Registrar audit log verification . . . . . . . . . . 58 128 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60 129 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60 130 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60 131 5.9.3. EST Client Certificate Request . . . . . . . . . . . 61 132 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61 133 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 63 134 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63 135 6. Clarification of transfer-encoding . . . . . . . . . . . . . 63 136 7. Reduced security operational modes . . . . . . . . . . . . . 63 137 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64 138 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 139 7.3. Registrar security reductions . . . . . . . . . . . . . . 65 140 7.4. MASA security reductions . . . . . . . . . . . . . . . . 66 141 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67 142 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67 143 7.4.3. Updating or extending voucher trust anchors . . . . . 68 145 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 146 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 147 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 69 148 8.3. Well-known EST registration . . . . . . . . . . . . . . . 69 149 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 70 150 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70 151 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 152 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 71 153 9.1. Operational Requirements . . . . . . . . . . . . . . . . 72 154 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72 155 9.1.2. Domain Owner Operational Requirements . . . . . . . . 73 156 9.1.3. Device Operational Requirements . . . . . . . . . . . 74 157 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74 158 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 74 159 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 75 160 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 76 161 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 78 162 10.5. Manufacturers and Grey market equipment . . . . . . . . 79 163 10.6. Some mitigations for meddling by manufacturers . . . . . 80 164 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 81 165 11. Security Considerations . . . . . . . . . . . . . . . . . . . 81 166 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 82 167 11.2. DomainID must be resistant to second-preimage attacks . 83 168 11.3. Availability of good random numbers . . . . . . . . . . 83 169 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 83 170 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84 171 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85 172 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 87 173 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87 174 11.6.3. Compromise of MASA web service . . . . . . . . . . . 89 175 11.7. YANG Module Security Considerations . . . . . . . . . . 90 176 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 177 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 178 13.1. Normative References . . . . . . . . . . . . . . . . . . 90 179 13.2. Informative References . . . . . . . . . . . . . . . . . 94 180 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 98 181 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 98 182 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 98 183 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 98 184 Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 99 185 C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 99 186 C.1.1. Manufacturer Certificate Authority for IDevID 187 signatures . . . . . . . . . . . . . . . . . . . . . 100 188 C.1.2. MASA key pair for voucher signatures . . . . . . . . 101 189 C.1.3. Registrar Certificate Authority . . . . . . . . . . . 103 190 C.1.4. Registrar key pair . . . . . . . . . . . . . . . . . 104 191 C.1.5. Pledge key pair . . . . . . . . . . . . . . . . . . . 106 192 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 107 193 C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 107 194 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 111 195 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 117 196 Appendix D. Additional References . . . . . . . . . . . . . . . 121 197 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 121 199 1. Introduction 201 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 202 provides a solution for secure zero-touch (automated) bootstrap of 203 new (unconfigured) devices that are called pledges in this document. 204 Pledges have an IDevID installed in them at the factory. 206 "BRSKI" is pronounced like "brewski", a colloquial term for beer in 207 Canada and parts of the US-midwest. [brewski] 209 This document primarily provides for the needs of the ISP and 210 Enterprise focused ANIMA Autonomic Control Plane (ACP) 211 [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process 212 satisfies the [RFC7575] requirements of section 3.3 of making all 213 operations secure by default. Other users of the BRSKI protocol will 214 need to provide separate applicability statements that include 215 privacy and security considerations appropriate to that deployment. 216 Section 9 explains the detailed applicability for this the ACP usage. 218 The BRSKI protocol requires a significant amount of communication 219 between manufacturer and owner: in its default modes it provides a 220 cryptographic transfer of control to the initial owner. In its 221 strongest modes, it leverages sales channel information to identify 222 the owner in advance. Resale of devices is possible, provided that 223 the manufacturer is willing to authorize the transfer. Mechanisms to 224 enable transfers of ownership without manufacturer authorization are 225 not included in this version of the protocol, but could be designed 226 into future versions. 228 This document describes how pledges discover (or are discovered by) 229 an element of the network domain to which the pledge belongs that 230 will perform the bootstrap. This element (device) is called the 231 registrar. Before any other operation, pledge and registrar need to 232 establish mutual trust: 234 1. Registrar authenticating the pledge: "Who is this device? What 235 is its identity?" 237 2. Registrar authorizing the pledge: "Is it mine? Do I want it? 238 What are the chances it has been compromised?" 240 3. Pledge authenticating the registrar: "What is this registrar's 241 identity?" 243 4. Pledge authorizing the registrar: "Should I join this network?" 245 This document details protocols and messages to answer the above 246 questions. It uses a TLS connection and an PKIX-shaped (X.509v3) 247 certificate (an IEEE 802.1AR [IDevID] IDevID) of the pledge to answer 248 points 1 and 2. It uses a new artifact called a "voucher" that the 249 registrar receives from a "Manufacturer Authorized Signing Authority" 250 (MASA) and passes to the pledge to answer points 3 and 4. 252 A proxy provides very limited connectivity between the pledge and the 253 registrar. 255 The syntactic details of vouchers are described in detail in 256 [RFC8366]. This document details automated protocol mechanisms to 257 obtain vouchers, including the definition of a 'voucher-request' 258 message that is a minor extension to the voucher format (see 259 Section 3) defined by [RFC8366]. 261 BRSKI results in the pledge storing an X.509 root certificate 262 sufficient for verifying the registrar identity. In the process a 263 TLS connection is established that can be directly used for 264 Enrollment over Secure Transport (EST). In effect BRSKI provides an 265 automated mechanism for the "Bootstrap Distribution of CA 266 Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge 267 "MUST [...] engage a human user to authorize the CA certificate using 268 out-of-band" information. With BRSKI the pledge now can automate 269 this process using the voucher. Integration with a complete EST 270 enrollment is optional but trivial. 272 BRSKI is agile enough to support bootstrapping alternative key 273 infrastructures, such as a symmetric key solutions, but no such 274 system is described in this document. 276 1.1. Prior Bootstrapping Approaches 278 To literally "pull yourself up by the bootstraps" is an impossible 279 action. Similarly the secure establishment of a key infrastructure 280 without external help is also an impossibility. Today it is commonly 281 accepted that the initial connections between nodes are insecure, 282 until key distribution is complete, or that domain-specific keying 283 material (often pre-shared keys, including mechanisms like SIM cards) 284 is pre-provisioned on each new device in a costly and non-scalable 285 manner. Existing automated mechanisms are known as non-secured 286 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 287 [Stajano99theresurrecting] or 'pre-staging'. 289 Another prior approach has been to try and minimize user actions 290 during bootstrapping, but not eliminate all user-actions. The 291 original EST protocol [RFC7030] does reduce user actions during 292 bootstrap but does not provide solutions for how the following 293 protocol steps can be made autonomic (not involving user actions): 295 * using the Implicit Trust Anchor [RFC7030] database to authenticate 296 an owner specific service (not an autonomic solution because the 297 URL must be securely distributed), 299 * engaging a human user to authorize the CA certificate using out- 300 of-band data (not an autonomic solution because the human user is 301 involved), 303 * using a configured Explicit TA database (not an autonomic solution 304 because the distribution of an explicit TA database is not 305 autonomic), 307 * and using a Certificate-Less TLS mutual authentication method (not 308 an autonomic solution because the distribution of symmetric key 309 material is not autonomic). 311 These "touch" methods do not meet the requirements for zero-touch. 313 There are "call home" technologies where the pledge first establishes 314 a connection to a well known manufacturer service using a common 315 client-server authentication model. After mutual authentication, 316 appropriate credentials to authenticate the target domain are 317 transferred to the pledge. This creates several problems and 318 limitations: 320 * the pledge requires realtime connectivity to the manufacturer 321 service, 323 * the domain identity is exposed to the manufacturer service (this 324 is a privacy concern), 326 * the manufacturer is responsible for making the authorization 327 decisions (this is a liability concern), 329 BRSKI addresses these issues by defining extensions to the EST 330 protocol for the automated distribution of vouchers. 332 1.2. Terminology 334 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 335 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 336 "OPTIONAL" in this document are to be interpreted as described in BCP 337 14 [RFC2119] [RFC8174] when, and only when, they appear in all 338 capitals, as shown here. 340 The following terms are defined for clarity: 342 ANI: The Autonomic Network Infrastructure as defined by 343 [I-D.ietf-anima-reference-model]. Section 9 details specific 344 requirements for pledges, proxies and registrars when they are 345 part of an ANI. 347 Circuit Proxy: A stateful implementation of the join proxy. This is 348 the assumed type of proxy. 350 drop-ship: The physical distribution of equipment containing the 351 "factory default" configuration to a final destination. In zero- 352 touch scenarios there is no staging or pre-configuration during 353 drop-ship. 355 Domain: The set of entities that share a common local trust anchor. 356 This includes the proxy, registrar, Domain Certificate Authority, 357 Management components and any existing entity that is already a 358 member of the domain. 360 domainID: The domain IDentity is a unique value based upon the 361 Registrar CA's certificate. Section 5.8.2 specifies how it is 362 calculated. 364 Domain CA: The domain Certification Authority (CA) provides 365 certification functionalities to the domain. At a minimum it 366 provides certification functionalities to a registrar and manages 367 the private key that defines the domain. Optionally, it certifies 368 all elements. 370 enrollment: The process where a device presents key material to a 371 network and acquires a network-specific identity. For example 372 when a certificate signing request is presented to a certification 373 authority and a certificate is obtained in response. 375 imprint: The process where a device obtains the cryptographic key 376 material to identify and trust future interactions with a network. 377 This term is taken from Konrad Lorenz's work in biology with new 378 ducklings: during a critical period, the duckling would assume 379 that anything that looks like a mother duck is in fact their 380 mother. An equivalent for a device is to obtain the fingerprint 381 of the network's root certification authority certificate. A 382 device that imprints on an attacker suffers a similar fate to a 383 duckling that imprints on a hungry wolf. Securely imprinting is a 384 primary focus of this document [imprinting]. The analogy to 385 Lorenz's work was first noted in [Stajano99theresurrecting]. 387 IDevID: An Initial Device Identity X.509 certificate installed by 388 the vendor on new equipment. This is a term from 802.1AR [IDevID] 390 IPIP Proxy: A stateless proxy alternative. 392 Join Proxy: A domain entity that helps the pledge join the domain. 393 A join proxy facilitates communication for devices that find 394 themselves in an environment where they are not provided 395 connectivity until after they are validated as members of the 396 domain. For simplicity this document sometimes uses the term of 397 'proxy' to indicate the join proxy. The pledge is unaware that 398 they are communicating with a proxy rather than directly with a 399 registrar. 401 Join Registrar (and Coordinator): A representative of the domain 402 that is configured, perhaps autonomically, to decide whether a new 403 device is allowed to join the domain. The administrator of the 404 domain interfaces with a "join registrar (and coordinator)" to 405 control this process. Typically a join registrar is "inside" its 406 domain. For simplicity this document often refers to this as just 407 "registrar". Within [I-D.ietf-anima-reference-model] this is 408 referred to as the "join registrar autonomic service agent". 409 Other communities use the abbreviation "JRC". 411 LDevID: A Local Device Identity X.509 certificate installed by the 412 owner of the equipment. This is a term from 802.1AR [IDevID] 414 manufacturer: the term manufacturer is used throughout this document 415 to be the entity that created the device. This is typically the 416 "original equipment manufacturer" or OEM, but in more complex 417 situations it could be a "value added retailer" (VAR), or possibly 418 even a systems integrator. In general, it a goal of BRSKI to 419 eliminate small distinctions between different sales channels. 420 The reason for this is that it permits a single device, with a 421 uniform firmware load, to be shipped directly to all customers. 422 This eliminates costs for the manufacturer. This also reduces the 423 number of products supported in the field increasing the chance 424 that firmware will be more up to date. 426 MASA Audit-Log: An anonymized list of previous owners maintained by 427 the MASA on a per device (per pledge) basis. Described in 428 Section 5.8.1. 430 MASA Service: A third-party Manufacturer Authorized Signing 431 Authority (MASA) service on the global Internet. The MASA signs 432 vouchers. It also provides a repository for audit-log information 433 of privacy protected bootstrapping events. It does not track 434 ownership. 436 nonced: a voucher (or request) that contains a nonce (the normal 437 case). 439 nonceless: a voucher (or request) that does not contain a nonce, 440 relying upon accurate clocks for expiration, or which does not 441 expire. 443 offline: When an architectural component cannot perform realtime 444 communications with a peer, either due to network connectivity or 445 because the peer is turned off, the operation is said to be 446 occurring offline. 448 Ownership Tracker: An Ownership Tracker service on the global 449 Internet. The Ownership Tracker uses business processes to 450 accurately track ownership of all devices shipped against domains 451 that have purchased them. Although optional, this component 452 allows vendors to provide additional value in cases where their 453 sales and distribution channels allow for accurate tracking of 454 such ownership. Ownership tracking information is indicated in 455 vouchers as described in [RFC8366] 457 Pledge: The prospective (unconfigured) device, which has an identity 458 installed at the factory. 460 (Public) Key Infrastructure: The collection of systems and processes 461 that sustain the activities of a public key system. The registrar 462 acts as an [RFC5280] and [RFC5272] (see section 7) "Registration 463 Authority". 465 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 466 where a pledge device makes no security decisions but rather 467 simply trusts the first registrar it is contacted by. This is 468 also known as the "resurrecting duckling" model. 470 Voucher: A signed artifact from the MASA that indicates to a pledge 471 the cryptographic identity of the registrar it should trust. 472 There are different types of vouchers depending on how that trust 473 is asserted. Multiple voucher types are defined in [RFC8366] 475 1.3. Scope of solution 477 1.3.1. Support environment 479 This solution (BRSKI) can support large router platforms with multi- 480 gigabit inter-connections, mounted in controlled access data centers. 481 But this solution is not exclusive to large equipment: it is intended 482 to scale to thousands of devices located in hostile environments, 483 such as ISP provided CPE devices which are drop-shipped to the end 484 user. The situation where an order is fulfilled from distributed 485 warehouse from a common stock and shipped directly to the target 486 location at the request of a domain owner is explicitly supported. 487 That stock ("SKU") could be provided to a number of potential domain 488 owners, and the eventual domain owner will not know a-priori which 489 device will go to which location. 491 The bootstrapping process can take minutes to complete depending on 492 the network infrastructure and device processing speed. The network 493 communication itself is not optimized for speed; for privacy reasons, 494 the discovery process allows for the pledge to avoid announcing its 495 presence through broadcasting. 497 Nomadic or mobile devices often need to acquire credentials to access 498 the network at the new location. An example of this is mobile phone 499 roaming among network operators, or even between cell towers. This 500 is usually called handoff. BRSKI does not provide a low-latency 501 handoff which is usually a requirement in such situations. For these 502 solutions BRSKI can be used to create a relationship (an LDevID) with 503 the "home" domain owner. The resulting credentials are then used to 504 provide credentials more appropriate for a low-latency handoff. 506 1.3.2. Constrained environments 508 Questions have been posed as to whether this solution is suitable in 509 general for Internet of Things (IoT) networks. This depends on the 510 capabilities of the devices in question. The terminology of 511 [RFC7228] is best used to describe the boundaries. 513 The solution described in this document is aimed in general at non- 514 constrained (i.e., class 2+ [RFC7228]) devices operating on a non- 515 Challenged network. The entire solution as described here is not 516 intended to be useable as-is by constrained devices operating on 517 challenged networks (such as 802.15.4 Low-power Lossy Networks 518 (LLN)s). 520 Specifically, there are protocol aspects described here that might 521 result in congestion collapse or energy-exhaustion of intermediate 522 battery powered routers in an LLN. Those types of networks should 523 not use this solution. These limitations are predominately related 524 to the large credential and key sizes required for device 525 authentication. Defining symmetric key techniques that meet the 526 operational requirements is out-of-scope but the underlying protocol 527 operations (TLS handshake and signing structures) have sufficient 528 algorithm agility to support such techniques when defined. 530 The imprint protocol described here could, however, be used by non- 531 energy constrained devices joining a non-constrained network (for 532 instance, smart light bulbs are usually mains powered, and speak 533 802.11). It could also be used by non-constrained devices across a 534 non-energy constrained, but challenged network (such as 802.15.4). 535 The certificate contents, and the process by which the four questions 536 above are resolved do apply to constrained devices. It is simply the 537 actual on-the-wire imprint protocol that could be inappropriate. 539 1.3.3. Network Access Controls 541 This document presumes that network access control has either already 542 occurred, is not required, or is integrated by the proxy and 543 registrar in such a way that the device itself does not need to be 544 aware of the details. Although the use of an X.509 Initial Device 545 Identity is consistent with IEEE 802.1AR [IDevID], and allows for 546 alignment with 802.1X network access control methods, its use here is 547 for pledge authentication rather than network access control. 548 Integrating this protocol with network access control, perhaps as an 549 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 550 out-of-scope. 552 1.3.4. Bootstrapping is not Booting 554 This document describes "bootstrapping" as the protocol used to 555 obtain a local trust anchor. It is expected that this trust anchor, 556 along with any additional configuration information subsequently 557 installed, is persisted on the device across system restarts 558 ("booting"). Bootstrapping occurs only infrequently such as when a 559 device is transferred to a new owner or has been reset to factory 560 default settings. 562 1.4. Leveraging the new key infrastructure / next steps 564 As a result of the protocol described herein, the bootstrapped 565 devices have the Domain CA trust anchor in common. An end entity 566 certificate has optionally been issued from the Domain CA. This 567 makes it possible to securely deploy functionalities across the 568 domain, e.g: 570 * Device management. 572 * Routing authentication. 574 * Service discovery. 576 The major intended benefit is that it possible to use the credentials 577 deployed by this protocol to secure the Autonomic Control Plane (ACP) 578 ([I-D.ietf-anima-autonomic-control-plane]). 580 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 582 The BRSKI protocol can be used in a number of environments. Some of 583 the options in this document are the result of requirements that are 584 out of the ANI scope. This section defines the base requirements for 585 ANI devices. 587 For devices that intend to become part of an Autonomic Network 588 Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes 589 an Autonomic Control Plane 590 ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST 591 be implemented. 593 The pledge must perform discovery of the proxy as described in 594 Section 4.1 using Generic Autonomic Signaling Protocol (GRASP)'s DULL 595 [I-D.ietf-anima-grasp] M_FLOOD announcements. 597 Upon successfully validating a voucher artifact, a status telemetry 598 MUST be returned. See Section 5.7. 600 An ANIMA ANI pledge MUST implement the EST automation extensions 601 described in Section 5.9. They supplement the [RFC7030] EST to 602 better support automated devices that do not have an end user. 604 The ANI Join Registrar Autonomic Service Agent (ASA) MUST support all 605 the BRSKI and above listed EST operations. 607 All ANI devices SHOULD support the BRSKI proxy function, using 608 circuit proxies over the ACP. (See Section 4.3) 610 2. Architectural Overview 612 The logical elements of the bootstrapping framework are described in 613 this section. Figure 1 provides a simplified overview of the 614 components. 616 +------------------------+ 617 +--------------Drop Ship----------------| Vendor Service | 618 | +------------------------+ 619 | | M anufacturer| | 620 | | A uthorized |Ownership| 621 | | S igning |Tracker | 622 | | A uthority | | 623 | +--------------+---------+ 624 | ^ 625 | | BRSKI- 626 V | MASA 627 +-------+ ............................................|... 628 | | . | . 629 | | . +------------+ +-----------+ | . 630 | | . | | | | | . 631 |Pledge | . | Join | | Domain <-------+ . 632 | | . | Proxy | | Registrar | . 633 | <-------->............<-------> (PKI RA) | . 634 | | | BRSKI-EST | | . 635 | | . | | +-----+-----+ . 636 |IDevID | . +------------+ | e.g. RFC7030 . 637 | | . +-----------------+----------+ . 638 | | . | Key Infrastructure | . 639 | | . | (e.g., PKI Certificate | . 640 +-------+ . | Authority) | . 641 . +----------------------------+ . 642 . . 643 ................................................ 644 "Domain" components 646 Figure 1: Architecture Overview 648 We assume a multi-vendor network. In such an environment there could 649 be a Manufacturer Service for each manufacturer that supports devices 650 following this document's specification, or an integrator could 651 provide a generic service authorized by multiple manufacturers. It 652 is unlikely that an integrator could provide Ownership Tracking 653 services for multiple manufacturers due to the required sales channel 654 integrations necessary to track ownership. 656 The domain is the managed network infrastructure with a Key 657 Infrastructure the pledge is joining. The domain provides initial 658 device connectivity sufficient for bootstrapping through a proxy. 659 The domain registrar authenticates the pledge, makes authorization 660 decisions, and distributes vouchers obtained from the Manufacturer 661 Service. Optionally the registrar also acts as a PKI Certification 662 Authority. 664 2.1. Behavior of a Pledge 666 The pledge goes through a series of steps, which are outlined here at 667 a high level. 669 ------------ 670 / Factory \ 671 \ default / 672 -----+------ 673 | 674 +------v-------+ 675 | (1) Discover | 676 +------------> | 677 | +------+-------+ 678 | | 679 | +------v-------+ 680 | | (2) Identify | 681 ^------------+ | 682 | rejected +------+-------+ 683 | | 684 | +------v-------+ 685 | | (3) Request | 686 | | Join | 687 | +------+-------+ 688 | | 689 | +------v-------+ 690 | | (4) Imprint | 691 ^------------+ | 692 | Bad MASA +------+-------+ 693 | response | send Voucher Status Telemetry 694 | +------v-------+ 695 | | (5) Enroll |<---+ (non-error HTTP codes ) 696 ^------------+ |\___/ (e.g. 202 'Retry-After') 697 | Enroll +------+-------+ 698 | Failure | 699 | -----v------ 700 | / Enrolled \ 701 ^------------+ | 702 Factory \------------/ 703 reset 705 Figure 2: Pledge State Diagram 707 State descriptions for the pledge are as follows: 709 1. Discover a communication channel to a registrar. 711 2. Identify itself. This is done by presenting an X.509 IDevID 712 credential to the discovered registrar (via the proxy) in a TLS 713 handshake. (The registrar credentials are only provisionally 714 accepted at this time). 716 3. Request to join the discovered registrar. A unique nonce is 717 included ensuring that any responses can be associated with this 718 particular bootstrapping attempt. 720 4. Imprint on the registrar. This requires verification of the 721 manufacturer-service-provided voucher. A voucher contains 722 sufficient information for the pledge to complete authentication 723 of a registrar. This document details this step in depth. 725 5. Enroll. After imprint an authenticated TLS (HTTPS) connection 726 exists between pledge and registrar. Enrollment over Secure 727 Transport (EST) [RFC7030] can then be used to obtain a domain 728 certificate from a registrar. 730 The pledge is now a member of, and can be managed by, the domain and 731 will only repeat the discovery aspects of bootstrapping if it is 732 returned to factory default settings. 734 This specification details integration with EST enrollment so that 735 pledges can optionally obtain a locally issued certificate, although 736 any Representational State Transfer (REST) (see [REST]) interface 737 could be integrated in future work. 739 2.2. Secure Imprinting using Vouchers 741 A voucher is a cryptographically protected artifact (using a digital 742 signature) to the pledge device authorizing a zero-touch imprint on 743 the registrar domain. 745 The format and cryptographic mechanism of vouchers is described in 746 detail in [RFC8366]. 748 Vouchers provide a flexible mechanism to secure imprinting: the 749 pledge device only imprints when a voucher can be validated. At the 750 lowest security levels the MASA can indiscriminately issue vouchers 751 and log claims of ownership by domains. At the highest security 752 levels issuance of vouchers can be integrated with complex sales 753 channel integrations that are beyond the scope of this document. The 754 sales channel integration would verify actual (legal) ownership of 755 the pledge by the domain. This provides the flexibility for a number 756 of use cases via a single common protocol mechanism on the pledge and 757 registrar devices that are to be widely deployed in the field. The 758 MASA services have the flexibility to leverage either the currently 759 defined claim mechanisms or to experiment with higher or lower 760 security levels. 762 Vouchers provide a signed but non-encrypted communication channel 763 among the pledge, the MASA, and the registrar. The registrar 764 maintains control over the transport and policy decisions, allowing 765 the local security policy of the domain network to be enforced. 767 2.3. Initial Device Identifier 769 Pledge authentication and pledge voucher-request signing is via a 770 PKIX-shaped certificate installed during the manufacturing process. 771 This is the 802.1AR Initial Device Identifier (IDevID), and it 772 provides a basis for authenticating the pledge during the protocol 773 exchanges described here. There is no requirement for a common root 774 PKI hierarchy. Each device manufacturer can generate its own root 775 certificate. Specifically, the IDevID enables: 777 1. Uniquely identifying the pledge by the Distinguished Name (DN) 778 and subjectAltName (SAN) parameters in the IDevID. The unique 779 identification of a pledge in the voucher objects are derived 780 from those parameters as described below. Section 10.3 discusses 781 privacy implications of the identifier. 783 2. Provides a cryptographic authentication of the pledge to the 784 Registrar (see Section 5.3). 786 3. Secure auto-discovery of the pledge's MASA by the registrar (see 787 Section 2.8). 789 4. Signing of voucher-request by the pledge's IDevID (see 790 Section 3). 792 5. Provides a cryptographic authentication of the pledge to the MASA 793 (see Section 5.5.5). 795 Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of 796 [IDevID] discusses keyUsage and extendedKeyUsage extensions in the 797 IDevID certificate. [IDevID] acknowledges that adding restrictions 798 in the certificate limits applicability of these long-lived 799 certificates. This specification emphasizes this point, and 800 therefore RECOMMENDS that no key usage restrictions be included. 801 This is consistent with [RFC5280] section 4.2.1.3, which does not 802 require key usage restrictions for end entity certificates. 804 2.3.1. Identification of the Pledge 806 In the context of BRSKI, pledges have a 1:1 relationship with a 807 "serial-number". This serial-number is used both in the "serial- 808 number" field of voucher or voucher-requests (see Section 3) and in 809 local policies on registrar or MASA (see Section 5). 811 The serialNumber field is defined in [RFC5280]. That specification 812 allows for the field to be omitted if there is a good technical 813 reason. IDevID certificates for use with this protocol are REQUIRED 814 to include the "serialNumber" attribute with the device's unique 815 serial number (from [IDevID] section 7.2.8, and [RFC5280] section 816 4.1.2.2's list of standard attributes). 818 The serialNumber field is used as follows by the pledge to build the 819 "serial-number" that is placed in the voucher-request. In order to 820 build it, the fields need to be converted into a serial-number of 821 "type string". 823 An example of a printable form of the "serialNumber" field is 824 provided in [RFC4519] section 2.31 ("WI-3005"). That section further 825 provides equality and syntax attributes. 827 Due to the reality of existing device identity provisioning 828 processes, some manufacturers have stored serial-numbers in other 829 fields. Registrar's SHOULD be configurable, on a per-manufacturer 830 basis, to look for serial-number equivalents in other fields. 832 As explained in Section 5.5 the Registrar MUST extract the serial- 833 number again itself from the pledge's TLS certificate. It can 834 consult the serial-number in the pledge-request if there are any 835 possible confusion about the source of the serial-number. 837 2.3.2. MASA URI extension 839 This document defines a new PKIX non-critical certificate extension 840 to carry the MASA URI. This extension is intended to be used in the 841 IDevID certificate. The URI is represented as described in 842 Section 7.4 of [RFC5280]. 844 The URI provides the authority information. The BRSKI "/.well-known" 845 tree ([RFC5785]) is described in Section 5. 847 A complete URI MAY be in this extension, including the 'scheme', 848 'authority', and 'path', The complete URI will typically be used in 849 diagnostic or experimental situations. Typically, (and in 850 consideration to constrained systems), this SHOULD be reduced to only 851 the 'authority', in which case a scheme of "https://" ([RFC7230] 852 section 2.7.3) and 'path' of "/.well-known/est" is to be assumed. 854 The registrar can assume that only the 'authority' is present in the 855 extension, if there are no slash ("/") characters in the extension. 857 Section 7.4 of [RFC5280] calls out various schemes that MUST be 858 supported, including LDAP, HTTP and FTP. However, the registrar MUST 859 use HTTPS for the BRSKI-MASA connection. 861 The new extension is identified as follows: 863 864 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 865 internet(1) security(5) mechanisms(5) pkix(7) 866 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 868 DEFINITIONS IMPLICIT TAGS ::= BEGIN 870 -- EXPORTS ALL -- 872 IMPORTS 873 EXTENSION 874 FROM PKIX-CommonTypes-2009 875 { iso(1) identified-organization(3) dod(6) internet(1) 876 security(5) mechanisms(5) pkix(7) id-mod(0) 877 id-mod-pkixCommon-02(57) } 879 id-pe FROM PKIX1Explicit-2009 880 { iso(1) identified-organization(3) dod(6) internet(1) 881 security(5) mechanisms(5) pkix(7) id-mod(0) 882 id-mod-pkix1-explicit-02(51) } ; 884 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 885 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 886 IDENTIFIED BY id-pe-masa-url } 888 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 890 MASAURLSyntax ::= IA5String 892 END 893 895 Figure 3: MASAURL ASN.1 Module 897 The choice of id-pe is based on guidance found in Section 4.2.2 of 898 [RFC5280], "These extensions may be used to direct applications to 899 on-line information about the issuer or the subject". The MASA URL 900 is precisely that: online information about the particular subject. 902 2.4. Protocol Flow 904 A representative flow is shown in Figure 4 905 +--------+ +---------+ +------------+ +------------+ 906 | Pledge | | Circuit | | Domain | | Vendor | 907 | | | Join | | Registrar | | Service | 908 | | | Proxy | | (JRC) | | (MASA) | 909 +--------+ +---------+ +------------+ +------------+ 910 | | | Internet | 911 [discover] | | | 912 |<-RFC4862 IPv6 addr | | | 913 |<-RFC3927 IPv4 addr | Appendix A | Legend | 914 |-++++++++++++++++++->| | C - circuit | 915 | optional: mDNS query| Appendix B | join proxy | 916 | RFC6763/RFC6762 (+) | | P - provisional | 917 |<-++++++++++++++++++-| | TLS connection | 918 | GRASP M_FLOOD | | | 919 | periodic broadcast| | | 920 [identity] | | | 921 |<------------------->C<----------------->| | 922 | TLS via the Join Proxy | | 923 |<--Registrar TLS server authentication---| | 924 [PROVISIONAL accept of server cert] | | 925 P---X.509 client authentication---------->| | 926 [request join] | | 927 P---Voucher Request(w/nonce for voucher)->| | 928 P /------------------- | | 929 P | [accept device?] | 930 P | [contact Vendor] | 931 P | |--Pledge ID-------->| 932 P | |--Domain ID-------->| 933 P | |--optional:nonce--->| 934 P optional: | [extract DomainID] 935 P can occur in advance | [update audit log] 936 P if nonceleess | | 937 P | |<- voucher ---------| 938 P \------------------- | w/nonce if provided| 939 P<------voucher---------------------------| | 940 [imprint] | | 941 |-------voucher status telemetry--------->| | 942 | |<-device audit log--| 943 | [verify audit log and voucher] | 944 |<--------------------------------------->| | 945 [enroll] | | 946 | Continue with RFC7030 enrollment | | 947 | using now bidirectionally authenticated | | 948 | TLS session. | | 949 [enrolled] | | 951 Figure 4: Protocol Time Sequence Diagram 953 On initial bootstrap, a new device (the pledge) uses a local service 954 autodiscovery (GRASP or mDNS) to locate a join proxy. The join proxy 955 connects the pledge to a local registrar (the JRC). 957 Having found a candidate registrar, the fledgling pledge sends some 958 information about itself to the registrar, including its serial 959 number in the form of a voucher request and its device identity 960 certificate (IDevID) as part of the TLS session. 962 The registrar can determine whether it expected such a device to 963 appear, and locates a MASA. The location of the MASA is usually 964 found in an extension in the IDevID. Having determined that the MASA 965 is suitable, the entire information from the initial voucher request 966 (including device serial number) is transmitted over the internet in 967 a TLS protected channel to the manufacturer, along with information 968 about the registrar/owner. 970 The manufacturer can then apply policy based on the provided 971 information, as well as other sources of information (such as sales 972 records), to decide whether to approve the claim by the registrar to 973 own the device; if the claim is accepted, a voucher is issued that 974 directs the device to accept its new owner. 976 The voucher is returned to the registrar, but not immediately to the 977 device -- the registrar has an opportunity to examine the voucher, 978 the MASA's audit-logs, and other sources of information to determine 979 whether the device has been tampered with, and whether the bootstrap 980 should be accepted. 982 No filtering of information is possible in the signed voucher, so 983 this is a binary yes-or-no decision. If the registrar accepts the 984 voucher as a proper one for its device, the voucher is returned to 985 the pledge for imprinting. 987 The voucher also includes a trust anchor that the pledge uses as 988 representing the owner. This is used to successfully bootstrap from 989 an environment where only the manufacturer has built-in trust by the 990 device into an environment where the owner now has a PKI footprint on 991 the device. 993 When BRSKI is followed with EST this single footprint is further 994 leveraged into the full owner's PKI and a LDevID for the device. 995 Subsequent reporting steps provide flows of information to indicate 996 success/failure of the process. 998 2.5. Architectural Components 1000 2.5.1. Pledge 1002 The pledge is the device that is attempting to join. The pledge is 1003 assumed to talk to the Join Proxy using link-local network 1004 connectivity. In most cases, the pledge has no other connectivity 1005 until the pledge completes the enrollment process and receives some 1006 kind of network credential. 1008 2.5.2. Join Proxy 1010 The join proxy provides HTTPS connectivity between the pledge and the 1011 registrar. A circuit proxy mechanism is described in Section 4. 1012 Additional mechanisms, including a CoAP mechanism and a stateless 1013 IPIP mechanism are the subject of future work. 1015 2.5.3. Domain Registrar 1017 The domain's registrar operates as the BRSKI-MASA client when 1018 requesting vouchers from the MASA (see Section 5.4). The registrar 1019 operates as the BRSKI-EST server when pledges request vouchers (see 1020 Section 5.1). The registrar operates as the BRSKI-EST server 1021 "Registration Authority" if the pledge requests an end entity 1022 certificate over the BRSKI-EST connection (see Section 5.9). 1024 The registrar uses an Implicit Trust Anchor database for 1025 authenticating the BRSKI-MASA connection's MASA TLS Server 1026 Certificate. Configuration or distribution of trust anchors is out- 1027 of-scope for this specification. 1029 The registrar uses a different Implicit Trust Anchor database for 1030 authenticating the BRSKI-EST connection's Pledge TLS Client 1031 Certificate. Configuration or distribution of the BRSKI-EST client 1032 trust anchors is out-of-scope of this specification. Note that the 1033 trust anchors in/excluded from the database will affect which 1034 manufacturers' devices are acceptable to the registrar as pledges, 1035 and can also be used to limit the set of MASAs that are trusted for 1036 enrollment. 1038 2.5.4. Manufacturer Service 1040 The Manufacturer Service provides two logically separate functions: 1041 the Manufacturer Authorized Signing Authority (MASA) described in 1042 Section 5.5 and Section 5.6, and an ownership tracking/auditing 1043 function described in Section 5.7 and Section 5.8. 1045 2.5.5. Public Key Infrastructure (PKI) 1047 The Public Key Infrastructure (PKI) administers certificates for the 1048 domain of concern, providing the trust anchor(s) for it and allowing 1049 enrollment of pledges with domain certificates. 1051 The voucher provides a method for the distribution of a single PKI 1052 trust anchor (as the "pinned-domain-cert"). A distribution of the 1053 full set of current trust anchors is possible using the optional EST 1054 integration. 1056 The domain's registrar acts as an [RFC5272] Registration Authority, 1057 requesting certificates for pledges from the Key Infrastructure. 1059 The expectations of the PKI are unchanged from EST [RFC7030]. This 1060 document does not place any additional architectural requirements on 1061 the Public Key Infrastructure. 1063 2.6. Certificate Time Validation 1065 2.6.1. Lack of realtime clock 1067 Many devices when bootstrapping do not have knowledge of the current 1068 time. Mechanisms such as Network Time Protocols cannot be secured 1069 until bootstrapping is complete. Therefore bootstrapping is defined 1070 with a framework that does not require knowledge of the current time. 1071 A pledge MAY ignore all time stamps in the voucher and in the 1072 certificate validity periods if it does not know the current time. 1074 The pledge is exposed to dates in the following five places: 1075 registrar certificate notBefore, registrar certificate notAfter, 1076 voucher created-on, and voucher expires-on. Additionally, CMS 1077 signatures contain a signingTime. 1079 A pledge with a real time clock in which it has confidence, MUST 1080 check the above time fields in all certificates and signatures that 1081 it processes. 1083 If the voucher contains a nonce then the pledge MUST confirm the 1084 nonce matches the original pledge voucher-request. This ensures the 1085 voucher is fresh. See Section 5.2. 1087 2.6.2. Infinite Lifetime of IDevID 1089 [RFC5280] explains that long lived pledge certificates "SHOULD be 1090 assigned the GeneralizedTime value of 99991231235959Z" for the 1091 notAfter field. 1093 Some deployed IDevID management systems are not compliant with the 1094 802.1AR requirement for infinite lifetimes, and put in typical <= 3 1095 year certificate lifetimes. Registrars SHOULD be configurable on a 1096 per-manufacturer basis to ignore pledge lifetimes when the pledge did 1097 not follow the RFC5280 recommendations. 1099 2.7. Cloud Registrar 1101 There exist operationally open networks wherein devices gain 1102 unauthenticated access to the Internet at large. In these use cases 1103 the management domain for the device needs to be discovered within 1104 the larger Internet. The case where a device can boot and get access 1105 to larger Internet are less likely within the ANIMA ACP scope but may 1106 be more important in the future. In the ANIMA ACP scope, new devices 1107 will be quarantined behind a Join Proxy. 1109 There are additionally some greenfield situations involving an 1110 entirely new installation where a device may have some kind of 1111 management uplink that it can use (such as via 3G network for 1112 instance). In such a future situation, the device might use this 1113 management interface to learn that it should configure itself to 1114 become the local registrar. 1116 In order to support these scenarios, the pledge MAY contact a well 1117 known URI of a cloud registrar if a local registrar cannot be 1118 discovered or if the pledge's target use cases do not include a local 1119 registrar. 1121 If the pledge uses a well known URI for contacting a cloud registrar 1122 a manufacturer-assigned Implicit Trust Anchor database (see 1123 [RFC7030]) MUST be used to authenticate that service as described in 1124 [RFC6125]. The use of a DNS-ID for validation is appropriate, and it 1125 may include wildcard components on the left-mode side. This is 1126 consistent with the human user configuration of an EST server URI in 1127 [RFC7030] which also depends on RFC6125. 1129 2.8. Determining the MASA to contact 1131 The registrar needs to be able to contact a MASA that is trusted by 1132 the pledge in order to obtain vouchers. There are three mechanisms 1133 described: 1135 The device's Initial Device Identifier (IDevID) will normally contain 1136 the MASA URL as detailed in Section 2.3. This is the RECOMMENDED 1137 mechanism. 1139 It can be operationally difficult to ensure the necessary X.509 1140 extensions are in the pledge's IDevID due to the difficulty of 1141 aligning current pledge manufacturing with software releases and 1142 development. As a final fallback the registrar MAY be manually 1143 configured or distributed with a MASA URL for each manufacturer. 1144 Note that the registrar can only select the configured MASA URL based 1145 on the trust anchor -- so manufacturers can only leverage this 1146 approach if they ensure a single MASA URL works for all pledges 1147 associated with each trust anchor. 1149 3. Voucher-Request artifact 1151 Voucher-requests are how vouchers are requested. The semantics of 1152 the voucher-request are described below, in the YANG model. 1154 A pledge forms the "pledge voucher-request", signs it with it's 1155 IDevID and submits it to the registrar. 1157 The registrar in turn forms the "registrar voucher-request", signs it 1158 with it's Registrar keypair and submits it to the MASA. 1160 The "proximity-registrar-cert" leaf is used in the pledge voucher- 1161 requests. This provides a method for the pledge to assert the 1162 registrar's proximity. 1164 This network proximity results from the following properties in the 1165 ACP context: the pledge is connected to the Join Proxy (Section 4) 1166 using a Link-Local IPv6 connection. While the Join Proxy does not 1167 participate in any meaningful sense in the cryptography of the TLS 1168 connection (such as via a Channel Binding), the Registrar can observe 1169 that the connection is via the private ACP (ULA) address of the join 1170 proxy, and could not come from outside the ACP. The Pledge must 1171 therefore be at most one IPv6 Link-Local hop away from an existing 1172 node on the ACP. 1174 Other users of BRSKI will need to define other kinds of assertions if 1175 the network proximity described above does not match their needs. 1177 The "prior-signed-voucher-request" leaf is used in registrar voucher- 1178 requests. If present, it is the signed pledge voucher-request 1179 artifact. This provides a method for the registrar to forward the 1180 pledge's signed request to the MASA. This completes transmission of 1181 the signed "proximity-registrar-cert" leaf. 1183 Unless otherwise signaled (outside the voucher-request artifact), the 1184 signing structure is as defined for vouchers, see [RFC8366]. 1186 3.1. Nonceless Voucher Requests 1188 A registrar MAY also retrieve nonceless vouchers by sending nonceless 1189 voucher-requests to the MASA in order to obtain vouchers for use when 1190 the registrar does not have connectivity to the MASA. No "prior- 1191 signed-voucher-request" leaf would be included. The registrar will 1192 also need to know the serial number of the pledge. This document 1193 does not provide a mechanism for the registrar to learn that in an 1194 automated fashion. Typically this will be done via scanning of bar- 1195 code or QR-code on packaging, or via some sales channel integration. 1197 3.2. Tree Diagram 1199 The following tree diagram illustrates a high-level view of a 1200 voucher-request document. The voucher-request builds upon the 1201 voucher artifact described in [RFC8366]. The tree diagram is 1202 described in [RFC8340]. Each node in the diagram is fully described 1203 by the YANG module in Section 3.4. Please review the YANG module for 1204 a detailed description of the voucher-request format. 1206 module: ietf-voucher-request 1208 grouping voucher-request-grouping 1209 +---- voucher 1210 +---- created-on? yang:date-and-time 1211 +---- expires-on? yang:date-and-time 1212 +---- assertion? enumeration 1213 +---- serial-number string 1214 +---- idevid-issuer? binary 1215 +---- pinned-domain-cert? binary 1216 +---- domain-cert-revocation-checks? boolean 1217 +---- nonce? binary 1218 +---- last-renewal-date? yang:date-and-time 1219 +---- prior-signed-voucher-request? binary 1220 +---- proximity-registrar-cert? binary 1222 Figure 5: YANG Tree diagram for Voucher-Request 1224 3.3. Examples 1226 This section provides voucher-request examples for illustration 1227 purposes. These examples show the JSON prior to CMS wrapping. JSON 1228 encoding rules specify that any binary content be base64 encoded 1229 ([RFC4648] section 4). The contents of the (base64) encoded 1230 certificates have been elided to save space. For detailed examples, 1231 see Appendix C.2. These examples conform to the encoding rules 1232 defined in [RFC7951]. 1234 Example (1) The following example illustrates a pledge voucher- 1235 request. The assertion leaf is indicated as 'proximity' 1236 and the registrar's TLS server certificate is included 1237 in the 'proximity-registrar-cert' leaf. See 1238 Section 5.2. 1240 { 1241 "ietf-voucher-request:voucher": { 1242 "assertion": "proximity", 1243 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1244 "serial-number" : "JADA123456789", 1245 "created-on": "2017-01-01T00:00:00.000Z", 1246 "proximity-registrar-cert": "base64encodedvalue==" 1247 } 1248 } 1250 Figure 6: JSON representation of example Voucher-Request 1252 Example (2) The following example illustrates a registrar voucher- 1253 request. The 'prior-signed-voucher-request' leaf is 1254 populated with the pledge's voucher-request (such as the 1255 prior example). The pledge's voucher-request is a 1256 binary CMS signed object. In the JSON encoding used 1257 here it must be base64 encoded. The nonce and assertion 1258 have been carried forward from the pledge request to the 1259 registrar request. The serial-number is extracted from 1260 the pledge's Client Certificate from the TLS connection. 1261 See Section 5.5. 1263 { 1264 "ietf-voucher-request:voucher": { 1265 "assertion" : "proximity", 1266 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1267 "created-on": "2017-01-01T00:00:02.000Z", 1268 "idevid-issuer": "base64encodedvalue==", 1269 "serial-number": "JADA123456789", 1270 "prior-signed-voucher-request": "base64encodedvalue==" 1271 } 1272 } 1274 Figure 7: JSON representation of example Prior-Signed Voucher-Request 1276 Example (3) The following example illustrates a registrar voucher- 1277 request. The 'prior-signed-voucher-request' leaf is not 1278 populated with the pledge's voucher-request nor is the 1279 nonce leaf. This form might be used by a registrar 1280 requesting a voucher when the pledge can not communicate 1281 with the registrar (such as when it is powered down, or 1282 still in packaging), and therefore could not submit a 1283 nonce. This scenario is most useful when the registrar 1284 is aware that it will not be able to reach the MASA 1285 during deployment. See Section 5.5. 1287 { 1288 "ietf-voucher-request:voucher": { 1289 "created-on": "2017-01-01T00:00:02.000Z", 1290 "idevid-issuer": "base64encodedvalue==", 1291 "serial-number": "JADA123456789" 1292 } 1293 } 1295 Figure 8: JSON representation of Offline Voucher-Request 1297 3.4. YANG Module 1299 Following is a YANG [RFC7950] module formally extending the [RFC8366] 1300 voucher into a voucher-request. 1302 file "ietf-voucher-request@2018-02-14.yang" 1303 module ietf-voucher-request { 1304 yang-version 1.1; 1306 namespace 1307 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 1308 prefix "vcr"; 1310 import ietf-restconf { 1311 prefix rc; 1312 description "This import statement is only present to access 1313 the yang-data extension defined in RFC 8040."; 1314 reference "RFC 8040: RESTCONF Protocol"; 1315 } 1317 import ietf-voucher { 1318 prefix vch; 1319 description "This module defines the format for a voucher, 1320 which is produced by a pledge's manufacturer or 1321 delegate (MASA) to securely assign a pledge to 1322 an 'owner', so that the pledge may establish a secure 1323 connection to the owner's network infrastructure"; 1325 reference "RFC 8366: Voucher Artifact for Bootstrapping Protocols"; 1326 } 1328 organization 1329 "IETF ANIMA Working Group"; 1331 contact 1332 "WG Web: 1333 WG List: 1334 Author: Kent Watsen 1335 1336 Author: Michael H. Behringer 1337 1338 Author: Toerless Eckert 1339 1340 Author: Max Pritikin 1341 1342 Author: Michael Richardson 1343 "; 1345 description 1346 "This module defines the format for a voucher request. 1347 It is a superset of the voucher itself. 1348 It provides content to the MASA for consideration 1349 during a voucher request. 1351 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 1352 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1353 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1354 described in BCP 14 RFC2119 RFC8174 when, and only when, they 1355 appear in all capitals, as shown here. 1357 Copyright (c) 2019 IETF Trust and the persons identified as 1358 authors of the code. All rights reserved. 1360 Redistribution and use in source and binary forms, with or without 1361 modification, is permitted pursuant to, and subject to the license 1362 terms contained in, the Simplified BSD License set forth in Section 1363 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1364 (http://trustee.ietf.org/license-info). 1366 This version of this YANG module is part of RFC XXXX; see the RFC 1367 itself for full legal notices."; 1369 revision "2018-02-14" { 1370 description 1371 "Initial version"; 1372 reference 1373 "RFC XXXX: Bootstrapping Remote Secure Key Infrastructure"; 1374 } 1376 // Top-level statement 1377 rc:yang-data voucher-request-artifact { 1378 uses voucher-request-grouping; 1380 } 1382 // Grouping defined for future usage 1383 grouping voucher-request-grouping { 1384 description 1385 "Grouping to allow reuse/extensions in future work."; 1387 uses vch:voucher-artifact-grouping { 1388 refine "voucher/created-on" { 1389 mandatory false; 1390 } 1392 refine "voucher/pinned-domain-cert" { 1393 mandatory false; 1394 } 1396 refine "voucher/domain-cert-revocation-checks" { 1397 description "The domain-cert-revocation-checks field 1398 is not valid in a voucher request, and 1399 any occurence MUST be ignored"; 1400 } 1402 refine "voucher/assertion" { 1403 mandatory false; 1404 description "Any assertion included in registrar voucher 1405 requests SHOULD be ignored by the MASA."; 1406 } 1408 augment "voucher" { 1409 description 1410 "Adds leaf nodes appropriate for requesting vouchers."; 1412 leaf prior-signed-voucher-request { 1413 type binary; 1414 description 1415 "If it is necessary to change a voucher, or re-sign and 1416 forward a voucher that was previously provided along a 1417 protocol path, then the previously signed voucher SHOULD be 1418 included in this field. 1420 For example, a pledge might sign a voucher request 1421 with a proximity-registrar-cert, and the registrar 1422 then includes it as the prior-signed-voucher-request field. 1423 This is a simple mechanism for a chain of trusted 1424 parties to change a voucher request, while 1425 maintaining the prior signature information. 1427 The Registrar and MASA MAY examine the prior signed 1428 voucher information for the 1429 purposes of policy decisions. For example this information 1430 could be useful to a MASA to determine that both pledge and 1431 registrar agree on proximity assertions. The MASA SHOULD 1432 remove all prior-signed-voucher-request information when 1433 signing a voucher for imprinting so as to minimize the 1434 final voucher size."; 1435 } 1437 leaf proximity-registrar-cert { 1438 type binary; 1439 description 1440 "An X.509 v3 certificate structure as specified by RFC 5280, 1441 Section 4 encoded using the ASN.1 distinguished encoding 1442 rules (DER), as specified in [ITU.X690.1994]. 1444 The first certificate in the Registrar TLS server 1445 certificate_list sequence (the end-entity TLS certificate, 1446 see [RFC8446]) presented by the Registrar to the Pledge. 1447 This MUST be populated in a Pledge's voucher request when a 1448 proximity assertion is requested."; 1449 } 1450 } 1451 } 1452 } 1454 } 1455 1457 Figure 9: YANG module for Voucher-Request 1459 4. Proxying details (Pledge - Proxy - Registrar) 1461 This section is normative for uses with an ANIMA ACP. The use of the 1462 GRASP mechanism is part of the ACP. Other users of BRSKI will need 1463 to define an equivalent proxy mechanism, and an equivalent mechanism 1464 to configure the proxy. 1466 The role of the proxy is to facilitate communications. The proxy 1467 forwards packets between the pledge and a registrar that has been 1468 provisioned to the proxy via full GRASP ACP discovery. 1470 This section defines a stateful proxy mechanism which is referred to 1471 as a "circuit" proxy. This is a form of Application Level Gateway 1472 ([RFC2663] section 2.9). 1474 The proxy does not terminate the TLS handshake: it passes streams of 1475 bytes onward without examination. A proxy MUST NOT assume any 1476 specific TLS version. Please see [RFC8446] section 9.3 for details 1477 on TLS invariants. 1479 A Registrar can directly provide the proxy announcements described 1480 below, in which case the announced port can point directly to the 1481 Registrar itself. In this scenario the pledge is unaware that there 1482 is no proxying occurring. This is useful for Registrars which are 1483 servicing pledges on directly connected networks. 1485 As a result of the proxy Discovery process in Section 4.1.1, the port 1486 number exposed by the proxy does not need to be well known, or 1487 require an IANA allocation. 1489 During the discovery of the Registrar by the Join Proxy, the Join 1490 Proxy will also learn which kinds of proxy mechanisms are available. 1491 This will allow the Join Proxy to use the lowest impact mechanism 1492 which the Join Proxy and Registrar have in common. 1494 In order to permit the proxy functionality to be implemented on the 1495 maximum variety of devices the chosen mechanism should use the 1496 minimum amount of state on the proxy device. While many devices in 1497 the ANIMA target space will be rather large routers, the proxy 1498 function is likely to be implemented in the control plane CPU of such 1499 a device, with available capabilities for the proxy function similar 1500 to many class 2 IoT devices. 1502 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1503 more extensive analysis and background of the alternative proxy 1504 methods. 1506 4.1. Pledge discovery of Proxy 1508 The result of discovery is a logical communication with a registrar, 1509 through a proxy. The proxy is transparent to the pledge. The 1510 communication between the pledge and Join Proxy is over IPv6 Link- 1511 Local addresses. 1513 To discover the proxy the pledge performs the following actions: 1515 1. MUST: Obtains a local address using IPv6 methods as described in 1516 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1517 [RFC4941] temporary addresses is encouraged. To limit pervasive 1518 monitoring ( [RFC7258]), a new temporary address MAY use a short 1519 lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). 1520 Pledges will generally prefer use of IPv6 Link-Local addresses, 1521 and discovery of proxy will be by Link-Local mechanisms. IPv4 1522 methods are described in Appendix A 1524 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1525 announcements of the objective: "AN_Proxy". See section 1526 Section 4.1.1 for the details of the objective. The pledge MAY 1527 listen concurrently for other sources of information, see 1528 Appendix B. 1530 Once a proxy is discovered the pledge communicates with a registrar 1531 through the proxy using the bootstrapping protocol defined in 1532 Section 5. 1534 While the GRASP M_FLOOD mechanism is passive for the pledge, the non- 1535 normative other methods (mDNS, and IPv4 methods) described in 1536 Appendix B are active. The pledge SHOULD run those methods in 1537 parallel with listening to for the M_FLOOD. The active methods 1538 SHOULD back-off by doubling to a maximum of one hour to avoid 1539 overloading the network with discovery attempts. Detection of change 1540 of physical link status (Ethernet carrier for instance) SHOULD reset 1541 the back off timers. 1543 The pledge could discover more than one proxy on a given physical 1544 interface. The pledge can have a multitude of physical interfaces as 1545 well: a layer-2/3 Ethernet switch may have hundreds of physical 1546 ports. 1548 Each possible proxy offer SHOULD be attempted up to the point where a 1549 valid voucher is received: while there are many ways in which the 1550 attempt may fail, it does not succeed until the voucher has been 1551 validated. 1553 The connection attempts via a single proxy SHOULD exponentially back- 1554 off to a maximum of one hour to avoid overloading the network 1555 infrastructure. The back-off timer for each MUST be independent of 1556 other connection attempts. 1558 Connection attempts SHOULD be run in parallel to avoid head of queue 1559 problems wherein an attacker running a fake proxy or registrar could 1560 perform protocol actions intentionally slowly. Connection attempts 1561 to different proxies SHOULD be sent with an interval of 3 to 5s. The 1562 pledge SHOULD continue to listen to for additional GRASP M_FLOOD 1563 messages during the connection attempts. 1565 Each connection attempt through a distinct Join Proxy MUST have a 1566 unique nonce in the voucher-request. 1568 Once a connection to a registrar is established (e.g. establishment 1569 of a TLS session key) there are expectations of more timely 1570 responses, see Section 5.2. 1572 Once all discovered services are attempted (assuming that none 1573 succeeded) the device MUST return to listening for GRASP M_FLOOD. It 1574 SHOULD periodically retry any manufacturer-specific mechanisms. The 1575 pledge MAY prioritize selection order as appropriate for the 1576 anticipated environment. 1578 4.1.1. Proxy GRASP announcements 1580 A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. 1581 This announcement can be within the same message as the ACP 1582 announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. 1584 The formal Concise Data Definition Language (CDDL) [RFC8610] 1585 definition is: 1587 flood-message = [M_FLOOD, session-id, initiator, ttl, 1588 +[objective, (locator-option / [])]] 1590 objective = ["AN_Proxy", objective-flags, loop-count, 1591 objective-value] 1593 ttl = 180000 ; 180,000 ms (3 minutes) 1594 initiator = ACP address to contact Registrar 1595 objective-flags = sync-only ; as in GRASP spec 1596 sync-only = 4 ; M_FLOOD only requires synchronization 1597 loop-count = 1 ; one hop only 1598 objective-value = any ; none 1600 locator-option = [ O_IPv6_LOCATOR, ipv6-address, 1601 transport-proto, port-number ] 1602 ipv6-address = the v6 LL of the Proxy 1603 $transport-proto /= IPPROTO_TCP ; note this can be any value from the 1604 ; IANA protocol registry, as per 1605 ; [GRASP] section 2.9.5.1, note 3. 1606 port-number = selected by Proxy 1608 Figure 10: CDDL definition of Proxy Discovery message 1610 Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port 1611 4443. 1613 [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, 1614 ["AN_Proxy", 4, 1, ""], 1615 [O_IPv6_LOCATOR, 1616 h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] 1618 Figure 11: Example of Proxy Discovery message 1620 On a small network the Registrar MAY include the GRASP M_FLOOD 1621 announcements to locally connected networks. 1623 The $transport-proto above indicates the method that the pledge- 1624 proxy-registrar will use. The TCP method described here is 1625 mandatory, and other proxy methods, such as CoAP methods not defined 1626 in this document are optional. Other methods MUST NOT be enabled 1627 unless the Join Registrar ASA indicates support for them in it's own 1628 announcement. 1630 4.2. CoAP connection to Registrar 1632 The use of CoAP to connect from pledge to registrar is out of scope 1633 for this document, and is described in future work. See 1634 [I-D.ietf-anima-constrained-voucher]. 1636 4.3. Proxy discovery and communication of Registrar 1638 The registrar SHOULD announce itself so that proxies can find it and 1639 determine what kind of connections can be terminated. 1641 The registrar announces itself using ACP instance of GRASP using 1642 M_FLOOD messages. A registrar may announce any convenient port 1643 number, including using a stock port 443. ANI proxies MUST support 1644 GRASP discovery of registrars. 1646 The M_FLOOD is formatted as follows: 1648 [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, 1649 ["AN_join_registrar", 4, 255, "EST-TLS"], 1650 [O_IPv6_LOCATOR, 1651 h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]] 1653 Figure 12: An example of a Registrar announcement message 1655 The formal CDDL definition is: 1657 flood-message = [M_FLOOD, session-id, initiator, ttl, 1658 +[objective, (locator-option / [])]] 1660 objective = ["AN_join_registrar", objective-flags, loop-count, 1661 objective-value] 1663 initiator = ACP address to contact Registrar 1664 objective-flags = sync-only ; as in GRASP spec 1665 sync-only = 4 ; M_FLOOD only requires synchronization 1666 loop-count = 255 ; mandatory maximum 1667 objective-value = text ; name of the (list of) of supported 1668 ; protocols: "EST-TLS" for RFC7030. 1670 Figure 13: CDDL definition for Registrar announcement message 1672 The M_FLOOD message MUST be sent periodically. The default period 1673 SHOULD be 60 seconds, the value SHOULD be operator configurable but 1674 SHOULD NOT be smaller than 60 seconds. The frequency of sending MUST 1675 be such that the aggregate amount of periodic M_FLOODs from all 1676 flooding sources cause only negligible traffic across the ACP. 1678 Here are some examples of locators for illustrative purposes. Only 1679 the first one ($transport-protocol = 6, TCP) is defined in this 1680 document and is mandatory to implement. 1682 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1683 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1684 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1686 A protocol of 6 indicates that TCP proxying on the indicated port is 1687 desired. 1689 Registrars MUST announce the set of protocols that they support. 1690 They MUST support TCP traffic. 1692 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1694 Registrars MUST support ANI TLS circuit proxy and therefore BRSKI 1695 across HTTPS/TLS native across the ACP. 1697 In the ANI, the Autonomic Control Plane (ACP) secured instance of 1698 GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI 1699 registrar ACP addresses and ports by ANI proxies. The TCP leg of the 1700 proxy connection between ANI proxy and ANI registrar therefore also 1701 runs across the ACP. 1703 5. Protocol Details (Pledge - Registrar - MASA) 1705 The pledge MUST initiate BRSKI after boot if it is unconfigured. The 1706 pledge MUST NOT automatically initiate BRSKI if it has been 1707 configured or is in the process of being configured. 1709 BRSKI is described as extensions to EST [RFC7030]. The goal of these 1710 extensions is to reduce the number of TLS connections and crypto 1711 operations required on the pledge. The registrar implements the 1712 BRSKI REST interface within the same "/.well-known" URI tree as the 1713 existing EST URIs as described in EST [RFC7030] section 3.2.2. The 1714 communication channel between the pledge and the registrar is 1715 referred to as "BRSKI-EST" (see Figure 1). 1717 The communication channel between the registrar and MASA is similarly 1718 described as extensions to EST within the same "/.well-known" tree. 1719 For clarity this channel is referred to as "BRSKI-MASA". (See 1720 Figure 1). 1722 The MASA URI is "https://" authority "/.well-known/est". 1724 BRSKI uses existing CMS message formats for existing EST operations. 1725 BRSKI uses JSON [RFC8259] for all new operations defined here, and 1726 voucher formats. In all places where a binary value must be carried 1727 in a JSON string, the use of base64 format ([RFC4648] section 4) is 1728 to be used, as per [RFC7951] section 6.6. 1730 While EST section 3.2 does not insist upon use of HTTP persistent 1731 connections ([RFC7230] section 6.3), BRSKI-EST connections SHOULD use 1732 persistent connections. The intention of this guidance is to ensure 1733 the provisional TLS state occurs only once, and that the subsequent 1734 resolution of the provision state is not subject to a MITM attack 1735 during a critical phase. 1737 If non-persistent connections are used, then both the pledge and the 1738 registrar MUST remember the certificates seen, and also sent for the 1739 first connection. They MUST check each subsequent connections for 1740 the same certificates, and each end MUST use the same certificates as 1741 well. This places a difficult restriction on rolling certificates on 1742 the Registrar. 1744 Summarized automation extensions for the BRSKI-EST flow are: 1746 * The pledge either attempts concurrent connections via each 1747 discovered proxy, or it times out quickly and tries connections in 1748 series, as explained at the end of Section 5.1. 1750 * The pledge provisionally accepts the registrar certificate during 1751 the TLS handshake as detailed in Section 5.1. 1753 * The pledge requests a voucher using the new REST calls described 1754 below. This voucher is then validated. 1756 * The pledge completes authentication of the server certificate as 1757 detailed in Section 5.6.1. This moves the BRSKI-EST TLS 1758 connection out of the provisional state. 1760 * Mandatory bootstrap steps conclude with voucher status telemetry 1761 (see Section 5.7). 1763 The BRSKI-EST TLS connection can now be used for EST enrollment. 1765 The extensions for a registrar (equivalent to EST server) are: 1767 * Client authentication is automated using Initial Device Identity 1768 (IDevID) as per the EST certificate based client authentication. 1769 The subject field's DN encoding MUST include the "serialNumber" 1770 attribute with the device's unique serial number as explained in 1771 Section 2.3.1 1773 * The registrar requests and validates the voucher from the MASA. 1775 * The registrar forwards the voucher to the pledge when requested. 1777 * The registrar performs log verifications (described in 1778 Section 5.8.3) in addition to local authorization checks before 1779 accepting optional pledge device enrollment requests. 1781 5.1. BRSKI-EST TLS establishment details 1783 The pledge establishes the TLS connection with the registrar through 1784 the circuit proxy (see Section 4) but the TLS handshake is with the 1785 registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST 1786 registrar is the TLS server. All security associations established 1787 are between the pledge and the registrar regardless of proxy 1788 operations. 1790 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is 1791 REQUIRED on the Pledge side. TLS 1.3 (or newer) SHOULD be available 1792 on the Registrar server interface, and the Registrar client 1793 interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be 1794 available on the MASA server interface, but TLS 1.2 MAY be used. 1796 Establishment of the BRSKI-EST TLS connection is as specified in EST 1797 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1799 [RFC7030] wherein the client is authenticated with the IDevID 1800 certificate, and the EST server (the registrar) is provisionally 1801 authenticated with an unverified server certificate. Configuration 1802 or distribution of the trust anchor database used for validating the 1803 IDevID certificate is out-of-scope of this specification. Note that 1804 the trust anchors in/excluded from the database will affect which 1805 manufacturers' devices are acceptable to the registrar as pledges, 1806 and can also be used to limit the set of MASAs that are trusted for 1807 enrollment. 1809 The signatures in the certificate MUST be validated even if a signing 1810 key can not (yet) be validated. The certificate (or chain) MUST be 1811 retained for later validation. 1813 A self-signed certificate for the Registrar is acceptable as the 1814 voucher can validate it upon successful enrollment. 1816 The pledge performs input validation of all data received until a 1817 voucher is verified as specified in Section 5.6.1 and the TLS 1818 connection leaves the provisional state. Until these operations are 1819 complete the pledge could be communicating with an attacker. 1821 The pledge code needs to be written with the assumption that all data 1822 is being transmitted at this point to an unauthenticated peer, and 1823 that received data, while inside a TLS connection, MUST be considered 1824 untrusted. This particularly applies to HTTP headers and CMS 1825 structures that make up the voucher. 1827 A pledge that can connect to multiple Registrars concurrently SHOULD 1828 do so. Some devices may be unable to do so for lack of threading, or 1829 resource issues. Concurrent connections defeat attempts by a 1830 malicious proxy from causing a TCP Slowloris-like attack (see 1831 [slowloris]). 1833 A pledge that can not maintain as many connections as there are 1834 eligible proxies will need to rotate among the various choices, 1835 terminating connections that do not appear to be making progress. If 1836 no connection is making progress after 5 seconds then the pledge 1837 SHOULD drop the oldest connection and go on to a different proxy: the 1838 proxy that has been communicated with least recently. If there were 1839 no other proxies discovered, the pledge MAY continue to wait, as long 1840 as it is concurrently listening for new proxy announcements. 1842 5.2. Pledge Requests Voucher from the Registrar 1844 When the pledge bootstraps it makes a request for a voucher from a 1845 registrar. 1847 This is done with an HTTPS POST using the operation path value of 1848 "/.well-known/est/requestvoucher". 1850 The pledge voucher-request Content-Type is: 1852 application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON 1853 document that has been signed using a CMS structure", and the 1854 voucher-request described in Section 3 is created in the same way. 1855 The media type is the same as defined in [RFC8366]. This is also 1856 used for the pledge voucher-request. The pledge MUST sign the 1857 request using the Section 2.3 credential. 1859 Registrar implementations SHOULD anticipate future media types but of 1860 course will simply fail the request if those types are not yet known. 1862 The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header 1863 field indicating the acceptable media type for the voucher response. 1864 The "application/voucher-cms+json" media type is defined in [RFC8366] 1865 but constrained voucher formats are expected in the future. 1866 Registrars and MASA are expected to be flexible in what they accept. 1868 The pledge populates the voucher-request fields as follows: 1870 created-on: Pledges that have a realtime clock are RECOMMENDED to 1871 populate this field with the current date and time in yang:date- 1872 and-time format. This provides additional information to the 1873 MASA. Pledges that have no real-time clocks MAY omit this field. 1875 nonce: The pledge voucher-request MUST contain a cryptographically 1876 strong random or pseudo-random number nonce (see [RFC4086] section 1877 6.2). As the nonce is usually generated very early in the boot 1878 sequence there is a concern that the same nonce might generated 1879 across multiple boots, or after a factory reset. Different nonces 1880 MUST be generated for each bootstrapping attempt, whether in 1881 series or concurrently. The freshness of this nonce mitigates 1882 against the lack of real-time clock as explained in Section 2.6.1. 1884 assertion: The pledge indicates support for the mechanism described 1885 in this document, by putting the value "proximity" in the voucher- 1886 request, and MUST include the "proximity-registrar-cert" field 1887 (below). 1889 proximity-registrar-cert: In a pledge voucher-request this is the 1890 first certificate in the TLS server 'certificate_list' sequence 1891 (see [RFC5246]) presented by the registrar to the pledge. That 1892 is, it is the end-entity certificate. This MUST be populated in a 1893 pledge voucher-request. 1895 serial-number The serial number of the pledge is included in the 1896 voucher-request from the Pledge. This value is included as a 1897 sanity check only, but it is not to be forwarded by the Registrar 1898 as described in Section 5.5. 1900 All other fields MAY be omitted in the pledge voucher-request. 1902 An example JSON payload of a pledge voucher-request is in Section 3.3 1903 Example 1. 1905 The registrar confirms that the assertion is 'proximity' and that 1906 pinned 'proximity-registrar-cert' is the Registrar's certificate. If 1907 this validation fails, then there is an On-Path Attacker (MITM), and 1908 the connection MUST be closed after the returning an HTTP 401 error 1909 code. 1911 5.3. Registrar Authorization of Pledge 1913 In a fully automated network all devices must be securely identified 1914 and authorized to join the domain. 1916 A Registrar accepts or declines a request to join the domain, based 1917 on the authenticated identity presented. For different networks, 1918 examples of automated acceptance may include: 1920 * allow any device of a specific type (as determined by the X.509 1921 IDevID), 1923 * allow any device from a specific vendor (as determined by the 1924 X.509 IDevID), 1926 * allow a specific device from a vendor (as determined by the X.509 1927 IDevID) against a domain white list. (The mechanism for checking 1928 a shared white list potentially used by multiple Registrars is out 1929 of scope). 1931 If validation fails the registrar SHOULD respond with the HTTP 404 1932 error code. If the voucher-request is in an unknown format, then an 1933 HTTP 406 error code is more appropriate. A situation that could be 1934 resolved with administrative action (such as adding a vendor to a 1935 whitelist) MAY be responded with an 403 HTTP error code. 1937 If authorization is successful the registrar obtains a voucher from 1938 the MASA service (see Section 5.5) and returns that MASA signed 1939 voucher to the pledge as described in Section 5.6. 1941 5.4. BRSKI-MASA TLS establishment details 1943 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1944 appropriate for HTTPS REST interfaces. The registrar initiates the 1945 connection and uses the MASA URL obtained as described in 1946 Section 2.8. The mechanisms in [RFC6125] SHOULD be used in 1947 authentication of the MASA using a DNS-ID that matches that which is 1948 found in the IDevID. Registrars MAY include a mechanism to override 1949 the MASA URL on a manufacturer-by-manufacturer basis, and within that 1950 override it is appropriate to provide alternate anchors. This will 1951 typically used by some vendors to establish explicit (or private) 1952 trust anchors for validating their MASA that is part of a sales 1953 channel integration. 1955 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is 1956 REQUIRED. TLS 1.3 (or newer) SHOULD be available. 1958 As described in [RFC7030], the MASA and the registrars SHOULD be 1959 prepared to support TLS client certificate authentication and/or HTTP 1960 Basic or Digest authentication. This connection MAY also have no 1961 client authentication at all. 1963 Registrars SHOULD permit trust anchors to be pre-configured on a per- 1964 vendor(MASA) basis. Registrars SHOULD include the ability to 1965 configure a TLS ClientCertificate on a per-MASA basis, or to use no 1966 client certificate. Registrars SHOULD also permit HTTP Basic and 1967 Digest authentication to be configured. 1969 The authentication of the BRSKI-MASA connection does not change the 1970 voucher-request process, as voucher-requests are already signed by 1971 the registrar. Instead, this authentication provides access control 1972 to the audit-log as described in Section 5.8. 1974 Implementors are advised that contacting the MASA is to establish a 1975 secured API connection with a web service and that there are a number 1976 of authentication models being explored within the industry. 1977 Registrars are RECOMMENDED to fail gracefully and generate useful 1978 administrative notifications or logs in the advent of unexpected HTTP 1979 401 (Unauthorized) responses from the MASA. 1981 5.4.1. MASA authentication of customer Registrar 1983 Providing per-customer options requires that the customer's registrar 1984 be uniquely identified. This can be done by any stateless method 1985 that HTTPS supports such as with HTTP Basic or Digest authentication 1986 (that is using a password), but the use of TLS Client Certificate 1987 authentication is RECOMMENDED. 1989 Stateful methods involving API tokens, or HTTP Cookies, are not 1990 recommended. 1992 It is expected that the setup and configuration of per-customer 1993 Client Certificates is done as part of a sales ordering process. 1995 The use of public PKI (i.e. WebPKI) End-Entity Certificates to 1996 identify the Registrar is reasonable, and if done universally this 1997 would permit a MASA to identify a customers' Registrar simply by a 1998 FQDN. 2000 The use of DANE records in DNSSEC signed zones would also permit use 2001 of a FQDN to identify customer Registrars. 2003 A third (and simplest, but least flexible) mechanism would be for the 2004 MASA to simply store the Registrar's certificate pinned in a 2005 database. 2007 A MASA without any supply chain integration can simply accept 2008 Registrars without any authentication, or can accept them on a blind 2009 Trust-on-First-Use basis as described in Section 7.4.2. 2011 This document does not make a specific recommendation on how the MASA 2012 authenticates the Registrar as there are likely different tradeoffs 2013 in different environments and product values. Even within the ANIMA 2014 ACP applicability, there is a significant difference between supply 2015 chain logistics for $100 CPE devices and $100,000 core routers. 2017 5.5. Registrar Requests Voucher from MASA 2019 When a registrar receives a pledge voucher-request it in turn submits 2020 a registrar voucher-request to the MASA service via an HTTPS 2021 interface ([RFC7231]). 2023 This is done with an HTTP POST using the operation path value of 2024 "/.well-known/est/requestvoucher". 2026 The voucher media type "application/voucher-cms+json" is defined in 2027 [RFC8366] and is also used for the registrar voucher-request. It is 2028 a JSON document that has been signed using a CMS structure. The 2029 registrar MUST sign the registrar voucher-request. The entire 2030 registrar certificate chain, up to and including the Domain CA, MUST 2031 be included in the CMS structure. 2033 MASA impementations SHOULD anticipate future media types but of 2034 course will simply fail the request if those types are not yet known. 2036 The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" 2037 header field indicating the response media types that are acceptable. 2038 This list SHOULD be the entire list presented to the Registrar in the 2039 Pledge's original request (see Section 5.2) but MAY be a subset. 2040 MASA's are expected to be flexible in what they accept. 2042 The registrar populates the voucher-request fields as follows: 2044 created-on: The Registrars SHOULD populate this field with the 2045 current date and time when the Registrar formed this voucher 2046 request. This field provides additional information to the MASA. 2048 nonce: This value, if present, is copied from the pledge voucher- 2049 request. The registrar voucher-request MAY omit the nonce as per 2050 Section 3.1. 2052 serial-number: The serial number of the pledge the registrar would 2053 like a voucher for. The registrar determines this value by 2054 parsing the authenticated pledge IDevID certificate. See 2055 Section 2.3. The registrar MUST verify that the serial number 2056 field it parsed matches the serial number field the pledge 2057 provided in its voucher-request. This provides a sanity check 2058 useful for detecting error conditions and logging. The registrar 2059 MUST NOT simply copy the serial number field from a pledge voucher 2060 request as that field is claimed but not certified. 2062 idevid-issuer: The Issuer value from the pledge IDevID certificate 2063 is included to ensure unique interpretation of the serial-number. 2064 In the case of nonceless (offline) voucher-request, then an 2065 appropriate value needs to be configured from the same out-of-band 2066 source as the serial-number. 2068 prior-signed-voucher-request: The signed pledge voucher-request 2069 SHOULD be included in the registrar voucher-request. The entire 2070 CMS signed structure is to be included, base64 encoded for 2071 transport in the JSON structure. 2073 A nonceless registrar voucher-request MAY be submitted to the MASA. 2074 Doing so allows the registrar to request a voucher when the pledge is 2075 offline, or when the registrar anticipates not being able to connect 2076 to the MASA while the pledge is being deployed. Some use cases 2077 require the registrar to learn the appropriate IDevID SerialNumber 2078 field and appropriate 'Accept header field' values from the physical 2079 device labeling or from the sales channel (out-of-scope for this 2080 document). 2082 All other fields MAY be omitted in the registrar voucher-request. 2084 The "proximity-registrar-cert" field MUST NOT be present in the 2085 registrar voucher-request. 2087 Example JSON payloads of registrar voucher-requests are in 2088 Section 3.3 Examples 2 through 4. 2090 The MASA verifies that the registrar voucher-request is internally 2091 consistent but does not necessarily authenticate the registrar 2092 certificate since the registrar MAY be unknown to the MASA in 2093 advance. The MASA performs the actions and validation checks 2094 described in the following sub-sections before issuing a voucher. 2096 5.5.1. MASA renewal of expired vouchers 2098 As described in [RFC8366] vouchers are normally short lived to avoid 2099 revocation issues. If the request is for a previous (expired) 2100 voucher using the same registrar (that is, a Registrar with the same 2101 Domain CA) then the request for a renewed voucher SHOULD be 2102 automatically authorized. The MASA has sufficient information to 2103 determine this by examining the request, the registrar 2104 authentication, and the existing audit-log. The issuance of a 2105 renewed voucher is logged as detailed in Section 5.6. 2107 To inform the MASA that existing vouchers are not to be renewed one 2108 can update or revoke the registrar credentials used to authorize the 2109 request (see Section 5.5.4 and Section 5.5.3). More flexible methods 2110 will likely involve sales channel integration and authorizations 2111 (details are out-of-scope of this document). 2113 5.5.2. MASA pinning of registrar 2115 The registrar's certificate chain is extracted from the signature 2116 method. The entire registrar certificate chain was included in the 2117 CMS structure, as specified in Section 5.5. This CA certificate will 2118 be used to populate the "pinned-domain-cert" of the voucher being 2119 issued. 2121 If this domain CA is unknown to the MASA, then it is to be considered 2122 a temporary trust anchor for the rest of the steps in this section. 2123 The intention is not to authenticate the message as having come from 2124 a fully validated origin, but to establish the consistency of the 2125 domain PKI. 2127 5.5.3. MASA checking of voucher request signature 2129 As described in Section 5.5.2, the MASA has extracted Registrar's 2130 domain CA. This is used to validate the CMS signature ([RFC5652]) on 2131 the voucher-request. 2133 Normal PKIX revocation checking is assumed during voucher-request 2134 signature validation. This CA certificate MAY have Certificate 2135 Revocation List distribution points, or Online Certificate Status 2136 Protocol (OCSP) information ([RFC6960]). If they are present, the 2137 MASA MUST be able to reach the relevant servers belonging to the 2138 Registrar's domain CA to perform the revocation checks. 2140 The use of OCSP Stapling is preferred. 2142 5.5.4. MASA verification of domain registrar 2144 The MASA MUST verify that the registrar voucher-request is signed by 2145 a registrar. This is confirmed by verifying that the id-kp-cmcRA 2146 extended key usage extension field (as detailed in EST RFC7030 2147 section 3.6.1) exists in the certificate of the entity that signed 2148 the registrar voucher-request. This verification is only a 2149 consistency check that the unauthenticated domain CA intended the 2150 voucher-request signer to be a registrar. Performing this check 2151 provides value to the domain PKI by assuring the domain administrator 2152 that the MASA service will only respect claims from authorized 2153 Registration Authorities of the domain. 2155 Even when a domain CA is authenticated to the MASA, and there is 2156 strong sales channel integration to understand who the legitimate 2157 owner is, the above cmcRC check prevents arbitrary End-Entity 2158 certificates (such as an LDevID certificate) from having vouchers 2159 issued against them. 2161 Other cases of inappropriate voucher issuance are detected by 2162 examination of the audit log. 2164 If a nonceless voucher-request is submitted the MASA MUST 2165 authenticate the registrar as described in either EST [RFC7030] 2166 section 3.2.3, section 3.3.2, or by validating the registrar's 2167 certificate used to sign the registrar voucher-request using a 2168 configured trust anchor. Any of these methods reduce the risk of 2169 DDoS attacks and provide an authenticated identity as an input to 2170 sales channel integration and authorizations (details are out-of- 2171 scope of this document). 2173 In the nonced case, validation of the Registrar's identity (via TLS 2174 Client Certificate or HTTP authentication) MAY be omitted if the 2175 device policy is to accept audit-only vouchers. 2177 5.5.5. MASA verification of pledge prior-signed-voucher-request 2179 The MASA MAY verify that the registrar voucher-request includes the 2180 'prior-signed-voucher-request' field. If so the prior-signed- 2181 voucher-request MUST include a 'proximity-registrar-cert' that is 2182 consistent with the certificate used to sign the registrar voucher- 2183 request. Additionally the voucher-request serial-number leaf MUST 2184 match the pledge serial-number that the MASA extracts from the 2185 signing certificate of the prior-signed-voucher-request. The 2186 consistency check described above is checking that the 'proximity- 2187 registrar-cert' SPKI fingerprint exists within the registrar voucher- 2188 request CMS signature's certificate chain. This is substantially the 2189 same as the pin validation described in in [RFC7469] section 2.6, 2190 paragraph three. 2192 If these checks succeed the MASA updates the voucher and audit-log 2193 assertion leafs with the "proximity" assertion, as defined by 2194 [RFC8366] section 5.3. 2196 5.5.6. MASA nonce handling 2198 The MASA does not verify the nonce itself. If the registrar voucher- 2199 request contains a nonce, and the prior-signed-voucher-request 2200 exists, then the MASA MUST verify that the nonce is consistent. 2201 (Recall from above that the voucher-request might not contain a 2202 nonce, see Section 5.5 and Section 5.5.4). 2204 The MASA populates the audit-log with the nonce that was verified. 2205 If a nonceless voucher is issued, then the audit-log is to be 2206 populated with the JSON value "null". 2208 5.6. MASA and Registrar Voucher Response 2210 The MASA voucher response to the registrar is forwarded without 2211 changes to the pledge; therefore this section applies to both the 2212 MASA and the registrar. The HTTP signaling described applies to both 2213 the MASA and registrar responses. 2215 When a voucher request arrives at the registrar, if it has a cached 2216 response from the MASA for the corresponding registrar voucher- 2217 request, that cached response can be used according to local policy; 2218 otherwise the registrar constructs a new registrar voucher-request 2219 and sends it to the MASA. 2221 Registrar evaluation of the voucher itself is purely for transparency 2222 and audit purposes to further inform log verification (see 2223 Section 5.8.3) and therefore a registrar could accept future voucher 2224 formats that are opaque to the registrar. 2226 If the voucher-request is successful, the server (MASA responding to 2227 registrar or registrar responding to pledge) response MUST contain an 2228 HTTP 200 response code. The server MUST answer with a suitable 4xx 2229 or 5xx HTTP [RFC7230] error code when a problem occurs. In this 2230 case, the response data from the MASA MUST be a plaintext human- 2231 readable (UTF-8) error message containing explanatory information 2232 describing why the request was rejected. 2234 The registrar MAY respond with an HTTP 202 ("the request has been 2235 accepted for processing, but the processing has not been completed") 2236 as described in EST [RFC7030] section 4.2.3 wherein the client "MUST 2237 wait at least the specified 'Retry-After' time before repeating the 2238 same request". (see [RFC7231] section 6.6.4) The pledge is 2239 RECOMMENDED to provide local feedback (blinked LED etc) during this 2240 wait cycle if mechanisms for this are available. To prevent an 2241 attacker registrar from significantly delaying bootstrapping the 2242 pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the 2243 pledge would keep track of the appropriate Retry-After header field 2244 values for any number of outstanding registrars but this would 2245 involve a state table on the pledge. Instead the pledge MAY ignore 2246 the exact Retry-After value in favor of a single hard coded value (a 2247 registrar that is unable to complete the transaction after the first 2248 60 seconds has another chance a minute later). A pledge SHOULD only 2249 maintain a 202 retry-state for up to 4 days, which is longer than a 2250 long weekend, after which time the enrollment attempt fails and the 2251 pledge returns to discovery state. 2253 A pledge that retries a request after receiving a 202 message MUST 2254 resend the same voucher-request. It MUST NOT sign a new voucher- 2255 request each time, and in particular, it MUST NOT change the nonce 2256 value. 2258 In order to avoid infinite redirect loops, which a malicious 2259 registrar might do in order to keep the pledge from discovering the 2260 correct registrar, the pledge MUST NOT follow more than one 2261 redirection (3xx code) to another web origins. EST supports 2262 redirection but requires user input; this change allows the pledge to 2263 follow a single redirection without a user interaction. 2265 A 403 (Forbidden) response is appropriate if the voucher-request is 2266 not signed correctly, stale, or if the pledge has another outstanding 2267 voucher that cannot be overridden. 2269 A 404 (Not Found) response is appropriate when the request is for a 2270 device that is not known to the MASA. 2272 A 406 (Not Acceptable) response is appropriate if a voucher of the 2273 desired type or using the desired algorithms (as indicated by the 2274 Accept: header fields, and algorithms used in the signature) cannot 2275 be issued such as because the MASA knows the pledge cannot process 2276 that type. The registrar SHOULD use this response if it determines 2277 the pledge is unacceptable due to inventory control, MASA audit-logs, 2278 or any other reason. 2280 A 415 (Unsupported Media Type) response is appropriate for a request 2281 that has a voucher-request or Accept: value that is not understood. 2283 The voucher response format is as indicated in the submitted Accept 2284 header fields or based on the MASA's prior understanding of proper 2285 format for this Pledge. Only the [RFC8366] "application/voucher- 2286 cms+json" media type is defined at this time. The syntactic details 2287 of vouchers are described in detail in [RFC8366]. Figure 14 shows a 2288 sample of the contents of a voucher. 2290 { 2291 "ietf-voucher:voucher": { 2292 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 2293 "assertion": "logged", 2294 "pinned-domain-cert": "base64encodedvalue==", 2295 "serial-number": "JADA123456789" 2296 } 2297 } 2299 Figure 14: An example voucher 2301 The MASA populates the voucher fields as follows: 2303 nonce: The nonce from the pledge if available. See Section 5.5.6. 2305 assertion: The method used to verify the relationship between pledge 2306 and registrar. See Section 5.5.5. 2308 pinned-domain-cert: The domain CA cert. See Section 5.5.2. This 2309 figure is illustrative, for an example, see Appendix C.2 2311 serial-number: The serial-number as provided in the voucher-request. 2312 Also see Section 5.5.5. 2314 domain-cert-revocation-checks: Set as appropriate for the pledge's 2315 capabilities and as documented in [RFC8366]. The MASA MAY set 2316 this field to 'false' since setting it to 'true' would require 2317 that revocation information be available to the pledge and this 2318 document does not make normative requirements for [RFC6961] or 2319 equivalent integrations. 2321 expires-on: This is set for nonceless vouchers. The MASA ensures 2322 the voucher lifetime is consistent with any revocation or pinned- 2323 domain-cert consistency checks the pledge might perform. See 2324 section Section 2.6.1. There are three times to consider: (a) a 2325 configured voucher lifetime in the MASA, (b) the expiry time for 2326 the registrar's certificate, (c) any certificate revocation 2327 information (CRL) lifetime. The expires-on field SHOULD be before 2328 the earliest of these three values. Typically (b) will be some 2329 significant time in the future, but (c) will typically be short 2330 (on the order of a week or less). The RECOMMENDED period for (a) 2331 is on the order of 20 minutes, so it will typically determine the 2332 lifespan of the resulting voucher. 20 minutes is sufficient time 2333 to reach the post-provisional state in the pledge, at which point 2334 there is an established trust relationship between pledge and 2335 registrar. The subsequent operations can take as long as required 2336 from that point onwards. The lifetime of the voucher has no 2337 impact on the lifespan of the ownership relationship. 2339 Whenever a voucher is issued the MASA MUST update the audit-log 2340 sufficiently to generate the response as described in Section 5.8.1. 2341 The internal state requirements to maintain the audit-log are out-of- 2342 scope. 2344 5.6.1. Pledge voucher verification 2346 The pledge MUST verify the voucher signature using the manufacturer- 2347 installed trust anchor(s) associated with the manufacturer's MASA 2348 (this is likely included in the pledge's firmware). Management of 2349 the manufacturer-installed trust anchor(s) is out-of-scope of this 2350 document; this protocol does not update these trust anchor(s). 2352 The pledge MUST verify the serial-number field of the signed voucher 2353 matches the pledge's own serial-number. 2355 The pledge MUST verify the nonce information in the voucher. If 2356 present, the nonce in the voucher must match the nonce the pledge 2357 submitted to the registrar; vouchers with no nonce can also be 2358 accepted (according to local policy, see Section 7.2. 2360 The pledge MUST be prepared to parse and fail gracefully from a 2361 voucher response that does not contain a 'pinned-domain-cert' field. 2362 Such a thing indicates a failure to enroll in this domain, and the 2363 pledge MUST attempt joining with other available Join Proxy. 2365 The pledge MUST be prepared to ignore additional fields that it does 2366 not recognize. 2368 5.6.2. Pledge authentication of provisional TLS connection 2370 The 'pinned-domain-cert' element of the voucher contains the domain 2371 CA's public key. The pledge MUST use the 'pinned-domain-cert' trust 2372 anchor to immediately complete authentication of the provisional TLS 2373 connection. 2375 If a registrar's credentials cannot be verified using the pinned- 2376 domain-cert trust anchor from the voucher then the TLS connection is 2377 immediately discarded and the pledge abandons attempts to bootstrap 2378 with this discovered registrar. The pledge SHOULD send voucher 2379 status telemetry (described below) before closing the TLS connection. 2380 The pledge MUST attempt to enroll using any other proxies it has 2381 found. It SHOULD return to the same proxy again after unsuccessful 2382 attempts with other proxies. Attempts should be made repeated at 2383 intervals according to the backoff timer described earlier. Attempts 2384 SHOULD be repeated as failure may be the result of a temporary 2385 inconsistency (an inconsistently rolled registrar key, or some other 2386 mis-configuration). The inconsistency could also be the result an 2387 active MITM attack on the EST connection. 2389 The registrar MUST use a certificate that chains to the pinned- 2390 domain-cert as its TLS server certificate. 2392 The pledge's PKIX path validation of a registrar certificate's 2393 validity period information is as described in Section 2.6.1. Once 2394 the PKIX path validation is successful the TLS connection is no 2395 longer provisional. 2397 The pinned-domain-cert MAY be installed as an trust anchor for future 2398 operations such as enrollment (e.g. [RFC7030] as recommended) or 2399 trust anchor management or raw protocols that do not need full PKI 2400 based key management. It can be used to authenticate any dynamically 2401 discovered EST server that contain the id-kp-cmcRA extended key usage 2402 extension as detailed in EST RFC7030 section 3.6.1; but to reduce 2403 system complexity the pledge SHOULD avoid additional discovery 2404 operations. Instead the pledge SHOULD communicate directly with the 2405 registrar as the EST server. The 'pinned-domain-cert' is not a 2406 complete distribution of the [RFC7030] section 4.1.3 CA Certificate 2407 Response, which is an additional justification for the recommendation 2408 to proceed with EST key management operations. Once a full CA 2409 Certificate Response is obtained it is more authoritative for the 2410 domain than the limited 'pinned-domain-cert' response. 2412 5.7. Pledge BRSKI Status Telemetry 2414 The domain is expected to provide indications to the system 2415 administrators concerning device lifecycle status. To facilitate 2416 this it needs telemetry information concerning the device's status. 2418 To indicate pledge status regarding the voucher, the pledge MUST post 2419 a status message to the Registrar. 2421 The posted data media type: application/json 2423 The client sends an HTTP POST to the server at the URI ".well- 2424 known/est/voucher_status". 2426 The format and semantics described below are for version 1. A 2427 version field is included to permit significant changes to this 2428 feedback in the future. A Registrar that receives a status message 2429 with a version larger than it knows about SHOULD log the contents and 2430 alert a human. 2432 The Status field indicates if the voucher was acceptable. Boolean 2433 values are acceptable, where "true" indicates the voucher was 2434 acceptable. 2436 If the voucher was not acceptable the Reason string indicates why. 2437 In the failure case this message may be sent to an unauthenticated, 2438 potentially malicious registrar and therefore the Reason string 2439 SHOULD NOT provide information beneficial to an attacker. The 2440 operational benefit of this telemetry information is balanced against 2441 the operational costs of not recording that an voucher was ignored by 2442 a client the registrar expected to continue joining the domain. 2444 The reason-context attribute is an arbitrary JSON object (literal 2445 value or hash of values) which provides additional information 2446 specific to this pledge. The contents of this field are not subject 2447 to standardization. 2449 The version and status fields MUST be present. The Reason field 2450 SHOULD be present whenever the status field is false. The Reason- 2451 Context field is optional. 2453 The keys to this JSON object are case-sensitive and MUST be 2454 lowercase. Figure 15 shows an example JSON. 2456 { 2457 "version":"1", 2458 "status":false, 2459 "reason":"Informative human readable message", 2460 "reason-context": { "additional" : "JSON" } 2461 } 2463 Figure 15: Example Status Telemetry 2465 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2466 an HTTP 404 error. The client ignores any response. Within the 2467 server logs the server SHOULD capture this telemetry information. 2469 Additional standard JSON fields in this POST MAY be added, see 2470 Section 8.5. A server that sees unknown fields should log them, but 2471 otherwise ignore them. 2473 5.8. Registrar audit-log request 2475 After receiving the pledge status telemetry Section 5.7, the 2476 registrar SHOULD request the MASA audit-log from the MASA service. 2478 This is done with an HTTP POST using the operation path value of 2479 "/.well-known/est/requestauditlog". 2481 The registrar SHOULD HTTP POST the same registrar voucher-request as 2482 it did when requesting a voucher (using the same Content-Type). It 2483 is posted to the /requestauditlog URI instead. The "idevid-issuer" 2484 and "serial-number" informs the MASA which log is requested so the 2485 appropriate log can be prepared for the response. Using the same 2486 media type and message minimizes cryptographic and message operations 2487 although it results in additional network traffic. The relying MASA 2488 implementation MAY leverage internal state to associate this request 2489 with the original, and by now already validated, voucher-request so 2490 as to avoid an extra crypto validation. 2492 A registrar MAY request logs at future times. If the registrar 2493 generates a new request then the MASA is forced to perform the 2494 additional cryptographic operations to verify the new request. 2496 A MASA that receives a request for a device that does not exist, or 2497 for which the requesting owner was never an owner returns an HTTP 404 2498 ("Not found") code. 2500 It is reasonable for a Registrar, that the MASA does not believe to 2501 be the current owner, to request the audit-log. There are probably 2502 reasons for this which are hard to predict in advance. For instance, 2503 such a registrar may not be aware that the device has been resold; it 2504 may be that the device has been resold inappropriately, and this is 2505 how the original owner will learn of the occurance. It is also 2506 possible that the device legitimately spends time in two different 2507 networks. 2509 Rather than returning the audit-log as a response to the POST (with a 2510 return code 200), the MASA MAY instead return a 201 ("Created") 2511 response ([RFC7231] sections 6.3.2 and 7.1), with the URL to the 2512 prepared (and idempotent, therefore cachable) audit response in the 2513 Location: header field. 2515 In order to avoid enumeration of device audit-logs, MASA that return 2516 URLs SHOULD take care to make the returned URL unguessable. 2517 [W3C.WD-capability-urls-20140218] provides very good additional 2518 guidance. For instance, rather than returning URLs containing a 2519 database number such as https://example.com/auditlog/1234 or the EUI 2520 of the device such https://example.com/auditlog/10-00-00-11-22-33, 2521 the MASA SHOULD return a randomly generated value (a "slug" in web 2522 parlance). The value is used to find the relevant database entry. 2524 A MASA that returns a code 200 MAY also include a Location: header 2525 for future reference by the registrar. 2527 5.8.1. MASA audit log response 2529 A log data file is returned consisting of all log entries associated 2530 with the device selected by the IDevID presented in the request. The 2531 audit log may be abridged by removal of old or repeated values as 2532 explained below. The returned data is in JSON format ([RFC8259]), 2533 and the Content-Type SHOULD be "application/json". 2535 The following CDDL ([RFC8610]) explains the structure of the JSON 2536 format audit-log response: 2538 audit-log-response = { 2539 "version": uint, 2540 "events": [ + event ] 2541 "truncation": { 2542 ? "nonced duplicates": uint, 2543 ? "nonceless duplicates": uint, 2544 ? "arbitrary": uint, 2545 } 2546 } 2548 event = { 2549 "date": text, 2550 "domainID": text, 2551 "nonce": text / null, 2552 "assertion": "verified" / "logged" / "proximity", 2553 ? "truncated": uint, 2554 } 2556 Figure 16: CDDL for audit-log response 2558 An example: 2560 { 2561 "version":"1", 2562 "events":[ 2563 { 2564 "date":"2019-05-15T17:25:55.644-04:00", 2565 "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", 2566 "nonce":"VOUFT-WwrEv0NuAQEHoV7Q", 2567 "assertion":"proximity", 2568 "truncated":"0" 2569 }, 2570 { 2571 "date":"2017-05-15T17:25:55.644-04:00", 2572 "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", 2573 "nonce":"f4G6Vi1t8nKo/FieCVgpBg==", 2574 "assertion":"proximity" 2575 } 2576 ], 2577 "truncation": { 2578 "nonced duplicates": "0", 2579 "nonceless duplicates": "1", 2580 "arbitrary": "2" 2581 } 2582 } 2584 Figure 17: Example of audit-log response 2586 The domainID is a binary SubjectKeyIdentifier value calculated 2587 according to Section 5.8.2. It is encoded once in base64 in order to 2588 be transported in this JSON container. 2590 The date is in [RFC3339] format, which is consistent with typical 2591 JavaScript usage of JSON. 2593 The truncation structure MAY be omitted if all values are zero. Any 2594 counter missing from the truncation structure is the be assumed to be 2595 zero. 2597 The nonce is a string, as provided in the voucher-request, and used 2598 in the voucher. If no nonce was placed in the resulting voucher, 2599 then a value of null SHOULD be used in preference to omitting the 2600 entry. While the nonce is often created as a base64 encoded random 2601 series of bytes, this should not be assumed. 2603 Distribution of a large log is less than ideal. This structure can 2604 be optimized as follows: Nonced or Nonceless entries for the same 2605 domainID MAY be abridged from the log leaving only the single most 2606 recent nonced or nonceless entry for that domainID. In the case of 2607 truncation the 'event' truncation value SHOULD contain a count of the 2608 number of events for this domainID that were omitted. The log SHOULD 2609 NOT be further reduced but there could exist operational situation 2610 where maintaining the full log is not possible. In such situations 2611 the log MAY be arbitrarily abridged for length, with the number of 2612 removed entries indicated as 'arbitrary'. 2614 If the truncation count exceeds 1024 then the MASA MAY use this value 2615 without further incrementing it. 2617 A log where duplicate entries for the same domain have been omitted 2618 ("nonced duplicates" and/or "nonceless duplicates) could still be 2619 acceptable for informed decisions. A log that has had "arbitrary" 2620 truncations is less acceptable but manufacturer transparency is 2621 better than hidden truncations. 2623 A registrar that sees a version value greater than 1 indicates an 2624 audit log format that has been enhanced with additional information. 2625 No information will be removed in future versions; should an 2626 incompatible change be desired in the future, then a new HTTP end 2627 point will be used. 2629 This document specifies a simple log format as provided by the MASA 2630 service to the registrar. This format could be improved by 2631 distributed consensus technologies that integrate vouchers with 2632 technologies such as block-chain or hash trees or optimized logging 2633 approaches. Doing so is out of the scope of this document but is an 2634 anticipated improvement for future work. As such, the registrar 2635 SHOULD anticipate new kinds of responses, and SHOULD provide operator 2636 controls to indicate how to process unknown responses. 2638 5.8.2. Calculation of domainID 2640 The domainID is a binary value (a BIT STRING) that uniquely 2641 identifies a Registrar by the "pinned-domain-cert" 2643 If the "pinned-domain-cert" certificate includes the 2644 SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be 2645 used as the domainID. If not, the SPKI Fingerprint as described in 2646 [RFC7469] section 2.4 is to be used. This value needs to be 2647 calculated by both MASA (to populate the audit-log), and by the 2648 Registrar (to recognize itself in the audit log). 2650 [RFC5280] section 4.2.1.2 does not mandate that the 2651 SubjectKeyIdentifier extension be present in non-CA certificates. It 2652 is RECOMMENDED that Registrar certificates (even if self-signed), 2653 always include the SubjectKeyIdentifier to be used as a domainID. 2655 The domainID is determined from the certificate chain associated with 2656 the pinned-domain-cert and is used to update the audit-log. 2658 5.8.3. Registrar audit log verification 2660 Each time the Manufacturer Authorized Signing Authority (MASA) issues 2661 a voucher, it appends details of the assignment to an internal audit 2662 log for that device. The internal audit log is processed when 2663 responding to requests for details as described in Section 5.8. The 2664 contents of the audit log can express a variety of trust levels, and 2665 this section explains what kind of trust a registrar can derive from 2666 the entries. 2668 While the audit log provides a list of vouchers that were issued by 2669 the MASA, the vouchers are issued in response to voucher-requests, 2670 and it is the contents of the voucher-requests which determines how 2671 meaningful the audit log entries are. 2673 A registrar SHOULD use the log information to make an informed 2674 decision regarding the continued bootstrapping of the pledge. The 2675 exact policy is out of scope of this document as it depends on the 2676 security requirements within the registrar domain. Equipment that is 2677 purchased pre-owned can be expected to have an extensive history. 2678 The following discussion is provided to help explain the value of 2679 each log element: 2681 date: The date field provides the registrar an opportunity to divide 2682 the log around known events such as the purchase date. Depending 2683 on context known to the registrar or administrator events before/ 2684 after certain dates can have different levels of importance. For 2685 example for equipment that is expected to be new, and thus have no 2686 history, it would be a surprise to find prior entries. 2688 domainID: If the log includes an unexpected domainID then the pledge 2689 could have imprinted on an unexpected domain. The registrar can 2690 be expected to use a variety of techniques to define "unexpected" 2691 ranging from white lists of prior domains to anomaly detection 2692 (e.g. "this device was previously bound to a different domain than 2693 any other device deployed"). Log entries can also be compared 2694 against local history logs in search of discrepancies (e.g. "this 2695 device was re-deployed some number of times internally but the 2696 external audit log shows additional re-deployments our internal 2697 logs are unaware of"). 2699 nonce: Nonceless entries mean the logged domainID could 2700 theoretically trigger a reset of the pledge and then take over 2701 management by using the existing nonceless voucher. 2703 assertion: The assertion leaf in the voucher and audit log indicates 2704 why the MASA issued the voucher. A "verified" entry means that 2705 the MASA issued the associated voucher as a result of positive 2706 verification of ownership. However, this entry does not indicate 2707 whether the pledge was actually deployed in the prior domain, or 2708 not. A "logged" assertion informs the registrar that the prior 2709 vouchers were issued with minimal verification. A "proximity" 2710 assertion assures the registrar that the pledge was truly 2711 communicating with the prior domain and thus provides assurance 2712 that the prior domain really has deployed the pledge. 2714 A relatively simple policy is to white list known (internal or 2715 external) domainIDs, and require all vouchers to have a nonce. An 2716 alternative is to require that all nonceless vouchers be from a 2717 subset (e.g. only internal) of domainIDs. If the policy is violated 2718 a simple action is to revoke any locally issued credentials for the 2719 pledge in question or to refuse to forward the voucher. The 2720 Registrar MUST then refuse any EST actions, and SHOULD inform a human 2721 via a log. A registrar MAY be configured to ignore (i.e. override 2722 the above policy) the history of the device but it is RECOMMENDED 2723 that this only be configured if hardware assisted (i.e. TPM 2724 anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported. 2726 5.9. EST Integration for PKI bootstrapping 2728 The pledge SHOULD follow the BRSKI operations with EST enrollment 2729 operations including "CA Certificates Request", "CSR Attributes" and 2730 "Client Certificate Request" or "Server-Side Key Generation", etc. 2731 This is a relatively seamless integration since BRSKI API calls 2732 provide an automated alternative to the manual bootstrapping method 2733 described in [RFC7030]. As noted above, use of HTTP persistent 2734 connections simplifies the pledge state machine. 2736 Although EST allows clients to obtain multiple certificates by 2737 sending multiple Certificate Signing Requests (CSR) requests, BRSKI 2738 does not support this mechanism directly. This is because BRSKI 2739 pledges MUST use the CSR Attributes request ([RFC7030] section 4.5). 2740 The registrar MUST validate the CSR against the expected attributes. 2741 This implies that client requests will "look the same" and therefore 2742 result in a single logical certificate being issued even if the 2743 client were to make multiple requests. Registrars MAY contain more 2744 complex logic but doing so is out-of-scope of this specification. 2745 BRSKI does not signal any enhancement or restriction to this 2746 capability. 2748 5.9.1. EST Distribution of CA Certificates 2750 The pledge SHOULD request the full EST Distribution of CA 2751 Certificates message. See RFC7030, section 4.1. 2753 This ensures that the pledge has the complete set of current CA 2754 certificates beyond the pinned-domain-cert (see Section 5.6.2 for a 2755 discussion of the limitations inherent in having a single certificate 2756 instead of a full CA Certificates response.) Although these 2757 limitations are acceptable during initial bootstrapping, they are not 2758 appropriate for ongoing PKIX end entity certificate validation. 2760 5.9.2. EST CSR Attributes 2762 Automated bootstrapping occurs without local administrative 2763 configuration of the pledge. In some deployments it is plausible 2764 that the pledge generates a certificate request containing only 2765 identity information known to the pledge (essentially the X.509 2766 IDevID information) and ultimately receives a certificate containing 2767 domain specific identity information. Conceptually the CA has 2768 complete control over all fields issued in the end entity 2769 certificate. Realistically this is operationally difficult with the 2770 current status of PKI certificate authority deployments, where the 2771 CSR is submitted to the CA via a number of non-standard protocols. 2772 Even with all standardized protocols used, it could operationally be 2773 problematic to expect that service specific certificate fields can be 2774 created by a CA that is likely operated by a group that has no 2775 insight into different network services/protocols used. For example, 2776 the CA could even be outsourced. 2778 To alleviate these operational difficulties, the pledge MUST request 2779 the EST "CSR Attributes" from the EST server and the EST server needs 2780 to be able to reply with the attributes necessary for use of the 2781 certificate in its intended protocols/services. This approach allows 2782 for minimal CA integrations and instead the local infrastructure (EST 2783 server) informs the pledge of the proper fields to include in the 2784 generated CSR (such as rfc822Name). This approach is beneficial to 2785 automated bootstrapping in the widest number of environments. 2787 In networks using the BRSKI enrolled certificate to authenticate the 2788 ACP (Autonomic Control Plane), the EST CSR attributes MUST include 2789 the ACP Domain Information Fields defined in 2790 [I-D.ietf-anima-autonomic-control-plane] section 6.1.1. 2792 The registrar MUST also confirm that the resulting CSR is formatted 2793 as indicated before forwarding the request to a CA. If the registrar 2794 is communicating with the CA using a protocol such as full CMC, which 2795 provides mechanisms to override the CSR attributes, then these 2796 mechanisms MAY be used even if the client ignores CSR Attribute 2797 guidance. 2799 5.9.3. EST Client Certificate Request 2801 The pledge MUST request a new client certificate. See RFC7030, 2802 section 4.2. 2804 5.9.4. Enrollment Status Telemetry 2806 For automated bootstrapping of devices, the administrative elements 2807 providing bootstrapping also provide indications to the system 2808 administrators concerning device lifecycle status. This might 2809 include information concerning attempted bootstrapping messages seen 2810 by the client. The MASA provides logs and status of credential 2811 enrollment. [RFC7030] assumes an end user and therefore does not 2812 include a final success indication back to the server. This is 2813 insufficient for automated use cases. 2815 In order to communicate this indicator, the client HTTP POSTs a JSON 2816 dictionary with a number of attributes described below to the new EST 2817 endpoint at "/.well-known/est/enrollstatus". 2819 When indicating a successful enrollment the client SHOULD first re- 2820 establish the EST TLS session using the newly obtained credentials. 2821 TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The 2822 client SHOULD therefore always close the existing TLS connection, and 2823 start a new one. 2825 In the case of a failed enrollment, the client MUST send the 2826 telemetry information over the same TLS connection that was used for 2827 the enrollment attempt, with a Reason string indicating why the most 2828 recent enrollment failed. (For failed attempts, the TLS connection 2829 is the most reliable way to correlate server-side information with 2830 what the client provides.) 2832 The reason-context attribute is an arbitrary JSON object (literal 2833 value or hash of values) which provides additional information 2834 specific to the failure to unroll from this pledge. The contents of 2835 this field are not subject to standardization. This is represented 2836 by the group-socket "$$arbitrary-map" in the CDDL. 2838 In the case of a SUCCESS the Reason string is omitted. 2840 enrollstatus-post = { 2841 "version": uint, 2842 "status": bool, 2843 "reason": text, 2844 ? "reason-context" : { $$arbitrary-map } 2845 } 2846 } 2848 Figure 18: CDDL for enrollment status POST 2850 An example status report can be seen below. It is sent with with the 2851 media type: application/json 2853 { 2854 "version":"1", 2855 "status":true, 2856 "reason":"Informative human readable message", 2857 "reason-context": { "additional" : "JSON" } 2858 } 2860 Figure 19: Example of enrollment status POST 2862 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2863 an HTTP 404 error. 2865 Within the server logs the server MUST capture if this message was 2866 received over an TLS session with a matching client certificate. 2868 5.9.5. Multiple certificates 2870 Pledges that require multiple certificates could establish direct EST 2871 connections to the registrar. 2873 5.9.6. EST over CoAP 2875 This document describes extensions to EST for the purposes of 2876 bootstrapping of remote key infrastructures. Bootstrapping is 2877 relevant for CoAP enrollment discussions as well. The definition of 2878 EST and BRSKI over CoAP is not discussed within this document beyond 2879 ensuring proxy support for CoAP operations. Instead it is 2880 anticipated that a definition of CoAP mappings will occur in 2881 subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP 2882 mappings for BRSKI will be discussed either there or in future work. 2884 6. Clarification of transfer-encoding 2886 [RFC7030] defines its endpoints to include a "Content-Transfer- 2887 Encoding" heading, and the payloads to be [RFC4648] Base64 encoded 2888 DER. 2890 When used within BRSKI, the original RFC7030 EST endpoints remain 2891 Base64 encoded, but the new BRSKI end points which send and receive 2892 binary artifacts (specifically, "/.well-known/est/requestvoucher") 2893 are binary. That is, no encoding is used. 2895 In the BRSKI context, the EST "Content-Transfer-Encoding" header 2896 field if present, SHOULD be ignored. This header field does not need 2897 to be included. 2899 7. Reduced security operational modes 2901 A common requirement of bootstrapping is to support less secure 2902 operational modes for support specific use cases. This section 2903 suggests a range of mechanisms that would alter the security 2904 assurance of BRSKI to accommodate alternative deployment 2905 architectures and mitigate lifecycle management issues identified in 2906 Section 10. They are presented here as informative (non-normative) 2907 design guidance for future standardization activities. Section 9 2908 provides standardization applicability statements for the ANIMA ACP. 2909 Other users would be expected that subsets of these mechanisms could 2910 be profiled with an accompanying applicability statements similar to 2911 the one described in Section 9. 2913 This section is considered non-normative in the generality of the 2914 protocol. Use of the suggested mechanisms here MUST be detailed in 2915 specific profiles of BRSKI, such as in Section 9. 2917 7.1. Trust Model 2919 This section explains the trust relationships detailed in 2920 Section 2.4: 2922 +--------+ +---------+ +------------+ +------------+ 2923 | Pledge | | Join | | Domain | |Manufacturer| 2924 | | | Proxy | | Registrar | | Service | 2925 | | | | | | | (Internet) | 2926 +--------+ +---------+ +------------+ +------------+ 2928 Figure 10 2930 Pledge: The pledge could be compromised and providing an attack 2931 vector for malware. The entity is trusted to only imprint using 2932 secure methods described in this document. Additional endpoint 2933 assessment techniques are RECOMMENDED but are out-of-scope of this 2934 document. 2936 Join Proxy: Provides proxy functionalities but is not involved in 2937 security considerations. 2939 Registrar: When interacting with a MASA a registrar makes all 2940 decisions. For Ownership Audit Vouchers (see [RFC8366]) the 2941 registrar is provided an opportunity to accept MASA decisions. 2943 Vendor Service, MASA: This form of manufacturer service is trusted 2944 to accurately log all claim attempts and to provide authoritative 2945 log information to registrars. The MASA does not know which 2946 devices are associated with which domains. These claims could be 2947 strengthened by using cryptographic log techniques to provide 2948 append only, cryptographic assured, publicly auditable logs. 2950 Vendor Service, Ownership Validation: This form of manufacturer 2951 service is trusted to accurately know which device is owned by 2952 which domain. 2954 7.2. Pledge security reductions 2956 The following is a list of alternative behaviours that the pledge can 2957 be programmed to implement. These behaviours are not mutually 2958 exclusive, nor are they dependent upon each other. Some of these 2959 methods enable offline and emergency (touch based) deployment use 2960 cases. Normative language is used as these behaviours are referenced 2961 in later sections in a normative fashion. 2963 1. The pledge MUST accept nonceless vouchers. This allows for a use 2964 case where the registrar can not connect to the MASA at the 2965 deployment time. Logging and validity periods address the 2966 security considerations of supporting these use cases. 2968 2. Many devices already support "trust on first use" for physical 2969 interfaces such as console ports. This document does not change 2970 that reality. Devices supporting this protocol MUST NOT support 2971 "trust on first use" on network interfaces. This is because 2972 "trust on first use" over network interfaces would undermine the 2973 logging based security protections provided by this 2974 specification. 2976 3. The pledge MAY have an operational mode where it skips voucher 2977 validation one time. For example if a physical button is 2978 depressed during the bootstrapping operation. This can be useful 2979 if the manufacturer service is unavailable. This behavior SHOULD 2980 be available via local configuration or physical presence methods 2981 (such as use of a serial/craft console) to ensure new entities 2982 can always be deployed even when autonomic methods fail. This 2983 allows for unsecured imprint. 2985 4. A craft/serial console could include a command such as "est- 2986 enroll [2001:db8:0:1]:443" that begins the EST process from the 2987 point after the voucher is validated. This process SHOULD 2988 include server certificate verification using an on-screen 2989 fingerprint. 2991 It is RECOMMENDED that "trust on first use" or any method of skipping 2992 voucher validation (including use of craft serial console) only be 2993 available if hardware assisted Network Endpoint Assessment (NEA: 2994 [RFC5209]) is supported. This recommendation ensures that domain 2995 network monitoring can detect inappropriate use of offline or 2996 emergency deployment procedures when voucher-based bootstrapping is 2997 not used. 2999 7.3. Registrar security reductions 3001 A registrar can choose to accept devices using less secure methods. 3002 They MUST NOT be the default behavior. These methods may be 3003 acceptable in situations where threat models indicate that low 3004 security is adequate. This includes situations where security 3005 decisions are being made by the local administrator: 3007 1. A registrar MAY choose to accept all devices, or all devices of a 3008 particular type, at the administrator's discretion. This could 3009 occur when informing all registrars of unique identifiers of new 3010 entities might be operationally difficult. 3012 2. A registrar MAY choose to accept devices that claim a unique 3013 identity without the benefit of authenticating that claimed 3014 identity. This could occur when the pledge does not include an 3015 X.509 IDevID factory installed credential. New Entities without 3016 an X.509 IDevID credential MAY form the Section 5.2 request using 3017 the Section 5.5 format to ensure the pledge's serial number 3018 information is provided to the registrar (this includes the 3019 IDevID AuthorityKeyIdentifier value, which would be statically 3020 configured on the pledge.) The pledge MAY refuse to provide a 3021 TLS client certificate (as one is not available.) The pledge 3022 SHOULD support HTTP-based or certificate-less TLS authentication 3023 as described in EST RFC7030 section 3.3.2. A registrar MUST NOT 3024 accept unauthenticated New Entities unless it has been configured 3025 to do so by an administrator that has verified that only expected 3026 new entities can communicate with a registrar (presumably via a 3027 physically secured perimeter.) 3029 3. A registrar MAY submit a nonceless voucher-requests to the MASA 3030 service (by not including a nonce in the voucher-request.) The 3031 resulting vouchers can then be stored by the registrar until they 3032 are needed during bootstrapping operations. This is for use 3033 cases where the target network is protected by an air gap and 3034 therefore cannot contact the MASA service during pledge 3035 deployment. 3037 4. A registrar MAY ignore unrecognized nonceless log entries. This 3038 could occur when used equipment is purchased with a valid history 3039 being deployed in air gap networks that required offline 3040 vouchers. 3042 5. A registrar MAY accept voucher formats of future types that can 3043 not be parsed by the Registrar. This reduces the Registrar's 3044 visibility into the exact voucher contents but does not change 3045 the protocol operations. 3047 7.4. MASA security reductions 3049 Lower security modes chosen by the MASA service affect all device 3050 deployments unless the lower-security behavior is tied to specific 3051 device identities. The modes described below can be applied to 3052 specific devices via knowledge of what devices were sold. They can 3053 also be bound to specific customers (independent of the device 3054 identity) by authenticating the customer's Registrar. 3056 7.4.1. Issuing Nonceless vouchers 3058 A MASA has the option of not including a nonce in the voucher, and/or 3059 not requiring one to be present in the voucher-request. This results 3060 in distribution of a voucher that may never expire and in effect 3061 makes the specified Domain an always trusted entity to the pledge 3062 during any subsequent bootstrapping attempts. That a nonceless 3063 voucher was issued is captured in the log information so that the 3064 registrar can make appropriate security decisions when a pledge joins 3065 the Domain. Nonceless vouchers are useful to support use cases where 3066 registrars might not be online during actual device deployment. 3068 While a nonceless voucher may include an expiry date, a typical use 3069 for a nonceless voucher is for it to be long-lived. If the device 3070 can be trusted to have an accurate clock (the MASA will know), then a 3071 nonceless voucher CAN be issued with a limited lifetime. 3073 A more typical case for a nonceless voucher is for use with offline 3074 onboarding scenarios where it is not possible to pass a fresh 3075 voucher-request to the MASA. The use of a long-lived voucher also 3076 eliminates concern about the availability of the MASA many years in 3077 the future. Thus many nonceless vouchers will have no expiry dates. 3079 Thus, the long lived nonceless voucher does not require the proof 3080 that the device is online. Issuing such a thing is only accepted 3081 when the registrar is authenticated by the MASA and the MASA is 3082 authorized to provide this functionality to this customer. The MASA 3083 is RECOMMENDED to use this functionality only in concert with an 3084 enhanced level of ownership tracking, the details of which are out of 3085 scope for this document. 3087 If the pledge device is known to have a real-time-clock that is set 3088 from the factory, use of a voucher validity period is RECOMMENDED. 3090 7.4.2. Trusting Owners on First Use 3092 A MASA has the option of not verifying ownership before responding 3093 with a voucher. This is expected to be a common operational model 3094 because doing so relieves the manufacturer providing MASA services 3095 from having to track ownership during shipping and supply chain and 3096 allows for a very low overhead MASA service. A registrar uses the 3097 audit log information as a defense in depth strategy to ensure that 3098 this does not occur unexpectedly (for example when purchasing new 3099 equipment the registrar would throw an error if any audit log 3100 information is reported.) The MASA SHOULD verify the 'prior-signed- 3101 voucher-request' information for pledges that support that 3102 functionality. This provides a proof-of-proximity check that reduces 3103 the need for ownership verification. The proof-of-proximity comes 3104 from the assumption that the pledge and Join Proxy are on the same 3105 link-local connection. 3107 A MASA that practices Trust-on-First-Use (TOFU) for Registrar 3108 identity may wish to annotate the origin of the connection by IP 3109 address or netblock, and restrict future use of that identity from 3110 other locations. A MASA that does this SHOULD take care to not 3111 create nuisance situations for itself when a customer has multiple 3112 registrars, or uses outgoing IPv4 NAT44 connections that change 3113 frequently. 3115 7.4.3. Updating or extending voucher trust anchors 3117 This section deals with the problem of a MASA that is no longer 3118 available due to a failed business, or the situation where a MASA is 3119 uncooperative to a secondary sale. 3121 A manufacturer could offer a management mechanism that allows the 3122 list of voucher verification trust anchors to be extended. 3123 [I-D.ietf-netconf-keystore] is one such interface that could be 3124 implemented using YANG. Pretty much any configuration mechanism used 3125 today could be extended to provide the needed additional update. A 3126 manufacturer could even decide to install the domain CA trust anchors 3127 received during the EST "cacerts" step as voucher verification 3128 anchors. Some additional signals will be needed to clearly identify 3129 which keys have voucher validation authority from among those signed 3130 by the domain CA. This is future work. 3132 With the above change to the list of anchors, vouchers can be issued 3133 by an alternate MASA. This could be the previous owner (the seller), 3134 or some other trusted third party who is mediating the sale. If it 3135 was a third party, then the seller would need to have taken steps to 3136 introduce the third party configuration to the device prior 3137 disconnection. The third party (e.g. a wholesaler of used equipment) 3138 could however use a mechanism described in Section 7.2 to take 3139 control of the device after receiving it physically. This would 3140 permit the third party to act as the MASA for future onboarding 3141 actions. As the IDevID certificate probably can not be replaced, the 3142 new owner's Registrar would have to support an override of the MASA 3143 URL. 3145 To be useful for resale or other transfers of ownership one of two 3146 situations will need to occur. The simplest is that the device is 3147 not put through any kind of factory default/reset before going 3148 through onboarding again. Some other secure, physical signal would 3149 be needed to initiate it. This is most suitable for redeploying a 3150 device within the same Enterprise. This would entail having previous 3151 configuration in the system until entirely replaced by the new owner, 3152 and represents some level of risk. 3154 The second mechanism is that there would need to be two levels of 3155 factory reset. One would take the system back entirely to 3156 manufacturer state, including removing any added trust anchors, and 3157 the second (more commonly used) one would just restore the 3158 configuration back to a known default without erasing trust anchors. 3159 This weaker factory reset might leave valuable credentials on the 3160 device and this may be unacceptable to some owners. 3162 As a third option, the manufacturer's trust anchors could be entirely 3163 overwritten with local trust anchors. A factory default would never 3164 restore those anchors. This option comes with a lot of power, but 3165 also a lot of responsibility: if access to the private part of the 3166 new anchors are lost the manufacturer may be unable to help. 3168 8. IANA Considerations 3170 This document requires the following IANA actions: 3172 8.1. The IETF XML Registry 3174 This document registers a URI in the "IETF XML Registry" [RFC3688]. 3175 IANA is asked to register the following: 3177 URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request 3178 Registrant Contact: The ANIMA WG of the IETF. 3179 XML: N/A, the requested URI is an XML namespace. 3181 8.2. YANG Module Names Registry 3183 This document registers a YANG module in the "YANG Module Names" 3184 registry [RFC6020]. IANA is asked to register the following: 3186 name: ietf-voucher-request 3187 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request 3188 prefix: vch 3189 reference: THIS DOCUMENT 3191 8.3. Well-known EST registration 3193 This document extends the definitions of "est" (so far defined via 3194 RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ 3195 well-known-uris.xhtml" registry. IANA is asked to change the 3196 registration of "est" to include RFC7030 and this document. 3198 8.4. PKIX Registry 3200 IANA is requested to register the following: 3202 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 3203 the pkix(7) id-mod(0) Registry. 3205 This document has received an early allocation from the id-pe 3206 registry (SMI Security for PKIX Certificate Extension) for id-pe- 3207 masa-url with the value 32, resulting in an OID of 3208 1.3.6.1.5.5.7.1.32. 3210 8.5. Pledge BRSKI Status Telemetry 3212 IANA is requested to create a new Registry entitled: "BRSKI 3213 Parameters", and within that Registry to create a table called: 3214 "Pledge BRSKI Status Telemetry Attributes". New items can be added 3215 using the Specification Required. The following items are to be in 3216 the initial registration, with this document (Section 5.7) as the 3217 reference: 3219 * version 3221 * Status 3223 * Reason 3225 * reason-context 3227 8.6. DNS Service Names 3229 IANA is requested to register the following Service Names: 3231 Service Name: brski-proxy 3232 Transport Protocol(s): tcp 3233 Assignee: IESG . 3234 Contact: IESG 3235 Description: The Bootstrapping Remote Secure Key 3236 Infrastructures Proxy 3237 Reference: [This document] 3239 Service Name: brski-registrar 3240 Transport Protocol(s): tcp 3241 Assignee: IESG . 3242 Contact: IESG 3243 Description: The Bootstrapping Remote Secure Key 3244 Infrastructures Registrar 3245 Reference: [This document] 3247 9. Applicability to the Autonomic Control Plane (ACP) 3249 This document provides a solution to the requirements for secure 3250 bootstrap set out in Using an Autonomic Control Plane for Stable 3251 Connectivity of Network Operations, Administration, and Maintenance 3252 [RFC8368], A Reference Model for Autonomic Networking 3253 [I-D.ietf-anima-reference-model] and specifically the An Autonomic 3254 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section 3255 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 3256 Network). 3258 The protocol described in this document has appeal in a number of 3259 other non-ANIMA use cases. Such uses of the protocol will be 3260 deploying into other environments with different tradeoffs of 3261 privacy, security, reliability and autonomy from manufacturers. As 3262 such those use cases will need to provide their own applicability 3263 statements, and will need to address unique privacy and security 3264 considerations for the environments in which they are used. 3266 The autonomic control plane (ACP) that is bootstrapped by the BRSKI 3267 protocol is typically used in medium to large Internet Service 3268 Provider organizations. Equivalent enterprises that have significant 3269 layer-3 router connectivity also will find significant benefit, 3270 particularly if the Enterprise has many sites. (A network consisting 3271 of primarily layer-2 is not excluded, but the adjacencies that the 3272 ACP will create and maintain will not reflect the topology until all 3273 devices participate in the ACP). 3275 In the ACP, the Join Proxy is found to be proximal because 3276 communication between the pledge and the join proxy is exclusively on 3277 IPv6 Link-Local addresses. The proximity of the Join Proxy to the 3278 Registrar is validated by the Registrar using ANI ACP IPv6 Unique 3279 Local Addresses (ULA). ULAs are not routable over the Internet, so 3280 as long as the Join Proxy is operating correctly the proximity 3281 asssertion is satisfied. Other uses of BRSKI will need make similar 3282 analysis if they use proximity assertions. 3284 As specified in the ANIMA charter, this work "..focuses on 3285 professionally-managed networks." Such a network has an operator and 3286 can do things like install, configure and operate the Registrar 3287 function. The operator makes purchasing decisions and is aware of 3288 what manufacturers it expects to see on its network. 3290 Such an operator is also capable of performing bootstrapping of a 3291 device using a serial-console (craft console). The zero-touch 3292 mechanism presented in this and the ACP document 3293 [I-D.ietf-anima-autonomic-control-plane] represents a significiant 3294 efficiency: in particular it reduces the need to put senior experts 3295 on airplanes to configure devices in person. 3297 There is a recognition as the technology evolves that not every 3298 situation may work out, and occasionally a human may still have to 3299 visit. In recognition of this, some mechanisms are presented in 3300 Section 7.2. The manufacturer MUST provide at least one of the one- 3301 touch mechanisms described that permit enrollment to be proceed 3302 without availability of any manufacturer server (such as the MASA). 3304 The BRSKI protocol is going into environments where there have 3305 already been quite a number of vendor proprietary management systems. 3306 Those are not expected to go away quickly, but rather to leverage the 3307 secure credentials that are provisioned by BRSKI. The connectivity 3308 requirements of said management systems are provided by the ACP. 3310 9.1. Operational Requirements 3312 This section collects operational requirements based upon the three 3313 roles involved in BRSKI: The Manufacturer Authorized Signing 3314 Authority (MASA), the (Domain) Owner and the Device. It should be 3315 recognized that the manufacturer may be involved in two roles, as it 3316 creates the software/firmware for the device, and also may be the 3317 operator of the MASA. 3319 The requirements in this section are presented using BCP14 3320 ([RFC2119], [RFC8174]) language. These do not represent new 3321 normative statements, just a review of a few such things in one place 3322 by role. They also apply specifically to the ANIMA ACP use case. 3323 Other use cases likely have similar, but MAY have different 3324 requirements. 3326 9.1.1. MASA Operational Requirements 3328 The manufacturer MUST arrange for an online service to be available 3329 called the MASA. It MUST be available at the URL which is encoded in 3330 the IDevID certificate extensions described in Section 2.3.2. 3332 The online service MUST have access to a private key with which to 3333 sign [RFC8366] format voucher artifacts. The public key, 3334 certificate, or certificate chain MUST be built in to the device as 3335 part of the firmware. 3337 It is RECOMMENDED that the manufacturer arrange for this signing key 3338 (or keys) to be escrowed according to typical software source code 3339 escrow practices [softwareescrow]. 3341 The MASA accepts voucher requests from Domain Owners according to an 3342 operational practice appropriate for the device. This can range from 3343 any domain owner (first-come first-served, on a TOFU-like basis), to 3344 full sales channel integration where Domain Owners need to be 3345 positively identified by TLS Client Certicate pinned, or HTTP 3346 Authentication process. The MASA creates signed voucher artifacts 3347 according to its internally defined policies. 3349 The MASA MUST operate an audit log for devices that is accessible. 3350 The audit log is designed to be easily cacheable and the MASA MAY 3351 find it useful to put this content on a CDN. 3353 9.1.2. Domain Owner Operational Requirements 3355 The domain owner MUST operate an EST ([RFC7030]) server with the 3356 extensions described in this document. This is the JRC or Registrar. 3357 This JRC/EST server MUST announce itself using GRASP within the ACP. 3358 This EST server will typically reside with the Network Operations 3359 Center for the organization. 3361 The domain owner MAY operate an internal certificate authority (CA) 3362 that is seperate from the EST server, or it MAY combine all 3363 activities into a single device. The determination of the 3364 architecture depends upon the scale and resiliency requirements of 3365 the organization. Multiple JRC instances MAY be announced into the 3366 ACP from multiple locations to achieve an appropriate level of 3367 redundancy. 3369 In order to recognize which devices and which manufacturers are 3370 welcome on the domain owner's network, the domain owner SHOULD 3371 maintain a white list of manufacturers. This MAY extend to 3372 integration with purchasing departments to know the serial numbers of 3373 devices. 3375 The domain owner SHOULD use the resulting overlay ACP network to 3376 manage devices, replacing legacy out-of-band mechanisms. 3378 The domain owner SHOULD operate one or more EST servers which can be 3379 used to renew the domain certificates (LDevIDs) which are deployed to 3380 devices. These servers MAY be the same as the JRC, or MAY be a 3381 distinct set of devices, as approriate for resiliency. 3383 The organization MUST take appropriate precautions against loss of 3384 access to the certificate authority private key. Hardware security 3385 modules and/or secret splitting are appropriate. 3387 9.1.3. Device Operational Requirements 3389 Devices MUST come with built-in trust anchors that permit the device 3390 to validate vouchers from the MASA. 3392 Device MUST come with (unique, per-device) IDevID certificates that 3393 include their serial numbers, and the MASA URL extension. 3395 Devices are expected to find Join Proxies using GRASP, and then 3396 connect to the JRC using the protocol described in this document. 3398 Once a domain owner has been validated with the voucher, devices are 3399 expected to enroll into the domain using EST. Devices are then 3400 expected to form ACPs using IPsec over IPv6 Link-Local addresses as 3401 described in [I-D.ietf-anima-autonomic-control-plane] 3403 Once a device has been enrolled it SHOULD listen for the address of 3404 the JRC using GRASP, and it SHOULD enable itself as a Join Proxy, and 3405 announce itself on all links/interfaces using GRASP DULL. 3407 Devices are expected to renew their certificates before they expire. 3409 10. Privacy Considerations 3411 10.1. MASA audit log 3413 The MASA audit log includes the domainID for each domain a voucher 3414 has been issued to. This information is closely related to the 3415 actual domain identity. A MASA may need additional defenses against 3416 Denial of Service attacks (Section 11.1), and this may involve 3417 collecting additional (unspecified here) information. This could 3418 provide sufficient information for the MASA service to build a 3419 detailed understanding the devices that have been provisioned within 3420 a domain. 3422 There are a number of design choices that mitigate this risk. The 3423 domain can maintain some privacy since it has not necessarily been 3424 authenticated and is not authoritatively bound to the supply chain. 3426 Additionally the domainID captures only the unauthenticated subject 3427 key identifier of the domain. A privacy sensitive domain could 3428 theoretically generate a new domainID for each device being deployed. 3429 Similarly a privacy sensitive domain would likely purchase devices 3430 that support proximity assertions from a manufacturer that does not 3431 require sales channel integrations. This would result in a 3432 significant level of privacy while maintaining the security 3433 characteristics provided by Registrar based audit log inspection. 3435 10.2. What BRSKI-EST reveals 3437 During the provisional phase of the BRSKI-EST connection between the 3438 Pledge and the Registrar, each party reveals its certificates to each 3439 other. For the Pledge, this includes the serialNumber attribute, the 3440 MASA URL, and the identity that signed the IDevID certificate. 3442 TLS 1.2 reveals the certificate identities to on-path observers, 3443 including the Join Proxy. 3445 TLS 1.3 reveals the certificate identities only to the end parties, 3446 but as the connection is provisional, an on-path attacker (MTIM) can 3447 see the certificates. This includes not just malicious attackers, 3448 but also Registrars that are visible to the Pledge, but which are not 3449 part of the intended domain. 3451 The certificate of the Registrar is rather arbitrary from the point 3452 of view of the BRSKI protocol. As no [RFC6125] validations are 3453 expected to be done, the contents could be easily pseudonymized. Any 3454 device that can see a join proxy would be able to connect to the 3455 Registrar and learn the identity of the network in question. Even if 3456 the contents of the certificate are pseudonymized, it would be 3457 possible to correlate different connections in different locations 3458 belong to the same entity. This is unlikely to present a significant 3459 privacy concern to ANIMA ACP uses of BRSKI, but may be a concern to 3460 other users of BRSKI. 3462 The certificate of the Pledge could be revealed by a malicious Join 3463 Proxy that performed a MITM attack on the provisional TLS connection. 3464 Such an attacker would be able to reveal the identity of the Pledge 3465 to third parties if it chose to so. 3467 Research into a mechanism to do multi-step, multi-party authenticated 3468 key agreement, incorporating some kind of zero-knowledge proof would 3469 be valuable. Such a mechanism would ideally avoid disclosing 3470 identities until pledge, registrar and MASA agree to the transaction. 3471 Such a mechanism would need to discover the location of the MASA 3472 without knowing the identity of the pledge, or the identity of the 3473 MASA. This part of the problem may be unsolveable. 3475 10.3. What BRSKI-MASA reveals to the manufacturer 3477 With consumer-oriented devices, the "call-home" mechanism in IoT 3478 devices raises significant privacy concerns. See [livingwithIoT] and 3479 [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP) 3480 usage of BRSKI is not targeted at individual usage of IoT devices, 3481 but rather at the Enterprise and ISP creation of networks in a zero- 3482 touch fashion where the "call-home" represents a different class of 3483 privacy and lifecycle management concerns. 3485 As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted 3486 at individual usage of IoT devices, but rather at the Enterprise and 3487 ISP creation of networks in a zero-touch fashion, the "call-home" 3488 represents a different kind of concern. 3490 It needs to be re-iterated that the BRSKI-MASA mechanism only occurs 3491 once during the commissioning of the device. It is well defined, and 3492 although encrypted with TLS, it could in theory be made auditable as 3493 the contents are well defined. This connection does not occur when 3494 the device powers on or is restarted for normal routines. (It is 3495 conceivable, but remarkably unusual, that a device could be forced to 3496 go through a full factory reset during an exceptional firmware update 3497 situation, after which enrollment would have be repeated, and a new 3498 connection would occur) 3500 The BRSKI call-home mechanism is mediated via the owner's Registrar, 3501 and the information that is transmitted is directly auditable by the 3502 device owner. This is in stark contrast to many "call-home" 3503 protocols where the device autonomously calls home and uses an 3504 undocumented protocol. 3506 While the contents of the signed part of the pledge voucher request 3507 can not be changed, they are not encrypted at the registrar. The 3508 ability to audit the messages by the owner of the network is a 3509 mechanism to defend against exfiltration of data by a nefarious 3510 pledge. Both are, to re-iterate, encrypted by TLS while in transit. 3512 The BRSKI-MASA exchange reveals the following information to the 3513 manufacturer: 3515 * the identity of the device being enrolled. This is revealed by 3516 transmission of a signed voucher-request containing the serial- 3517 number. The manufacturer can usually link the serial number to a 3518 device model. 3520 * an identity of the domain owner in the form of the domain trust 3521 anchor. However, this is not a global PKI anchored name within 3522 the WebPKI, so this identity could be pseudonymous. If there is 3523 sales channel integration, then the MASA will have authenticated 3524 the domain owner, either via pinned certificate, or perhaps 3525 another HTTP authentication method, as per Section 5.5.4. 3527 * the time the device is activated, 3529 * the IP address of the domain Owner's Registrar. For ISPs and 3530 Enterprises, the IP address provides very clear geolocation of the 3531 owner. No amount of IP address privacy extensions ([RFC4941]) can 3532 do anything about this, as a simple whois lookup likely identifies 3533 the ISP or Enterprise from the upper bits anyway. A passive 3534 attacker who observes the connection definitely may conclude that 3535 the given enterprise/ISP is a customer of the particular equipment 3536 vendor. The precise model that is being enrolled will remain 3537 private. 3539 Based upon the above information, the manufacturer is able to track a 3540 specific device from pseudonymous domain identity to the next 3541 pseudonymous domain identity. If there is sales-channel integration, 3542 then the identities are not pseudonymous. 3544 The manufacturer knows the IP address of the Registrar, but it can 3545 not see the IP address of the device itself. The manufacturer can 3546 not track the device to a detailed physical or network location, only 3547 to the location of the Registrar. That is likely to be at the 3548 Enterprise or ISPs headquarters. 3550 The above situation is to be distinguished from a residential/ 3551 individual person who registers a device from a manufacturer. 3552 Individuals do not tend to have multiple offices, and their registrar 3553 is likely on the same network as the device. A manufacturer that 3554 sells switching/routing products to enterprises should hardly be 3555 surprised if additional purchases switching/routing products are 3556 made. Deviations from a historical trend or an establish baseline 3557 would, however, be notable. 3559 The situation is not improved by the enterprise/ISP using 3560 anonymization services such as ToR [Dingledine2004], as a TLS 1.2 3561 connection will reveal the ClientCertificate used, clearly 3562 identifying the enterprise/ISP involved. TLS 1.3 is better in this 3563 regard, but an active attacker can still discover the parties 3564 involved by performing a Man-In-The-Middle-Attack on the first 3565 attempt (breaking/killing it with a TCP RST), and then letting 3566 subsequent connection pass through. 3568 A manufacturer could attempt to mix the BRSKI-MASA traffic in with 3569 general traffic their site by hosting the MASA behind the same (set) 3570 of load balancers that the companies normal marketing site is hosted 3571 behind. This makes lots of sense from a straight capacity planning 3572 point of view as the same set of services (and the same set of 3573 Distributed Denial of Service mitigations) may be used. 3574 Unfortunately, as the BRSKI-MASA connections include TLS 3575 ClientCertificate exchanges, this may easily be observed in TLS 1.2, 3576 and a traffic analysis may reveal it even in TLS 1.3. This does not 3577 make such a plan irrelevant. There may be other organizational 3578 reasons to keep the marketing site (which is often subject to 3579 frequent re-designs, outsourcing, etc.) separate from the MASA, which 3580 may need to operate reliably for decades. 3582 10.4. Manufacturers and Used or Stolen Equipment 3584 As explained above, the manufacturer receives information each time 3585 that a device which is in factory-default mode does a zero-touch 3586 bootstrap, and attempts to enroll into a domain owner's registrar. 3588 The manufacturer is therefore in a position to decline to issue a 3589 voucher if it detects that the new owner is not the same as the 3590 previous owner. 3592 1. This can be seen as a feature if the equipment is believed to 3593 have been stolen. If the legitimate owner notifies the 3594 manufacturer of the theft, then when the new owner brings the 3595 device up, if they use the zero-touch mechanism, the new 3596 (illegitimate) owner reveals their location and identity. 3598 2. In the case of Used equipment, the initial owner could inform the 3599 manufacturer of the sale, or the manufacturer may just permit 3600 resales unless told otherwise. In which case, the transfer of 3601 ownership simply occurs. 3603 3. A manufacturer could however decide not to issue a new voucher in 3604 response to a transfer of ownership. This is essentially the 3605 same as the stolen case, with the manufacturer having decided 3606 that the sale was not legitimate. 3608 4. There is a fourth case, if the manufacturer is providing 3609 protection against stolen devices. The manufacturer then has a 3610 responsibility to protect the legitimate owner against fraudulent 3611 claims that the equipment was stolen. In the absence of such 3612 manufacturer protection, such a claim would cause the 3613 manufacturer to refuse to issue a new voucher. Should the device 3614 go through a deep factory reset (for instance, replacement of a 3615 damaged main board component, the device would not bootstrap. 3617 5. Finally, there is a fifth case: the manufacturer has decided to 3618 end-of-line the device, or the owner has not paid a yearly 3619 support amount, and the manufacturer refuses to issue new 3620 vouchers at that point. This last case is not new to the 3621 industry: many license systems are already deployed that have 3622 significantly worse effect. 3624 This section has outlined five situations in which a manufacturer 3625 could use the voucher system to enforce what are clearly license 3626 terms. A manufacturer that attempted to enforce license terms via 3627 vouchers would find it rather ineffective as the terms would only be 3628 enforced when the device is enrolled, and this is not (to repeat), a 3629 daily or even monthly occurrence. 3631 10.5. Manufacturers and Grey market equipment 3633 Manufacturers of devices often sell different products into different 3634 regional markets. Which product is available in which market can be 3635 driven by price differentials, support issues (some markets may 3636 require manuals and tech-support to be done in the local language), 3637 government export regulation (such as whether strong crypto is 3638 permitted to be exported, or permitted to be used in a particular 3639 market). When an domain owner obtains a device from a different 3640 market (they can be new) and transfers it to a different location, 3641 this is called a Grey Market. 3643 A manufacturer could decide not to issue a voucher to an enterprise/ 3644 ISP based upon their location. There are a number of ways which this 3645 could be determined: from the geolocation of the registrar, from 3646 sales channel knowledge about the customer, and what products are 3647 (un-)available in that market. If the device has a GPS the 3648 coordinates of the device could even be placed into an extension of 3649 the voucher. 3651 The above actions are not illegal, and not new. Many manufacturers 3652 have shipped crypto-weak (exportable) versions of firmware as the 3653 default on equipment for decades. The first task of an enterprise/ 3654 ISP has always been to login to a manufacturer system, show one's 3655 "entitlement" (country information, proof that support payments have 3656 been made), and receive either a new updated firmware, or a license 3657 key that will activate the correct firmware. 3659 BRSKI permits the above process to automated (in an autonomic 3660 fashion), and therefore perhaps encourages this kind of 3661 differentiation by reducing the cost of doing it. 3663 An issue that manufacturers will need to deal with in the above 3664 automated process is when a device is shipped to one country with one 3665 set of rules (or laws or entitlements), but the domain registry is in 3666 another one. Which rules apply is something will have to be worked 3667 out: the manufacturer could come to believe they are dealing with 3668 Grey market equipment, when it is simply dealing with a global 3669 enterprise. 3671 10.6. Some mitigations for meddling by manufacturers 3673 The most obvious mitigation is not to buy the product. Pick 3674 manufacturers that are up-front about their policies, who do not 3675 change them gratuitously. 3677 Section 7.4.3 describes some ways in which a manufacturer could 3678 provide a mechanism to manage the trust anchors and built-in 3679 certificates (IDevID) as an extension. There are a variety of 3680 mechanism, and some may take a substantial amount of work to get 3681 exactly correct. These mechanisms do not change the flow of the 3682 protocol described here, but rather allow the starting trust 3683 assumptions to be changed. This is an area for future 3684 standardization work. 3686 Replacement of the voucher validation anchors (usually pointing to 3687 the original manufacturer's MASA) with those of the new owner permits 3688 the new owner to issue vouchers to subsequent owners. This would be 3689 done by having the selling (old) owner to run a MASA. 3691 The BRSKI protocol depends upon a trust anchor on the device and an 3692 identity on the device. Management of these entities facilitates a 3693 few new operational modes without making any changes to the BRSKI 3694 protocol. Those modes include: offline modes where the domain owner 3695 operates an internal MASA for all devices, resell modes where the 3696 first domain owner becomes the MASA for the next (resold-to) domain 3697 owner, and services where an aggregator acquires a large variety of 3698 devices, and then acts as a pseudonymized MASA for a variety of 3699 devices from a variety of manufacturers. 3701 Although replacement of the IDevID is not required for all modes 3702 described above, a manufacturers could support such a thing. Some 3703 may wish to consider replacement of the IDevID as an indication that 3704 the device's warrantee is terminated. For others, the privacy 3705 requirements of some deployments might consider this a standard 3706 operating practice. 3708 As discussed at the end of Section 5.8.1, new work could be done to 3709 use a distributed consensus technology for the audit log. This would 3710 permit the audit log to continue to be useful, even when there is a 3711 chain of MASA due to changes of ownership. 3713 10.7. Death of a manufacturer 3715 A common concern has been that a manufacturer could go out of 3716 business, leaving owners of devices unable to get new vouchers for 3717 existing products. Said products might have been previously 3718 deployed, but need to be re-initialized, they might have been 3719 purchased used, or they might have kept in a warehouse as long-term 3720 spares. 3722 The MASA was named the Manufacturer *Authorized* Signing Authority to 3723 emphasize that it need not be the manufacturer itself that performs 3724 this. It is anticipated that specialist service providers will come 3725 to exist that deal with the creation of vouchers in much the same way 3726 that many companies have outsourced email, advertising and janitorial 3727 services. 3729 Further, it is expected that as part of any service agreement that 3730 the manufacturer would arrange to escrow appropriate private keys 3731 such that a MASA service could be provided by a third party. This 3732 has routinely been done for source code for decades. 3734 11. Security Considerations 3736 This document details a protocol for bootstrapping that balances 3737 operational concerns against security concerns. As detailed in the 3738 introduction, and touched on again in Section 7, the protocol allows 3739 for reduced security modes. These attempt to deliver additional 3740 control to the local administrator and owner in cases where less 3741 security provides operational benefits. This section goes into more 3742 detail about a variety of specific considerations. 3744 To facilitate logging and administrative oversight, in addition to 3745 triggering Registrar verification of MASA logs, the pledge reports on 3746 voucher parsing status to the registrar. In the case of a failure, 3747 this information is informative to a potentially malicious registrar. 3748 This is mandated anyway because of the operational benefits of an 3749 informed administrator in cases where the failure is indicative of a 3750 problem. The registrar is RECOMMENDED to verify MASA logs if voucher 3751 status telemetry is not received. 3753 To facilitate truly limited clients EST RFC7030 section 3.3.2 3754 requirements that the client MUST support a client authentication 3755 model have been reduced in Section 7 to a statement that the 3756 registrar "MAY" choose to accept devices that fail cryptographic 3757 authentication. This reflects current (poor) practices in shipping 3758 devices without a cryptographic identity that are NOT RECOMMENDED. 3760 During the provisional period of the connection the pledge MUST treat 3761 all HTTP header and content data as untrusted data. HTTP libraries 3762 are regularly exposed to non-secured HTTP traffic: mature libraries 3763 should not have any problems. 3765 Pledges might chose to engage in protocol operations with multiple 3766 discovered registrars in parallel. As noted above they will only do 3767 so with distinct nonce values, but the end result could be multiple 3768 vouchers issued from the MASA if all registrars attempt to claim the 3769 device. This is not a failure and the pledge choses whichever 3770 voucher to accept based on internal logic. The registrars verifying 3771 log information will see multiple entries and take this into account 3772 for their analytics purposes. 3774 11.1. Denial of Service (DoS) against MASA 3776 There are uses cases where the MASA could be unavailable or 3777 uncooperative to the Registrar. They include active DoS attacks, 3778 planned and unplanned network partitions, changes to MASA policy, or 3779 other instances where MASA policy rejects a claim. These introduce 3780 an operational risk to the Registrar owner in that MASA behavior 3781 might limit the ability to bootstrap a pledge device. For example 3782 this might be an issue during disaster recovery. This risk can be 3783 mitigated by Registrars that request and maintain long term copies of 3784 "nonceless" vouchers. In that way they are guaranteed to be able to 3785 bootstrap their devices. 3787 The issuance of nonceless vouchers themselves creates a security 3788 concern. If the Registrar of a previous domain can intercept 3789 protocol communications then it can use a previously issued nonceless 3790 voucher to establish management control of a pledge device even after 3791 having sold it. This risk is mitigated by recording the issuance of 3792 such vouchers in the MASA audit log that is verified by the 3793 subsequent Registrar and by Pledges only bootstrapping when in a 3794 factory default state. This reflects a balance between enabling MASA 3795 independence during future bootstrapping and the security of 3796 bootstrapping itself. Registrar control over requesting and auditing 3797 nonceless vouchers allows device owners to choose an appropriate 3798 balance. 3800 The MASA is exposed to DoS attacks wherein attackers claim an 3801 unbounded number of devices. Ensuring a registrar is representative 3802 of a valid manufacturer customer, even without validating ownership 3803 of specific pledge devices, helps to mitigate this. Pledge 3804 signatures on the pledge voucher-request, as forwarded by the 3805 registrar in the prior-signed-voucher-request field of the registrar 3806 voucher-request, significantly reduce this risk by ensuring the MASA 3807 can confirm proximity between the pledge and the registrar making the 3808 request. Supply chain integration ("know your customer") is an 3809 additional step that MASA providers and device vendors can explore. 3811 11.2. DomainID must be resistant to second-preimage attacks 3813 The domainID is used as the reference in the audit log to the domain. 3814 The domainID is expected to be calculated by a hash that is resistant 3815 to a second-preimage attack. Such an attack would allow a second 3816 registrar to create audit log entries that are fake. 3818 11.3. Availability of good random numbers 3820 The nonce used by the Pledge in the voucher-request SHOULD be 3821 generated by a Strong Cryptographic Sequence ([RFC4086] section 6.2). 3822 TLS has a similar requirement. 3824 In particular implementations should pay attention to the advance in 3825 [RFC4086] section 3, particularly section 3.4. The random seed used 3826 by a device at boot MUST be unique across all devices and all 3827 bootstraps. Resetting a device to factory default state does not 3828 obviate this requirement. 3830 11.4. Freshness in Voucher-Requests 3832 A concern has been raised that the pledge voucher-request should 3833 contain some content (a nonce) provided by the registrar and/or MASA 3834 in order for those actors to verify that the pledge voucher-request 3835 is fresh. 3837 There are a number of operational problems with getting a nonce from 3838 the MASA to the pledge. It is somewhat easier to collect a random 3839 value from the registrar, but as the registrar is not yet vouched 3840 for, such a registrar nonce has little value. There are privacy and 3841 logistical challenges to addressing these operational issues, so if 3842 such a thing were to be considered, it would have to provide some 3843 clear value. This section examines the impacts of not having a fresh 3844 pledge voucher-request. 3846 Because the registrar authenticates the pledge, a full Man-in-the- 3847 Middle attack is not possible, despite the provisional TLS 3848 authentication by the pledge (see Section 5.) Instead we examine the 3849 case of a fake registrar (Rm) that communicates with the pledge in 3850 parallel or in close time proximity with the intended registrar. 3851 (This scenario is intentionally supported as described in 3852 Section 4.1.) 3854 The fake registrar (Rm) can obtain a voucher signed by the MASA 3855 either directly or through arbitrary intermediaries. Assuming that 3856 the MASA accepts the registrar voucher-request (either because Rm is 3857 collaborating with a legitimate registrar according to supply chain 3858 information, or because the MASA is in audit-log only mode), then a 3859 voucher linking the pledge to the registrar Rm is issued. 3861 Such a voucher, when passed back to the pledge, would link the pledge 3862 to registrar Rm, and would permit the pledge to end the provisional 3863 state. It now trusts Rm and, if it has any security vulnerabilities 3864 leveragable by an Rm with full administrative control, can be assumed 3865 to be a threat against the intended registrar. 3867 This flow is mitigated by the intended registrar verifying the audit 3868 logs available from the MASA as described in Section 5.8. Rm might 3869 chose to collect a voucher-request but wait until after the intended 3870 registrar completes the authorization process before submitting it. 3871 This pledge voucher-request would be 'stale' in that it has a nonce 3872 that no longer matches the internal state of the pledge. In order to 3873 successfully use any resulting voucher the Rm would need to remove 3874 the stale nonce or anticipate the pledge's future nonce state. 3875 Reducing the possibility of this is why the pledge is mandated to 3876 generate a strong random or pseudo-random number nonce. 3878 Additionally, in order to successfully use the resulting voucher the 3879 Rm would have to attack the pledge and return it to a bootstrapping 3880 enabled state. This would require wiping the pledge of current 3881 configuration and triggering a re-bootstrapping of the pledge. This 3882 is no more likely than simply taking control of the pledge directly 3883 but if this is a consideration the target network is RECOMMENDED to 3884 take the following steps: 3886 * Ongoing network monitoring for unexpected bootstrapping attempts 3887 by pledges. 3889 * Retrieval and examination of MASA log information upon the 3890 occurrence of any such unexpected events. Rm will be listed in 3891 the logs along with nonce information for analysis. 3893 11.5. Trusting manufacturers 3895 The BRSKI extensions to EST permit a new pledge to be completely 3896 configured with domain specific trust anchors. The link from built- 3897 in manufacturer-provided trust anchors to domain-specific trust 3898 anchors is mediated by the signed voucher artifact. 3900 If the manufacturer's IDevID signing key is not properly validated, 3901 then there is a risk that the network will accept a pledge that 3902 should not be a member of the network. As the address of the 3903 manufacturer's MASA is provided in the IDevID using the extension 3904 from Section 2.3, the malicious pledge will have no problem 3905 collaborating with it's MASA to produce a completely valid voucher. 3907 BRSKI does not, however, fundamentally change the trust model from 3908 domain owner to manufacturer. Assuming that the pledge used its 3909 IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs 3910 to trust the manufacturer. 3912 Establishing this trust between domain and manufacturer is outside 3913 the scope of BRSKI. There are a number of mechanisms that can 3914 adopted including: 3916 * Manually configuring each manufacturer's trust anchor. 3918 * A Trust-On-First-Use (TOFU) mechanism. A human would be queried 3919 upon seeing a manufacturer's trust anchor for the first time, and 3920 then the trust anchor would be installed to the trusted store. 3921 There are risks with this; even if the key to name mapping is 3922 validated using something like the WebPKI, there remains the 3923 possibility that the name is a look alike: e.g, dem0.example. vs 3924 demO.example. 3926 * scanning the trust anchor from a QR code that came with the 3927 packaging (this is really a manual TOFU mechanism) 3929 * some sales integration process where trust anchors are provided as 3930 part of the sales process, probably included in a digital packing 3931 "slip", or a sales invoice. 3933 * consortium membership, where all manufacturers of a particular 3934 device category (e.g, a light bulb, or a cable-modem) are signed 3935 by an certificate authority specifically for this. This is done 3936 by CableLabs today. It is used for authentication and 3937 authorization as part of TR-79: [docsisroot] and [TR069]. 3939 The existing WebPKI provides a reasonable anchor between manufacturer 3940 name and public key. It authenticates the key. It does not provide 3941 a reasonable authorization for the manufacturer, so it is not 3942 directly useable on it's own. 3944 11.6. Manufacturer Maintenance of trust anchors 3946 BRSKI depends upon the manufacturer building in trust anchors to the 3947 pledge device. The voucher artifact which is signed by the MASA will 3948 be validated by the pledge using that anchor. This implies that the 3949 manufacturer needs to maintain access to a signing key that the 3950 pledge can validate. 3952 The manufacturer will need to maintain the ability to make signatures 3953 that can be validated for the lifetime that the device could be 3954 onboarded. Whether this onboarding lifetime is less than the device 3955 lifetime depends upon how the device is used. An inventory of 3956 devices kept in a warehouse as spares might not be onboarded for many 3957 decades. 3959 There are good cryptographic hygiene reasons why a manufacturer would 3960 not want to maintain access to a private key for many decades. A 3961 manufacturer in that situation can leverage a long-term certificate 3962 authority anchor, built-in to the pledge, and then a certificate 3963 chain may be incorporated using the normal CMS certificate set. This 3964 may increase the size of the voucher artifacts, but that is not a 3965 significant issues in non-constrained environments. 3967 There are a few other operational variations that manufacturers could 3968 consider. For instance, there is no reason that every device need 3969 have the same set of trust anchors pre-installed. Devices built in 3970 different factories, or on different days, or any other consideration 3971 could have different trust anchors built in, and the record of which 3972 batch the device is in would be recorded in the asset database. The 3973 manufacturer would then know which anchor to sign an artifact 3974 against. 3976 Aside from the concern about long-term access to private keys, a 3977 major limiting factor for the shelf-life of many devices will be the 3978 age of the cryptographic algorithms included. A device produced in 3979 2019 will have hardware and software capable of validating algorithms 3980 common in 2019, and will have no defense against attacks (both 3981 quantum and von-neuman brute force attacks) which have not yet been 3982 invented. This concern is orthogonal to the concern about access to 3983 private keys, but this concern likely dominates and limits the 3984 lifespan of a device in a warehouse. If any update to firmware to 3985 support new cryptographic mechanism were possible (while the device 3986 was in a warehouse), updates to trust anchors would also be done at 3987 the same time. 3989 The set of standard operating procedures for maintaining high value 3990 private keys is well documented. For instance, the WebPKI provides a 3991 number of options for audits at [cabforumaudit], and the DNSSEC root 3992 operations are well documented at [dnssecroot]. 3994 It is not clear if Manufacturers will take this level of precaution, 3995 or how strong the economic incentives are to maintain an appropriate 3996 level of security. 3998 This next section examines the risk due to a compromised manufacturer 3999 IDevID signing key. This is followed by examination of the risk due 4000 to a compromised MASA key. The third section sections below examines 4001 the situation where MASA web server itself is under attacker control, 4002 but that the MASA signing key itself is safe in a not-directly 4003 connected hardware module. 4005 11.6.1. Compromise of Manufacturer IDevID signing keys 4007 An attacker that has access to the key that the manufacturer uses to 4008 sign IDevID certificates can create counterfeit devices. Such 4009 devices can claim to be from a particular manufacturer, but be 4010 entirely different devices: Trojan horses in effect. 4012 As the attacker controls the MASA URL in the certificate, the 4013 registrar can be convinced to talk to the attackers' MASA. The 4014 Registrar does not need to be in any kind of promiscuous mode to be 4015 vulnerable. 4017 In addition to creating fake devices, the attacker may also be able 4018 to issue revocations for existing certificates if the IDevID 4019 certificate process relies upon CRL lists that are distributed. 4021 There does not otherwise seem to be any risk from this compromise to 4022 devices which are already deployed, or which are sitting locally in 4023 boxes waiting for deployment (local spares). The issue is that 4024 operators will be unable to trust devices which have been in an 4025 uncontrolled warehouse as they do not know if those are real devices. 4027 11.6.2. Compromise of MASA signing keys 4029 There are two periods of time in which to consider: when the MASA key 4030 has fallen into the hands of an attacker, and after the MASA 4031 recognizes that the key has been compromised. 4033 11.6.2.1. Attacker opportunties with compromised MASA key 4035 An attacker that has access to the MASA signing key could create 4036 vouchers. These vouchers could be for existing deployed devices, or 4037 for devices which are still in a warehouse. In order to exploit 4038 these vouchers two things need to occur: the device has to go through 4039 a factory default boot cycle, and the registrar has to be convinced 4040 to contact the attacker's MASA. 4042 If the attacker controls a Registrar which is visible to the device, 4043 then there is no difficulty in delivery of the false voucher. A 4044 possible practical example of an attack like this would be in a data 4045 center, at an ISP peering point (whether a public IX, or a private 4046 peering point). In such a situation, there are already cables 4047 attached to the equipment that lead to other devices (the peers at 4048 the IX), and through those links, the false voucher could be 4049 delivered. The difficult part would be get the device put through a 4050 factory reset. This might be accomplished through social engineering 4051 of data center staff. Most locked cages have ventilation holes, and 4052 possibly a long "paperclip" could reach through to depress a factory 4053 reset button. Once such a piece of ISP equipment has been 4054 compromised, it could be used to compromise equipment that was 4055 connected to (through long haul links even), assuming that those 4056 pieces of equipment could also be forced through a factory reset. 4058 The above scenario seems rather unlikely as it requires some element 4059 of physical access; but were there a remote exploit that did not 4060 cause a direct breach, but rather a fault that resulted in a factory 4061 reset, this could provide a reasonable path. 4063 The above deals with ANI uses of BRSKI. For cases where 802.11 or 4064 802.15.4 is involved, the need to connect directly to the device is 4065 eliminated, but the need to do a factory reset is not. Physical 4066 possession of the device is not required as above, provided that 4067 there is some way to force a factory reset. With some consumers 4068 devices with low overall implementation quality, the end users might 4069 be familiar with needing to reset the device regularly. 4071 The authors are unable to come up with an attack scenario where a 4072 compromised voucher signature enables an attacker to introduce a 4073 compromised pledge into an existing operator's network. This is the 4074 case because the operator controls the communication between 4075 Registrar and MASA, and there is no opportunity to introduce the fake 4076 voucher through that conduit. 4078 11.6.2.2. Risks after key compromise is known 4080 Once the operator of the MASA realizes that the voucher signing key 4081 has been compromised it has to do a few things. 4083 First, it MUST issue a firmware update to all devices that had that 4084 key as a trust anchor, such that they will no longer trust vouchers 4085 from that key. This will affect devices in the field which are 4086 operating, but those devices, being in operation, are not performing 4087 onboarding operations, so this is not a critical patch. 4089 Devices in boxes (in warehouses) are vulnerable, and remain 4090 vulnerable until patched. An operator would be prudent to unbox the 4091 devices, onboard them in a safe environment, and then perform 4092 firmware updates. This does not have to be done by the end-operator; 4093 it could be done by a distributor that stores the spares. A 4094 recommended practice for high value devices (which typically have a 4095 <4hr service window) may be to validate the device operation on a 4096 regular basis anyway. 4098 If the onboarding process includes attestations about firmware 4099 versions, then through that process the operator would be advised to 4100 upgrade the firmware before going into production. Unfortunately, 4101 this does not help against situations where the attacker operates 4102 their own Registrar (as listed above). 4104 [RFC8366] section 6.1 explains the need for short-lived vouchers. 4105 The nonce guarantees freshness, and the short-lived nature of the 4106 voucher means that the window to deliver a fake voucher is very 4107 short. A nonceless, long-lived voucher would be the only option for 4108 the attacker, and devices in the warehouse would be vulnerable to 4109 such a thing. 4111 A key operational recommendation is for manufacturers to sign 4112 nonceless, long-lived vouchers with a different key that they sign 4113 short-lived vouchers. That key needs significantly better 4114 protection. If both keys come from a common trust-anchor (the 4115 manufacturer's CA), then a compromise of the manufacturer's CA would 4116 compromise both keys. Such a compromise of the manufacturer's CA 4117 likely compromises all keys outlined in this section. 4119 11.6.3. Compromise of MASA web service 4121 An attacker that takes over the MASA web service has a number of 4122 attacks. The most obvious one is simply to take the database listing 4123 customers and devices and to sell this data to other attackers who 4124 will now know where to find potentially vulnerable devices. 4126 The second most obvious thing that the attacker can do is to kill the 4127 service, or make it operate unreliably, making customers frustrated. 4128 This could have a serious affect on ability to deploy new services by 4129 customers, and would be a significant issue during disaster recovery. 4131 While the compromise of the MASA web service may lead to the 4132 compromise of the MASA voucher signing key, if the signing occurs 4133 offboard (such as in a hardware signing module, HSM), then the key 4134 may well be safe, but control over it resides with the attacker. 4136 Such an attacker can issue vouchers for any device presently in 4137 service. Said device still needs to be convinced to do through a 4138 factory reset process before an attack. 4140 If the attacker has access to a key that is trusted for long-lived 4141 nonceless vouchers, then they could issue vouchers for devices which 4142 are not yet in service. This attack may be very hard to verify and 4143 as it would involve doing firmware updates on every device in 4144 warehouses (a potentially ruinously expensive process), a 4145 manufacturer might be reluctant to admit this possibility. 4147 11.7. YANG Module Security Considerations 4149 As described in the Security Considerations section of [RFC8366] 4150 (section 7.4), the YANG module specified in this document defines the 4151 schema for data that is subsequently encapsulated by a CMS signed- 4152 data content type, as described in Section 5 of [RFC5652]. As such, 4153 all of the YANG modeled data is protected from modification. 4155 The use of YANG to define data structures, via the 'yang-data' 4156 statement, is relatively new and distinct from the traditional use of 4157 YANG to define an API accessed by network management protocols such 4158 as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these 4159 guidelines do not follow template described by Section 3.7 of 4160 [RFC8407]. 4162 12. Acknowledgements 4164 We would like to thank the various reviewers for their input, in 4165 particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear, 4166 Sergey Kasatkin, Anoop Kumar, Tom Petch, Markus Stenberg, Peter van 4167 der Stok, and Thomas Werner 4169 Significant reviews were done by Jari Arko, Christian Huitema and 4170 Russ Housley. 4172 Henk Birkholz contributed the CDDL for the audit log response. 4174 This document started it's life as a two-page idea from Steinthor 4175 Bjarnason. 4177 In addition, significant review comments were received by many IESG 4178 members, including Adam Roach, Alexey Melnikov, Alissa Cooper, 4179 Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. 4181 13. References 4183 13.1. Normative References 4185 [I-D.ietf-anima-autonomic-control-plane] 4186 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 4187 Control Plane (ACP)", Work in Progress, Internet-Draft, 4188 draft-ietf-anima-autonomic-control-plane-22, 3 February 4189 2020, . 4192 [I-D.ietf-anima-grasp] 4193 Bormann, C., Carpenter, B., and B. Liu, "A Generic 4194 Autonomic Signaling Protocol (GRASP)", Work in Progress, 4195 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, 4196 . 4199 [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, 4200 . 4203 [ITU.X690.1994] 4204 International Telecommunications Union, "Information 4205 Technology - ASN.1 encoding rules: Specification of Basic 4206 Encoding Rules (BER), Canonical Encoding Rules (CER) and 4207 Distinguished Encoding Rules (DER)", ITU-T Recommendation 4208 X.690, 1994. 4210 [REST] Fielding, R.F., "Architectural Styles and the Design of 4211 Network-based Software Architectures", 2000, 4212 . 4215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4216 Requirement Levels", BCP 14, RFC 2119, 4217 DOI 10.17487/RFC2119, March 1997, 4218 . 4220 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4221 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4222 . 4224 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4225 DOI 10.17487/RFC3688, January 2004, 4226 . 4228 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 4229 Levkowetz, Ed., "Extensible Authentication Protocol 4230 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 4231 . 4233 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 4234 Configuration of IPv4 Link-Local Addresses", RFC 3927, 4235 DOI 10.17487/RFC3927, May 2005, 4236 . 4238 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 4239 "Randomness Requirements for Security", BCP 106, RFC 4086, 4240 DOI 10.17487/RFC4086, June 2005, 4241 . 4243 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 4244 (LDAP): Schema for User Applications", RFC 4519, 4245 DOI 10.17487/RFC4519, June 2006, 4246 . 4248 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 4249 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 4250 . 4252 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 4253 Address Autoconfiguration", RFC 4862, 4254 DOI 10.17487/RFC4862, September 2007, 4255 . 4257 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 4258 Extensions for Stateless Address Autoconfiguration in 4259 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 4260 . 4262 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 4263 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 4264 . 4266 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4267 Housley, R., and W. Polk, "Internet X.509 Public Key 4268 Infrastructure Certificate and Certificate Revocation List 4269 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4270 . 4272 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 4273 RFC 5652, DOI 10.17487/RFC5652, September 2009, 4274 . 4276 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 4277 the Network Configuration Protocol (NETCONF)", RFC 6020, 4278 DOI 10.17487/RFC6020, October 2010, 4279 . 4281 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 4282 Verification of Domain-Based Application Service Identity 4283 within Internet Public Key Infrastructure Using X.509 4284 (PKIX) Certificates in the Context of Transport Layer 4285 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 4286 2011, . 4288 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 4289 and A. Bierman, Ed., "Network Configuration Protocol 4290 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 4291 . 4293 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 4294 DOI 10.17487/RFC6762, February 2013, 4295 . 4297 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 4298 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 4299 . 4301 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4302 "Enrollment over Secure Transport", RFC 7030, 4303 DOI 10.17487/RFC7030, October 2013, 4304 . 4306 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 4307 Protocol (HTTP/1.1): Message Syntax and Routing", 4308 RFC 7230, DOI 10.17487/RFC7230, June 2014, 4309 . 4311 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 4312 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 4313 DOI 10.17487/RFC7231, June 2014, 4314 . 4316 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 4317 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 4318 2015, . 4320 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4321 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4322 . 4324 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4325 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4326 . 4328 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 4329 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 4330 . 4332 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4333 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4334 May 2017, . 4336 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 4337 Interchange Format", STD 90, RFC 8259, 4338 DOI 10.17487/RFC8259, December 2017, 4339 . 4341 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 4342 "A Voucher Artifact for Bootstrapping Protocols", 4343 RFC 8366, DOI 10.17487/RFC8366, May 2018, 4344 . 4346 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 4347 Control Plane for Stable Connectivity of Network 4348 Operations, Administration, and Maintenance (OAM)", 4349 RFC 8368, DOI 10.17487/RFC8368, May 2018, 4350 . 4352 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 4353 Documents Containing YANG Data Models", BCP 216, RFC 8407, 4354 DOI 10.17487/RFC8407, October 2018, 4355 . 4357 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4358 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4359 . 4361 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 4362 Definition Language (CDDL): A Notational Convention to 4363 Express Concise Binary Object Representation (CBOR) and 4364 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 4365 June 2019, . 4367 13.2. Informative References 4369 [brewski] "Urban Dictionary: Brewski", October 2019, 4370 . 4372 [cabforumaudit] 4373 "Information for Auditors and Assessors", August 2019, 4374 . 4377 [Dingledine2004] 4378 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 4379 second-generation onion router", 2004, 4380 . 4382 [dnssecroot] 4383 "DNSSEC Practice Statement for the Root Zone ZSK 4384 Operator", December 2017, 4385 . 4388 [docsisroot] 4389 "CableLabs Digital Certificate Issuance Service", February 4390 2018, . 4393 [I-D.ietf-ace-coap-est] 4394 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 4395 "EST over secure CoAP (EST-coaps)", Work in Progress, 4396 Internet-Draft, draft-ietf-ace-coap-est-18, 6 January 4397 2020, . 4400 [I-D.ietf-anima-constrained-voucher] 4401 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 4402 Voucher Artifacts for Bootstrapping Protocols", Work in 4403 Progress, Internet-Draft, draft-ietf-anima-constrained- 4404 voucher-07, 15 January 2020, . 4408 [I-D.ietf-anima-reference-model] 4409 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 4410 and J. Nobre, "A Reference Model for Autonomic 4411 Networking", Work in Progress, Internet-Draft, draft-ietf- 4412 anima-reference-model-10, 22 November 2018, 4413 . 4416 [I-D.ietf-netconf-keystore] 4417 Watsen, K., "A YANG Data Model for a Keystore", Work in 4418 Progress, Internet-Draft, draft-ietf-netconf-keystore-15, 4419 20 November 2019, . 4422 [I-D.richardson-anima-state-for-joinrouter] 4423 Richardson, M., "Considerations for stateful vs stateless 4424 join router in ANIMA bootstrap", Work in Progress, 4425 Internet-Draft, draft-richardson-anima-state-for- 4426 joinrouter-02, 25 January 2018, . 4430 [imprinting] 4431 "Wikipedia article: Imprinting", July 2015, 4432 . 4434 [IoTstrangeThings] 4435 "IoT of toys stranger than fiction: Cybersecurity and data 4436 privacy update (accessed 2018-12-02)", March 2017, 4437 . 4440 [livingwithIoT] 4441 "What is it actually like to live in a house filled with 4442 IoT devices? (accessed 2018-12-02)", February 2018, 4443 . 4446 [minerva] Richardsdon, M., "Minerva reference implementation for 4447 BRSKI", 2020, . 4449 [minervagithub] 4450 Richardsdon, M., "GITHUB hosting of Minerva reference 4451 code", 2020, . 4453 [openssl] "OpenSSL X509 utility", September 2019, 4454 . 4457 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 4458 Translator (NAT) Terminology and Considerations", 4459 RFC 2663, DOI 10.17487/RFC2663, August 1999, 4460 . 4462 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 4463 Tardo, "Network Endpoint Assessment (NEA): Overview and 4464 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 4465 . 4467 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 4468 Uniform Resource Identifiers (URIs)", RFC 5785, 4469 DOI 10.17487/RFC5785, April 2010, 4470 . 4472 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 4473 Galperin, S., and C. Adams, "X.509 Internet Public Key 4474 Infrastructure Online Certificate Status Protocol - OCSP", 4475 RFC 6960, DOI 10.17487/RFC6960, June 2013, 4476 . 4478 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 4479 Multiple Certificate Status Request Extension", RFC 6961, 4480 DOI 10.17487/RFC6961, June 2013, 4481 . 4483 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 4484 Constrained-Node Networks", RFC 7228, 4485 DOI 10.17487/RFC7228, May 2014, 4486 . 4488 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 4489 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 4490 2014, . 4492 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 4493 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 4494 December 2014, . 4496 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 4497 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 4498 Networking: Definitions and Design Goals", RFC 7575, 4499 DOI 10.17487/RFC7575, June 2015, 4500 . 4502 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4503 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4504 . 4506 [slowloris] 4507 "Slowloris (computer security)", February 2019, 4508 . 4511 [softwareescrow] 4512 "Wikipedia article: Software Escrow", October 2019, 4513 . 4515 [Stajano99theresurrecting] 4516 Stajano, F. and R. Anderson, "The resurrecting duckling: 4517 security issues for ad-hoc wireless networks", 1999, 4518 . 4521 [TR069] "TR-69: CPE WAN Management Protocol", February 2018, 4522 . 4525 [W3C.WD-capability-urls-20140218] 4526 Tennison, J., "Good Practices for Capability URLs", World 4527 Wide Web Consortium WD WD-capability-urls-20140218, 18 4528 February 2014, 4529 . 4531 Appendix A. IPv4 and non-ANI operations 4533 The specification of BRSKI in Section 4 intentionally only covers the 4534 mechanisms for an IPv6 pledge using Link-Local addresses. This 4535 section describes non-normative extensions that can be used in other 4536 environments. 4538 A.1. IPv4 Link Local addresses 4540 Instead of an IPv6 link-local address, an IPv4 address may be 4541 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 4542 Addresses. 4544 In the case that an IPv4 Link-Local address is formed, then the 4545 bootstrap process would continue as in the IPv6 case by looking for a 4546 (circuit) proxy. 4548 A.2. Use of DHCPv4 4550 The Pledge MAY obtain an IP address via DHCP [RFC2131]. The DHCP 4551 provided parameters for the Domain Name System can be used to perform 4552 DNS operations if all local discovery attempts fail. 4554 Appendix B. mDNS / DNSSD proxy discovery options 4556 Pledge discovery of the proxy (Section 4.1) MAY be performed with 4557 DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to 4558 discover the proxy at "_brski-proxy._tcp.local.". 4560 Proxy discovery of the registrar (Section 4.3) MAY be performed with 4561 DNS-based Service Discovery over Multicast DNS to discover registrars 4562 by searching for the service "_brski-registrar._tcp.local.". 4564 To prevent unaccceptable levels of network traffic, when using mDNS, 4565 the congestion avoidance mechanisms specified in [RFC6762] section 7 4566 MUST be followed. The pledge SHOULD listen for an unsolicited 4567 broadcast response as described in [RFC6762]. This allows devices to 4568 avoid announcing their presence via mDNS broadcasts and instead 4569 silently join a network by watching for periodic unsolicited 4570 broadcast responses. 4572 Discovery of registrar MAY also be performed with DNS-based service 4573 discovery by searching for the service "_brski- 4574 registrar._tcp.". In this case the domain "example.com" is 4575 discovered as described in [RFC6763] section 11 (Appendix A.2 4576 suggests the use of DHCP parameters). 4578 If no local proxy or registrar service is located using the GRASP 4579 mechanisms or the above mentioned DNS-based Service Discovery 4580 methods, the pledge MAY contact a well known manufacturer provided 4581 bootstrapping server by performing a DNS lookup using a well known 4582 URI such as "brski-registrar.manufacturer.example.com". The details 4583 of the URI are manufacturer specific. Manufacturers that leverage 4584 this method on the pledge are responsible for providing the registrar 4585 service. Also see Section 2.7. 4587 The current DNS services returned during each query are maintained 4588 until bootstrapping is completed. If bootstrapping fails and the 4589 pledge returns to the Discovery state, it picks up where it left off 4590 and continues attempting bootstrapping. For example, if the first 4591 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 4592 second and third responses are tried. If these fail the pledge moves 4593 on to normal DNS-based Service Discovery. 4595 Appendix C. Example Vouchers 4597 Three entities are involved in a voucher: the MASA issues (signs) it, 4598 the registrar's public key is mentioned in the voucher, and the 4599 pledge validates it. In order to provide reproduceable examples the 4600 public and private keys for an example MASA and registrar are first 4601 listed. 4603 The keys come from an open source reference implementation of BRSKI, 4604 called "Minerva" [minerva]. It is available on github 4605 [minervagithub]. The keys presented here are used in the unit and 4606 integration tests. The MASA code is called "highway", the Registrar 4607 code is called "fountain", and the example client is called "reach". 4609 The public key components of each are presented as both base64 4610 certificates, as well as being decoded by openssl's x509 utility so 4611 that the extensions can be seen. This was version 1.1.1c of the 4612 [openssl] library and utility. 4614 C.1. Keys involved 4616 The Manufacturer has a Certificate Authority that signs the pledge's 4617 IDevID. In addition the Manufacturer's signing authority (the MASA) 4618 signs the vouchers, and that certificate must distributed to the 4619 devices at manufacturing time so that vouchers can be validated. 4621 C.1.1. Manufacturer Certificate Authority for IDevID signatures 4623 This private key is Certificate Authority that signs IDevID 4624 certificates: 4626 file "vendor.key" 4627 -----BEGIN EC PRIVATE KEY----- 4628 MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G 4629 8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH 4630 L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP 4631 juF8QkoAbT8pMrY83MS8y76wZ7AalNQ= 4632 -----END EC PRIVATE KEY----- 4633 4635 This public key validates IDevID certificates: 4637 file: examples/vendor.key 4639 file "vendor.cert" 4640 Certificate: 4641 Data: 4642 Version: 3 (0x2) 4643 Serial Number: 519772114 (0x1efb17d2) 4644 Signature Algorithm: ecdsa-with-SHA256 4645 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA 4646 Validity 4647 Not Before: Feb 12 22:22:21 2019 GMT 4648 Not After : Feb 11 22:22:21 2021 GMT 4649 Subject: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA 4650 Subject Public Key Info: 4651 Public Key Algorithm: id-ecPublicKey 4652 Public-Key: (384 bit) 4653 pub: 4654 04:2e:e7:fc:a4:b4:96:c5:2e:33:02:f3:b8:7b:6f: 4655 ec:93:ad:e1:6e:17:c1:b0:7b:02:87:2f:89:92:d2: 4656 bd:1d:54:04:2e:6e:a0:d4:41:c4:eb:8e:fa:57:ad: 4657 70:a9:4e:88:e2:2c:2c:e0:a7:c7:f3:91:c5:03:91: 4658 9f:4b:0f:f3:3d:d0:b0:e2:a6:22:cd:20:e9:0f:8e: 4659 e1:7c:42:4a:00:6d:3f:29:32:b6:3c:dc:c4:bc:cb: 4660 be:b0:67:b0:1a:94:d4 4661 ASN1 OID: secp384r1 4662 NIST CURVE: P-384 4663 X509v3 extensions: 4664 X509v3 Basic Constraints: critical 4665 CA:TRUE 4666 X509v3 Key Usage: critical 4667 Certificate Sign, CRL Sign 4668 X509v3 Subject Key Identifier: 4670 5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76:8C:53:8A:08 4671 X509v3 Authority Key Identifier: 4672 keyid:5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76:8C:53:8A:08 4674 Signature Algorithm: ecdsa-with-SHA256 4675 30:65:02:30:5f:21:fd:c6:ab:d6:94:a6:cd:ca:37:2c:81:33: 4676 87:fe:7b:e1:b5:1a:e8:6c:05:43:a6:8b:4e:22:b5:55:e9:48: 4677 0c:b5:97:f3:c9:1a:65:d9:97:4b:f0:21:86:0d:cb:26:02:31: 4678 00:e3:2d:0d:08:49:4d:a3:f5:dc:57:1f:a7:13:26:a4:e0:d6: 4679 3a:c2:d5:4a:50:83:62:26:2e:79:2b:d0:a5:ee:66:d5:bf:16: 4680 9a:33:75:b4:d1:8d:ba:d3:50:77:6b:92:df 4681 -----BEGIN CERTIFICATE----- 4682 MIICTDCCAdKgAwIBAgIEHvsX0jAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h 4683 ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE 4684 AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjIyMVoX 4685 DTIxMDIxMTIyMjIyMVowXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh 4686 cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l 4687 eGFtcGxlLmNvbSBDQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABC7n/KS0lsUuMwLz 4688 uHtv7JOt4W4XwbB7AocviZLSvR1UBC5uoNRBxOuO+letcKlOiOIsLOCnx/ORxQOR 4689 n0sP8z3QsOKmIs0g6Q+O4XxCSgBtPykytjzcxLzLvrBnsBqU1KNjMGEwDwYDVR0T 4690 AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFF4MqVJajN+pDwMU 4691 6ZbxgHaMU4oIMB8GA1UdIwQYMBaAFF4MqVJajN+pDwMU6ZbxgHaMU4oIMAoGCCqG 4692 SM49BAMCA2gAMGUCMF8h/car1pSmzco3LIEzh/574bUa6GwFQ6aLTiK1VelIDLWX 4693 88kaZdmXS/Ahhg3LJgIxAOMtDQhJTaP13FcfpxMmpODWOsLVSlCDYiYueSvQpe5m 4694 1b8WmjN1tNGNutNQd2uS3w== 4695 -----END CERTIFICATE----- 4696 4698 C.1.2. MASA key pair for voucher signatures 4700 The MASA is the Manufacturer Authorized Signing Authority. This 4701 keypair signs vouchers. An example TLS certificate Section 5.4 HTTP 4702 authentication is not provided as it is a common form. 4704 This private key signs the vouchers which are presented below: 4706 file "masa.key" 4707 -----BEGIN EC PRIVATE KEY----- 4708 MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 4709 AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ 4710 gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== 4711 -----END EC PRIVATE KEY----- 4712 4714 This public key validates vouchers, and it has been signed by the CA 4715 above: 4717 file: examples/masa.key 4718 file "masa.cert" 4719 Certificate: 4720 Data: 4721 Version: 3 (0x2) 4722 Serial Number: 463036244 (0x1b995f54) 4723 Signature Algorithm: ecdsa-with-SHA256 4724 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA 4725 Validity 4726 Not Before: Feb 12 22:22:41 2019 GMT 4727 Not After : Feb 11 22:22:41 2021 GMT 4728 Subject: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com MASA 4729 Subject Public Key Info: 4730 Public Key Algorithm: id-ecPublicKey 4731 Public-Key: (256 bit) 4732 pub: 4733 04:aa:04:15:a3:44:b9:e2:44:f8:c9:f9:1b:07:1b: 4734 a6:74:73:9c:1e:ba:6c:a9:b3:a9:30:a9:a2:32:59: 4735 f7:a0:1d:47:01:6d:b9:30:95:7e:82:a8:b8:b4:c1: 4736 5f:48:9d:22:13:0b:7c:92:cc:df:59:72:b8:ac:b8: 4737 09:4b:69:a7:a5 4738 ASN1 OID: prime256v1 4739 NIST CURVE: P-256 4740 X509v3 extensions: 4741 X509v3 Basic Constraints: critical 4742 CA:FALSE 4743 Signature Algorithm: ecdsa-with-SHA256 4744 30:66:02:31:00:bd:55:e5:9b:0e:fb:fc:5e:95:29:e3:81:b3: 4745 15:35:aa:93:18:a2:04:be:44:72:b2:51:7d:4d:6d:eb:d1:d5: 4746 c1:10:3a:b2:39:7b:57:3f:c5:cc:b0:a3:0e:e7:99:46:ba:02: 4747 31:00:f6:7f:44:7d:b7:14:fa:d1:67:6a:d4:11:c3:4b:ae:e6: 4748 fb:9a:98:56:fa:85:21:2e:5c:48:4c:f0:3f:f2:9b:3f:ae:88: 4749 20:a7:ae:f9:72:ff:5b:f9:78:68:cf:0f:48:c9 4750 -----BEGIN CERTIFICATE----- 4751 MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h 4752 ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE 4753 AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX 4754 DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh 4755 cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l 4756 eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5 4757 4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf 4758 WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA 4759 vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6 4760 AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP 4761 D0jJ 4762 -----END CERTIFICATE----- 4763 4765 C.1.3. Registrar Certificate Authority 4767 This Certificate Authority enrolls the pledge once it is authorized, 4768 and it also signs the Registrar's certificate. 4770 file "ownerca_secp384r1.key" 4771 -----BEGIN EC PRIVATE KEY----- 4772 MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R 4773 EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW 4774 gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd 4775 0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ= 4776 -----END EC PRIVATE KEY----- 4777 4779 The public key is indicated in a pledge voucher-request to show 4780 proximity. 4782 file: examples/ownerca_secp384r1.key 4784 file "ownerca_secp384r1.cert" 4785 Certificate: 4786 Data: 4787 Version: 3 (0x2) 4788 Serial Number: 694879833 (0x296b0659) 4789 Signature Algorithm: ecdsa-with-SHA256 4790 Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Fountain Root CA 4791 Validity 4792 Not Before: Feb 25 21:31:45 2020 GMT 4793 Not After : Feb 24 21:31:45 2022 GMT 4794 Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Fountain Root CA 4795 Subject Public Key Info: 4796 Public Key Algorithm: id-ecPublicKey 4797 Public-Key: (384 bit) 4798 pub: 4799 04:1b:7f:59:ba:17:c3:1a:bc:66:8d:8c:6c:e0:c3: 4800 fa:31:71:0f:65:f6:22:91:bd:b7:56:80:07:db:df: 4801 b8:7a:a5:45:4d:79:8a:46:97:19:59:96:31:b1:8f: 4802 69:7d:32:be:3c:c8:3e:5b:63:b5:46:f6:a8:d5:6f: 4803 9b:f9:c0:f3:d3:b9:14:3f:72:47:51:a4:76:dd:d2: 4804 f0:bf:f5:ca:8f:30:01:7f:f8:c2:5f:d3:f5:20:03: 4805 44:8b:8b:f2:07:6c:b4 4806 ASN1 OID: secp384r1 4807 NIST CURVE: P-384 4808 X509v3 extensions: 4809 X509v3 Basic Constraints: critical 4810 CA:TRUE 4811 X509v3 Key Usage: critical 4812 Certificate Sign, CRL Sign 4814 X509v3 Subject Key Identifier: 4815 B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC:87:B3:74:26 4816 X509v3 Authority Key Identifier: 4817 keyid:B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC:87:B3:74:26 4819 Signature Algorithm: ecdsa-with-SHA256 4820 30:64:02:30:20:83:06:ce:8d:98:a4:54:7a:66:4c:4a:3a:70: 4821 c2:52:36:5a:52:8d:59:7d:20:9b:2a:69:14:58:87:38:d8:55: 4822 79:dd:fd:29:38:95:1e:91:93:76:b4:f5:66:29:44:b4:02:30: 4823 6f:38:f9:af:12:ed:30:d5:85:29:7c:b1:16:58:bd:67:91:43: 4824 c4:0d:30:f9:d8:1c:ac:2f:06:dd:bc:d5:06:42:2c:84:a2:04: 4825 ea:02:a4:5f:17:51:26:fb:d9:2f:d2:5c 4826 -----BEGIN CERTIFICATE----- 4827 MIICazCCAfKgAwIBAgIEKWsGWTAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB 4828 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50 4829 YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe 4830 Fw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0xEjAQBgoJkiaJk/IsZAEZ 4831 FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRh 4832 aW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMHYw 4833 EAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYikb23VoAH 4834 29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR23dLw 4835 v/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud 4836 DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0j 4837 BBgwFoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMG 4838 zo2YpFR6ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBv 4839 OPmvEu0w1YUpfLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lw= 4840 -----END CERTIFICATE----- 4841 4843 C.1.4. Registrar key pair 4845 The Registrar is the representative of the domain owner. This key 4846 signs registrar voucher-requests, and terminates the TLS connection 4847 from the pledge. 4849 file "jrc_prime256v1.key" 4850 -----BEGIN EC PRIVATE KEY----- 4851 MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 4852 AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E 4853 jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== 4854 -----END EC PRIVATE KEY----- 4855 4857 The public key is indicated in a pledge voucher-request to show 4858 proximity. 4860 file "jrc_prime256v1.cert" 4861 Certificate: 4862 Data: 4863 Version: 3 (0x2) 4864 Serial Number: 1066965842 (0x3f989b52) 4865 Signature Algorithm: ecdsa-with-SHA256 4866 Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Fountain Root CA 4867 Validity 4868 Not Before: Feb 25 21:31:54 2020 GMT 4869 Not After : Feb 24 21:31:54 2022 GMT 4870 Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com 4871 Subject Public Key Info: 4872 Public Key Algorithm: id-ecPublicKey 4873 Public-Key: (256 bit) 4874 pub: 4875 04:96:65:50:72:34:ba:9f:e5:dd:e6:5f:f6:f0:81: 4876 6f:e9:48:9e:81:0c:12:07:3b:46:8f:97:64:2b:63: 4877 00:8d:02:0f:57:c9:7c:94:7f:84:8c:b2:0e:61:d6: 4878 c9:88:8d:15:b4:42:1f:d7:f2:6a:b7:e4:ce:05:f8: 4879 a7:4c:d3:8b:3a 4880 ASN1 OID: prime256v1 4881 NIST CURVE: P-256 4882 X509v3 extensions: 4883 X509v3 Extended Key Usage: critical 4884 CMC Registration Authority 4885 X509v3 Key Usage: critical 4886 Digital Signature 4887 Signature Algorithm: ecdsa-with-SHA256 4888 30:65:02:30:66:4f:60:4c:55:48:1e:96:07:f8:dd:1f:b9:c8: 4889 12:8d:45:36:87:9b:23:c0:bc:bb:f1:cb:3d:26:15:56:6f:5f: 4890 1f:bf:d5:1c:0e:6a:09:af:1b:76:97:99:19:23:fd:7e:02:31: 4891 00:bc:ac:c3:41:b0:ba:0d:af:52:f9:9c:6e:7a:7f:00:1d:23: 4892 c8:62:01:61:bc:4b:c5:c0:47:99:35:0a:0c:77:61:44:01:4a: 4893 07:52:70:57:00:75:ff:be:07:0e:98:cb:e5 4894 -----BEGIN CERTIFICATE----- 4895 MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB 4896 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50 4897 YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe 4898 Fw0yMDAyMjUyMTMxNTRaFw0yMjAyMjQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZ 4899 FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRh 4900 aW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZl 4901 UHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRC 4902 H9fyarfkzgX4p0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1Ud 4903 DwEB/wQEAwIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaH 4904 myPAvLvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAd 4905 I8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U= 4906 -----END CERTIFICATE----- 4907 4909 C.1.5. Pledge key pair 4911 The pledge has an IDevID key pair built in at manufacturing time: 4913 file "idevid_00-D0-E5-F2-00-02.key" 4914 -----BEGIN EC PRIVATE KEY----- 4915 MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49 4916 AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx 4917 FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw== 4918 -----END EC PRIVATE KEY----- 4919 4921 The public key is used by the registrar to find the MASA. 4923 file "idevid_00-D0-E5-F2-00-02.cert" 4924 Certificate: 4925 Data: 4926 Version: 3 (0x2) 4927 Serial Number: 226876461 (0xd85dc2d) 4928 Signature Algorithm: ecdsa-with-SHA256 4929 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA 4930 Validity 4931 Not Before: Feb 3 06:47:20 2020 GMT 4932 Not After : Dec 31 00:00:00 2999 GMT 4933 Subject: serialNumber = 00-D0-E5-F2-00-02 4934 Subject Public Key Info: 4935 Public Key Algorithm: id-ecPublicKey 4936 Public-Key: (256 bit) 4937 pub: 4938 04:03:a3:75:43:87:b3:7c:c0:0a:9a:87:9c:ad:f6: 4939 f4:38:13:1c:d4:0c:84:1f:e0:40:4e:41:79:f0:5b: 4940 13:4b:20:71:b3:44:9b:49:62:f1:16:30:ce:bb:00: 4941 7d:80:b1:a7:d9:3b:13:50:9b:a6:27:a5:4f:c3:96: 4942 7f:4c:fe:21:27 4943 ASN1 OID: prime256v1 4944 NIST CURVE: P-256 4945 X509v3 extensions: 4946 X509v3 Subject Key Identifier: 4947 45:88:CC:96:96:00:64:37:B0:BA:23:65:64:64:54:08:06:6C:56:AD 4948 X509v3 Basic Constraints: 4949 CA:FALSE 4950 1.3.6.1.5.5.7.1.32: 4951 ..highway-test.example.com:9443 4952 Signature Algorithm: ecdsa-with-SHA256 4953 30:65:02:30:23:e1:a9:2e:ef:22:12:34:5a:a5:c2:15:d6:28: 4954 bd:ed:3d:96:d6:ce:04:95:ef:a7:c8:dc:18:a8:31:c7:b8:04: 4955 34:f2:b7:4d:79:8a:67:22:24:03:4f:c5:cd:d6:06:ba:02:31: 4956 00:b3:8d:5c:0a:d0:fe:04:83:90:d3:4f:6d:72:97:b3:3e:02: 4958 ea:f1:c8:5a:32:72:58:b7:45:02:50:78:bc:04:1d:23:5e:22: 4959 6f:c3:7f:8c:7c:d7:9b:70:20:91:b4:e1:7f 4960 -----BEGIN CERTIFICATE----- 4961 MIIB5jCCAWygAwIBAgIEDYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h 4962 ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE 4963 AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoY 4964 DzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZ 4965 MBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/g 4966 QE5BefBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0G 4967 A1UdDgQWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUF 4968 BwEgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMC 4969 A2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TXmKZyIk 4970 A0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vAQdI14ib8N/ 4971 jHzXm3AgkbThfw== 4972 -----END CERTIFICATE----- 4973 4975 C.2. Example process 4977 The JSON examples below are wrapped at 60 columns. This results in 4978 strings that have newlines in them, which makes them invalid JSON as 4979 is. The strings would otherwise be too long, so they need to be 4980 unwrapped before processing. 4982 C.2.1. Pledge to Registrar 4984 As described in Section 5.2, the pledge will sign a pledge voucher- 4985 request containing the registrar's public key in the proximity- 4986 registrar-cert field. The base64 has been wrapped at 60 characters 4987 for presentation reasons. 4989 file "vr_00-D0-E5-F2-00-02.b64" 4990 MIIG3gYJKoZIhvcNAQcCoIIGzzCCBssCAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGg 4991 ggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 4992 aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxNjozMzoxMS45ODQtMDU6MDAiLCJzZXJp 4993 YWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6InkyQmZOYUlTMEtKU3loS2Ft 4994 VEdYYVEiLCJwcm94aW1pdHktcmVnaXN0cmFyLWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1 4995 aWJVakFLQmdncWhrak9QUVFEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdv 4996 SmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJs 4997 YzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVG 4998 dzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsv 4999 SXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFV 5000 RUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VH 5001 Q0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNCYitsSW5vRU1FZ2M3Um8rWFpDdGpB 5002 STBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0Ex 5003 VWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtq 5004 T1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2 5005 WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhT 5006 OFhBUjVrMUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIE 5007 DYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW8xEjAQ 5008 BgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAX 5009 DTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0w 5010 MC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5B 5011 efBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDgQWBBRFiMyW 5012 lgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBwEgBB8MHWhpZ2h3YXktdGVzdC5l 5013 eGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXv 5014 p8jcGKgxx7gENPK3TXmKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4 5015 vAQdI14ib8N/jHzXm3AgkbThfzGCATowggE2AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYD 5016 VQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l 5017 eGFtcGxlLmNvbSBDQQIEDYXcLTALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN 5018 AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMjUyMTMzMTFaMC8GCSqGSIb3DQEJBDEiBCB0yBo/clJ6 5019 GlTKYRILxPrHxYFL9+4MAL0/DavOh/IkETAKBggqhkjOPQQDAgRGMEQCIFpErwe+ypjpXtYpnsIZ 5020 FsfoLFIOfH1p2p+Cr3eo4F1tAiAhvsI/GRsBd2LP7ZA+W0b+sBXwc2heR19a+LV5hwLIOg== 5021 5023 The ASN1 decoding of the artifact: 5025 file: examples/vr_00-D0-E5-F2-00-02.b64 5027 0:d=0 hl=4 l=1758 cons: SEQUENCE 5028 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 5029 15:d=1 hl=4 l=1743 cons: cont [ 0 ] 5030 19:d=2 hl=4 l=1739 cons: SEQUENCE 5031 23:d=3 hl=2 l= 1 prim: INTEGER :01 5032 26:d=3 hl=2 l= 13 cons: SET 5033 28:d=4 hl=2 l= 11 cons: SEQUENCE 5034 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 5035 41:d=3 hl=4 l= 905 cons: SEQUENCE 5036 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 5037 56:d=4 hl=4 l= 890 cons: cont [ 0 ] 5038 60:d=5 hl=4 l= 886 prim: OCTET STRING :{"ietf-voucher-request:v 5039 950:d=3 hl=4 l= 490 cons: cont [ 0 ] 5040 954:d=4 hl=4 l= 486 cons: SEQUENCE 5041 958:d=5 hl=4 l= 364 cons: SEQUENCE 5042 962:d=6 hl=2 l= 3 cons: cont [ 0 ] 5043 964:d=7 hl=2 l= 1 prim: INTEGER :02 5044 967:d=6 hl=2 l= 4 prim: INTEGER :0D85DC2D 5045 973:d=6 hl=2 l= 10 cons: SEQUENCE 5046 975:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5047 985:d=6 hl=2 l= 93 cons: SEQUENCE 5048 987:d=7 hl=2 l= 15 cons: SET 5049 989:d=8 hl=2 l= 13 cons: SEQUENCE 5050 991:d=9 hl=2 l= 3 prim: OBJECT :countryName 5051 996:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 5052 1004:d=7 hl=2 l= 16 cons: SET 5053 1006:d=8 hl=2 l= 14 cons: SEQUENCE 5054 1008:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 5055 1013:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 5056 1022:d=7 hl=2 l= 18 cons: SET 5057 1024:d=8 hl=2 l= 16 cons: SEQUENCE 5058 1026:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 5059 1031:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 5060 1042:d=7 hl=2 l= 36 cons: SET 5061 1044:d=8 hl=2 l= 34 cons: SEQUENCE 5062 1046:d=9 hl=2 l= 3 prim: OBJECT :commonName 5063 1051:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 5064 1080:d=6 hl=2 l= 32 cons: SEQUENCE 5065 1082:d=7 hl=2 l= 13 prim: UTCTIME :200203064720Z 5066 1097:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z 5067 1114:d=6 hl=2 l= 28 cons: SEQUENCE 5068 1116:d=7 hl=2 l= 26 cons: SET 5069 1118:d=8 hl=2 l= 24 cons: SEQUENCE 5070 1120:d=9 hl=2 l= 3 prim: OBJECT :serialNumber 5071 1125:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2-00-02 5072 1144:d=6 hl=2 l= 89 cons: SEQUENCE 5073 1146:d=7 hl=2 l= 19 cons: SEQUENCE 5074 1148:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 5075 1157:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 5076 1167:d=7 hl=2 l= 66 prim: BIT STRING 5077 1235:d=6 hl=2 l= 89 cons: cont [ 3 ] 5078 1237:d=7 hl=2 l= 87 cons: SEQUENCE 5079 1239:d=8 hl=2 l= 29 cons: SEQUENCE 5080 1241:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 5081 1246:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04144588CC9696 5082 1270:d=8 hl=2 l= 9 cons: SEQUENCE 5083 1272:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 5084 1277:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 5085 1281:d=8 hl=2 l= 43 cons: SEQUENCE 5086 1283:d=9 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.1.32 5087 1293:d=9 hl=2 l= 31 prim: OCTET STRING [HEX DUMP]:0C1D6869676877 5088 1326:d=5 hl=2 l= 10 cons: SEQUENCE 5089 1328:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5090 1338:d=5 hl=2 l= 104 prim: BIT STRING 5091 1444:d=3 hl=4 l= 314 cons: SET 5092 1448:d=4 hl=4 l= 310 cons: SEQUENCE 5093 1452:d=5 hl=2 l= 1 prim: INTEGER :01 5094 1455:d=5 hl=2 l= 101 cons: SEQUENCE 5095 1457:d=6 hl=2 l= 93 cons: SEQUENCE 5096 1459:d=7 hl=2 l= 15 cons: SET 5097 1461:d=8 hl=2 l= 13 cons: SEQUENCE 5098 1463:d=9 hl=2 l= 3 prim: OBJECT :countryName 5099 1468:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 5100 1476:d=7 hl=2 l= 16 cons: SET 5101 1478:d=8 hl=2 l= 14 cons: SEQUENCE 5102 1480:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 5103 1485:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 5104 1494:d=7 hl=2 l= 18 cons: SET 5105 1496:d=8 hl=2 l= 16 cons: SEQUENCE 5106 1498:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 5107 1503:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 5108 1514:d=7 hl=2 l= 36 cons: SET 5109 1516:d=8 hl=2 l= 34 cons: SEQUENCE 5110 1518:d=9 hl=2 l= 3 prim: OBJECT :commonName 5111 1523:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 5112 1552:d=6 hl=2 l= 4 prim: INTEGER :0D85DC2D 5113 1558:d=5 hl=2 l= 11 cons: SEQUENCE 5114 1560:d=6 hl=2 l= 9 prim: OBJECT :sha256 5115 1571:d=5 hl=2 l= 105 cons: cont [ 0 ] 5116 1573:d=6 hl=2 l= 24 cons: SEQUENCE 5117 1575:d=7 hl=2 l= 9 prim: OBJECT :contentType 5118 1586:d=7 hl=2 l= 11 cons: SET 5119 1588:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 5120 1599:d=6 hl=2 l= 28 cons: SEQUENCE 5121 1601:d=7 hl=2 l= 9 prim: OBJECT :signingTime 5122 1612:d=7 hl=2 l= 15 cons: SET 5123 1614:d=8 hl=2 l= 13 prim: UTCTIME :200225213311Z 5124 1629:d=6 hl=2 l= 47 cons: SEQUENCE 5125 1631:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 5126 1642:d=7 hl=2 l= 34 cons: SET 5127 1644:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:74C81A3F72527A 5128 1678:d=5 hl=2 l= 10 cons: SEQUENCE 5129 1680:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5130 1690:d=5 hl=2 l= 70 prim: OCTET STRING [HEX DUMP]:304402205A44AF 5132 The JSON contained in the voucher request: 5134 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr 5135 eated-on":"2020-02-25T16:33:11.984-05:00","serial-number":"0 5136 0-D0-E5-F2-00-02","nonce":"y2BfNaIS0KJSyhKamTGXaQ","proximit 5137 y-registrar-cert":"MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDA 5138 jBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZ 5139 WxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zd 5140 HJ1bmcgRm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNTRaFw0yMjAyM 5141 jQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkA 5142 RkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRhaW4tdGVzdC5leGFtcGxlL 5143 mNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb 5144 +lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p 5145 0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1UdDwEB/wQEA 5146 wIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaHmyPAv 5147 Lvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAdI 5148 8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}} 5150 C.2.2. Registrar to MASA 5152 As described in Section 5.5 the registrar will sign a registrar 5153 voucher-request, and will include pledge's voucher request in the 5154 prior-signed-voucher-request. 5156 file "parboiled_vr_00-D0-E5-F2-00-02.b64" 5157 MIIP9wYJKoZIhvcNAQcCoIIP6DCCD+QCAQExDTALBglghkgBZQMEAgEwggoMBgkqhkiG9w0BBwGg 5158 ggn9BIIJ+XsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 5159 aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQyMzowNDo0OS4wNTRaIiwic2VyaWFsLW51 5160 bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdR 5161 IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6Ik1JSUczd1lKS29aSWh2Y05BUWNDb0lJ 5162 RzBEQ0NCc3dDQVFFeERUQUxCZ2xnaGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042 5163 QklJRGRuc2lhV1YwWmkxMmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxj 5164 blJwYjI0aU9pSndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNQzB3TWkweU5W 5165 UXhPRG93TkRvME9DNDJOVEl0TURVNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0UkRB 5166 dFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJbUZOYW1kMVpVdFZWQzB5TW5kV2FXMXFObm95 5167 TjFFaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9pSk5TVWxDTDBSRFEwRlpT 5168 MmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFVVkZFUVdwQ2RFMVNTWGRGUVZsTFEx 5169 cEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZUW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhw 5170 WlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1kT1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5S 5171 ZFZwWWFHaGlXRUp6V2xNMWFtSXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZi 5172 VGwyWkVOQ1JGRlVRV1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVV 5173 MVVUWGhPVkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O 5174 SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFURlZSVUYz 5175 ZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9kbUpVUWxwTlFrMUhR 5176 bmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpLV214VlNFa3dkWEF2YkRObFdt 5177 WTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdwQlNUQkRSREZtU21aS1VpOW9TWGw1Ukcx 5178 SVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10NloxZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JL 5179 VVVWQ0wzZFJUVTFCYjBkRFEzTkhRVkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpT 5180 R2RFUVV0Q1oyZHhhR3RxVDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVp 5181 czFlVUpMVGxKVVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cx 5182 U2Eyb3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRPRmhC 5183 VWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJnZ2dIcU1JSUI1 5184 akNDQVd5Z0F3SUJBZ0lFRFlYY0xUQUtCZ2dxaGtqT1BRUURBakJkTVE4d0RRWURWUVFHRXdaRFlX 5185 NWhaR0V4RURBT0JnTlZCQWdNQjA5dWRHRnlhVzh4RWpBUUJnTlZCQXNNQ1ZOaGJtUmxiRzFoYmpF 5186 a01DSUdBMVVFQXd3YmFHbG5hSGRoZVMxMFpYTjBMbVY0WVcxd2JHVXVZMjl0SUVOQk1DQVhEVEl3 5187 TURJd016QTJORGN5TUZvWUR6STVPVGt4TWpNeE1EQXdNREF3V2pBY01Sb3dHQVlEVlFRRkRCRXdN 5188 QzFFTUMxRk5TMUdNaTB3TUMwd01qQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJB 5189 T2pkVU9IczN6QUNwcUhuSzMyOURnVEhOUU1oQi9nUUU1QmVmQmJFMHNnY2JORW0wbGk4Ull3enJz 5190 QWZZQ3hwOWs3RTFDYnBpZWxUOE9XZjB6K0lTZWpXVEJYTUIwR0ExVWREZ1FXQkJSRmlNeVdsZ0Jr 5191 TjdDNkkyVmtaRlFJQm14V3JUQUpCZ05WSFJNRUFqQUFNQ3NHQ0NzR0FRVUZCd0VnQkI4TUhXaHBa 5192 MmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlRvNU5EUXpNQW9HQ0NxR1NNNDlCQU1DQTJnQU1H 5193 VUNNQ1BocVM3dkloSTBXcVhDRmRZb3ZlMDlsdGJPQkpYdnA4amNHS2d4eDdnRU5QSzNUWG1LWnlJ 5194 a0EwL0Z6ZFlHdWdJeEFMT05YQXJRL2dTRGtOTlBiWEtYc3o0QzZ2SElXakp5V0xkRkFsQjR2QVFk 5195 STE0aWI4Ti9qSHpYbTNBZ2tiVGhmekdDQVRzd2dnRTNBZ0VCTUdVd1hURVBNQTBHQTFVRUJoTUdR 5196 MkZ1WVdSaE1SQXdEZ1lEVlFRSURBZFBiblJoY21sdk1SSXdFQVlEVlFRTERBbFRZVzVrWld4dFlX 5197 NHhKREFpQmdOVkJBTU1HMmhwWjJoM1lYa3RkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJTQkRRUUlFRFlY 5198 Y0xUQUxCZ2xnaGtnQlpRTUVBZ0dnYVRBWUJna3Foa2lHOXcwQkNRTXhDd1lKS29aSWh2Y05BUWNC 5199 TUJ3R0NTcUdTSWIzRFFFSkJURVBGdzB5TURBeU1qVXlNekEwTkRoYU1DOEdDU3FHU0liM0RRRUpC 5200 REVpQkNDeDZJcndzdEhGNjA5WTBFcURLNjJRS2J5NGR1eXlJV3VkdnMxNU0xNkJCVEFLQmdncWhr 5201 ak9QUVFEQWdSSE1FVUNJQnh3QTFVbGtJa3VRRGYvajdrWi9NVmVmZ3IxNDEraEtCRmdybk5uZ2p3 5202 cEFpRUF5OGFYdDBHU0I5bTFibWlFVXBlZkNFaHhTdjJ4TFl1ckdsdWd2MGRmci9FPSJ9faCCBG8w 5203 ggH8MIIBgqADAgECAgQ/mJtSMAoGCCqGSM49BAMCMG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcG 5204 CgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNv 5205 bSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTIwMDIyNTIxMzE1NFoXDTIyMDIyNDIxMzE1 5206 NFowUzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYD 5207 VQQDDBlmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 5208 lmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0VtEIf1/Jqt+TO 5209 BfinTNOLOqMqMCgwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAxwwDgYDVR0PAQH/BAQDAgeAMAoGCCqG 5210 SM49BAMCA2gAMGUCMGZPYExVSB6WB/jdH7nIEo1FNoebI8C8u/HLPSYVVm9fH7/VHA5qCa8bdpeZ 5211 GSP9fgIxALysw0Gwug2vUvmcbnp/AB0jyGIBYbxLxcBHmTUKDHdhRAFKB1JwVwB1/74HDpjL5TCC 5212 AmswggHyoAMCAQICBClrBlkwCgYIKoZIzj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 5213 CZImiZPyLGQBGRYJc2FuZGVsbWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29t 5214 IFVuc3RydW5nIEZvdW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTQ1WhcNMjIwMjI0MjEzMTQ1 5215 WjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNV 5216 BAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTB2 5217 MBAGByqGSM49AgEGBSuBBAAiA2IABBt/WboXwxq8Zo2MbODD+jFxD2X2IpG9t1aAB9vfuHqlRU15 5218 ikaXGVmWMbGPaX0yvjzIPltjtUb2qNVvm/nA89O5FD9yR1Gkdt3S8L/1yo8wAX/4wl/T9SADRIuL 5219 8gdstKNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLml9ssR 5220 4QekSSynCMZ8ELyHs3QmMB8GA1UdIwQYMBaAFLml9ssR4QekSSynCMZ8ELyHs3QmMAoGCCqGSM49 5221 BAMCA2cAMGQCMCCDBs6NmKRUemZMSjpwwlI2WlKNWX0gmyppFFiHONhVed39KTiVHpGTdrT1ZilE 5222 tAIwbzj5rxLtMNWFKXyxFli9Z5FDxA0w+dgcrC8G3bzVBkIshKIE6gKkXxdRJvvZL9JcMYIBSzCC 5223 AUcCAQEwdTBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4x 5224 PDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9v 5225 dCBDQQIEP5ibUjALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG 5226 SIb3DQEJBTEPFw0yMDAyMjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCA9gYxR1sS0giII3PwvOK/N 5227 5RUBwjSL/cDcrH/Bd+E1ajAKBggqhkjOPQQDAgRHMEUCIFieXZaO7P9eZMpCVn2laB4czw7I0s0P 5228 s9+frcJtEBTTAiEAhCcB//qmgqcEA+90mquvVNENmFH9dxCH8Ihhz6SCVDI= 5229 5230 The ASN1 decoding of the artifact: 5232 file: examples/parboiled_vr_00_D0-E5-02-00-2D.b64 5234 0:d=0 hl=4 l=4087 cons: SEQUENCE 5235 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 5236 15:d=1 hl=4 l=4072 cons: cont [ 0 ] 5237 19:d=2 hl=4 l=4068 cons: SEQUENCE 5238 23:d=3 hl=2 l= 1 prim: INTEGER :01 5239 26:d=3 hl=2 l= 13 cons: SET 5240 28:d=4 hl=2 l= 11 cons: SEQUENCE 5241 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 5242 41:d=3 hl=4 l=2572 cons: SEQUENCE 5243 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 5244 56:d=4 hl=4 l=2557 cons: cont [ 0 ] 5245 60:d=5 hl=4 l=2553 prim: OCTET STRING :{"ietf-voucher-request:v 5246 2617:d=3 hl=4 l=1135 cons: cont [ 0 ] 5247 2621:d=4 hl=4 l= 508 cons: SEQUENCE 5248 2625:d=5 hl=4 l= 386 cons: SEQUENCE 5249 2629:d=6 hl=2 l= 3 cons: cont [ 0 ] 5250 2631:d=7 hl=2 l= 1 prim: INTEGER :02 5251 2634:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 5252 2640:d=6 hl=2 l= 10 cons: SEQUENCE 5253 2642:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5254 2652:d=6 hl=2 l= 109 cons: SEQUENCE 5255 2654:d=7 hl=2 l= 18 cons: SET 5256 2656:d=8 hl=2 l= 16 cons: SEQUENCE 5257 2658:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5258 2670:d=9 hl=2 l= 2 prim: IA5STRING :ca 5259 2674:d=7 hl=2 l= 25 cons: SET 5260 2676:d=8 hl=2 l= 23 cons: SEQUENCE 5261 2678:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5262 2690:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 5263 2701:d=7 hl=2 l= 60 cons: SET 5264 2703:d=8 hl=2 l= 58 cons: SEQUENCE 5265 2705:d=9 hl=2 l= 3 prim: OBJECT :commonName 5266 2710:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 5267 2763:d=6 hl=2 l= 30 cons: SEQUENCE 5268 2765:d=7 hl=2 l= 13 prim: UTCTIME :200225213154Z 5269 2780:d=7 hl=2 l= 13 prim: UTCTIME :220224213154Z 5270 2795:d=6 hl=2 l= 83 cons: SEQUENCE 5271 2797:d=7 hl=2 l= 18 cons: SET 5272 2799:d=8 hl=2 l= 16 cons: SEQUENCE 5273 2801:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5274 2813:d=9 hl=2 l= 2 prim: IA5STRING :ca 5275 2817:d=7 hl=2 l= 25 cons: SET 5276 2819:d=8 hl=2 l= 23 cons: SEQUENCE 5277 2821:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5278 2833:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 5279 2844:d=7 hl=2 l= 34 cons: SET 5280 2846:d=8 hl=2 l= 32 cons: SEQUENCE 5281 2848:d=9 hl=2 l= 3 prim: OBJECT :commonName 5282 2853:d=9 hl=2 l= 25 prim: UTF8STRING :fountain-test.example.co 5283 2880:d=6 hl=2 l= 89 cons: SEQUENCE 5284 2882:d=7 hl=2 l= 19 cons: SEQUENCE 5285 2884:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 5286 2893:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 5287 2903:d=7 hl=2 l= 66 prim: BIT STRING 5288 2971:d=6 hl=2 l= 42 cons: cont [ 3 ] 5289 2973:d=7 hl=2 l= 40 cons: SEQUENCE 5290 2975:d=8 hl=2 l= 22 cons: SEQUENCE 5291 2977:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usag 5292 2982:d=9 hl=2 l= 1 prim: BOOLEAN :255 5293 2985:d=9 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B0601 5294 2999:d=8 hl=2 l= 14 cons: SEQUENCE 5295 3001:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 5296 3006:d=9 hl=2 l= 1 prim: BOOLEAN :255 5297 3009:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020780 5298 3015:d=5 hl=2 l= 10 cons: SEQUENCE 5299 3017:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5300 3027:d=5 hl=2 l= 104 prim: BIT STRING 5301 3133:d=4 hl=4 l= 619 cons: SEQUENCE 5302 3137:d=5 hl=4 l= 498 cons: SEQUENCE 5303 3141:d=6 hl=2 l= 3 cons: cont [ 0 ] 5304 3143:d=7 hl=2 l= 1 prim: INTEGER :02 5305 3146:d=6 hl=2 l= 4 prim: INTEGER :296B0659 5306 3152:d=6 hl=2 l= 10 cons: SEQUENCE 5307 3154:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5308 3164:d=6 hl=2 l= 109 cons: SEQUENCE 5309 3166:d=7 hl=2 l= 18 cons: SET 5310 3168:d=8 hl=2 l= 16 cons: SEQUENCE 5311 3170:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5312 3182:d=9 hl=2 l= 2 prim: IA5STRING :ca 5313 3186:d=7 hl=2 l= 25 cons: SET 5314 3188:d=8 hl=2 l= 23 cons: SEQUENCE 5315 3190:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5316 3202:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 5317 3213:d=7 hl=2 l= 60 cons: SET 5318 3215:d=8 hl=2 l= 58 cons: SEQUENCE 5319 3217:d=9 hl=2 l= 3 prim: OBJECT :commonName 5320 3222:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 5321 3275:d=6 hl=2 l= 30 cons: SEQUENCE 5322 3277:d=7 hl=2 l= 13 prim: UTCTIME :200225213145Z 5323 3292:d=7 hl=2 l= 13 prim: UTCTIME :220224213145Z 5324 3307:d=6 hl=2 l= 109 cons: SEQUENCE 5325 3309:d=7 hl=2 l= 18 cons: SET 5326 3311:d=8 hl=2 l= 16 cons: SEQUENCE 5327 3313:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5328 3325:d=9 hl=2 l= 2 prim: IA5STRING :ca 5329 3329:d=7 hl=2 l= 25 cons: SET 5330 3331:d=8 hl=2 l= 23 cons: SEQUENCE 5331 3333:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5332 3345:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 5333 3356:d=7 hl=2 l= 60 cons: SET 5334 3358:d=8 hl=2 l= 58 cons: SEQUENCE 5335 3360:d=9 hl=2 l= 3 prim: OBJECT :commonName 5336 3365:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 5337 3418:d=6 hl=2 l= 118 cons: SEQUENCE 5338 3420:d=7 hl=2 l= 16 cons: SEQUENCE 5339 3422:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 5340 3431:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 5341 3438:d=7 hl=2 l= 98 prim: BIT STRING 5342 3538:d=6 hl=2 l= 99 cons: cont [ 3 ] 5343 3540:d=7 hl=2 l= 97 cons: SEQUENCE 5344 3542:d=8 hl=2 l= 15 cons: SEQUENCE 5345 3544:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 5346 3549:d=9 hl=2 l= 1 prim: BOOLEAN :255 5347 3552:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF 5348 3559:d=8 hl=2 l= 14 cons: SEQUENCE 5349 3561:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 5350 3566:d=9 hl=2 l= 1 prim: BOOLEAN :255 5351 3569:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106 5352 3575:d=8 hl=2 l= 29 cons: SEQUENCE 5353 3577:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 5354 3582:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11 5355 3606:d=8 hl=2 l= 31 cons: SEQUENCE 5356 3608:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide 5357 3613:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6 5358 3639:d=5 hl=2 l= 10 cons: SEQUENCE 5359 3641:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5360 3651:d=5 hl=2 l= 103 prim: BIT STRING 5361 3756:d=3 hl=4 l= 331 cons: SET 5362 3760:d=4 hl=4 l= 327 cons: SEQUENCE 5363 3764:d=5 hl=2 l= 1 prim: INTEGER :01 5364 3767:d=5 hl=2 l= 117 cons: SEQUENCE 5365 3769:d=6 hl=2 l= 109 cons: SEQUENCE 5366 3771:d=7 hl=2 l= 18 cons: SET 5367 3773:d=8 hl=2 l= 16 cons: SEQUENCE 5368 3775:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5369 3787:d=9 hl=2 l= 2 prim: IA5STRING :ca 5370 3791:d=7 hl=2 l= 25 cons: SET 5371 3793:d=8 hl=2 l= 23 cons: SEQUENCE 5372 3795:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5373 3807:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 5374 3818:d=7 hl=2 l= 60 cons: SET 5375 3820:d=8 hl=2 l= 58 cons: SEQUENCE 5376 3822:d=9 hl=2 l= 3 prim: OBJECT :commonName 5377 3827:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 5378 3880:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 5379 3886:d=5 hl=2 l= 11 cons: SEQUENCE 5380 3888:d=6 hl=2 l= 9 prim: OBJECT :sha256 5381 3899:d=5 hl=2 l= 105 cons: cont [ 0 ] 5382 3901:d=6 hl=2 l= 24 cons: SEQUENCE 5383 3903:d=7 hl=2 l= 9 prim: OBJECT :contentType 5384 3914:d=7 hl=2 l= 11 cons: SET 5385 3916:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 5386 3927:d=6 hl=2 l= 28 cons: SEQUENCE 5387 3929:d=7 hl=2 l= 9 prim: OBJECT :signingTime 5388 3940:d=7 hl=2 l= 15 cons: SET 5389 3942:d=8 hl=2 l= 13 prim: UTCTIME :200225230449Z 5390 3957:d=6 hl=2 l= 47 cons: SEQUENCE 5391 3959:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 5392 3970:d=7 hl=2 l= 34 cons: SET 5393 3972:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:3D818C51D6C4B4 5394 4006:d=5 hl=2 l= 10 cons: SEQUENCE 5395 4008:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5396 4018:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220589E5D 5398 The JSON contained in the voucher request. Note that the previous 5399 voucher request is in the prior-signed-voucher-request attribute. 5401 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr 5402 eated-on":"2020-02-25T23:04:49.054Z","serial-number":"00-D0- 5403 E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","prior-signed- 5404 voucher-request":"MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBg 5405 lghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaG 5406 VyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLC 5407 JjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLC 5408 JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Im 5409 FNamd1ZUtVVC0yMndWaW1qNnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLW 5410 NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV 5411 FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU 5412 prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF 5413 lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm 5414 5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak 5415 F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV 5416 pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU 5417 F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn 5418 lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk 5419 NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU 5420 5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU 5421 1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG 5422 tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV 5423 BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk 5424 JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2 5425 NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIEDYXcLTAKBg 5426 gqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW 5427 8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0Lm 5428 V4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMD 5429 AwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49Ag 5430 EGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5BefBbE0 5431 sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDg 5432 QWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBw 5433 EgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BA 5434 MCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TX 5435 mKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vA 5436 QdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2 5437 FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJD 5438 AiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEDYXcLTALBg 5439 lghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSI 5440 b3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6Irwst 5441 HF609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIB 5442 xwA1UlkIkuQDf/j7kZ/MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bm 5443 iEUpefCEhxSv2xLYurGlugv0dfr/E="}} 5445 C.2.3. MASA to Registrar 5447 The MASA will return a voucher to the registrar, to be relayed to the 5448 pledge. 5450 file "voucher_00-D0-E5-F2-00-02.b64" 5451 MIIGyAYJKoZIhvcNAQcCoIIGuTCCBrUCAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG9w0BBwGg 5452 ggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoibG9nZ2VkIiwiY3Jl 5453 YXRlZC1vbiI6IjIwMjAtMDItMjVUMTY6MzM6MTIuODQ5LTA1OjAwIiwic2VyaWFsLW51bWJlciI6 5454 IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJ5MkJmTmFJUzBLSlN5aEthbVRHWGFRIiwicGlu 5455 bmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NBWUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFR 5456 REFqQnRNUkl3RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6 5457 WVc1a1pXeHRZVzR4UERBNkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpi 5458 MjBnVlc1emRISjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5U 5459 UmFGdzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJj 5460 R0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05MWJuUmhhVzR0 5461 ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFC 5462 SlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt 5463 SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqS2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0Nz 5464 R0FRVUZCd01jTUE0R0ExVWREd0VCL3dRRUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJt 5465 VDJCTVZVZ2VsZ2Y0M1IrNXlCS05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVht 5466 UmtqL1g0Q01RQzhyTU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNn 5467 ZFNjRmNBZGYrK0J3Nll5K1U9In19oIIB4zCCAd8wggFkoAMCAQICBBuZX1QwCgYIKoZIzj0EAwIw 5468 XTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4x 5469 JDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0xOTAyMTIyMjIyNDFaFw0y 5470 MTAyMTEyMjIyNDFaMF8xDzANBgNVBAYTBkNhbmFkYTEQMA4GA1UECAwHT250YXJpbzESMBAGA1UE 5471 CwwJU2FuZGVsbWFuMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gTUFTQTBZMBMG 5472 ByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5GwcbpnRznB66bKmzqTCpojJZ96AdRwFt 5473 uTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6WjEDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0E 5474 AwIDaQAwZgIxAL1V5ZsO+/xelSnjgbMVNaqTGKIEvkRyslF9TW3r0dXBEDqyOXtXP8XMsKMO55lG 5475 ugIxAPZ/RH23FPrRZ2rUEcNLrub7mphW+oUhLlxITPA/8ps/roggp675cv9b+Xhozw9IyTGCATww 5476 ggE4AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlT 5477 YW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEG5lfVDALBglg 5478 hkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAy 5479 MjUyMTMzMTJaMC8GCSqGSIb3DQEJBDEiBCAUaEb583jZIHCPYTPwZSRKJ7XONLRtjvf071ZCHb6i 5480 6jAKBggqhkjOPQQDAgRIMEYCIQCOzdl41Cdb0OycWymjmoT6alVT+mPvGfVPl2xyMxqwHwIhAPri 5481 bTuYNFARgkPLS5MX6iZx5IKhiTCjbJKY8hwfAqCE 5482 5484 The ASN1 decoding of the artifact: 5486 file: examples/voucher_00-D0-E5-F2-00-02.b64 5488 0:d=0 hl=4 l=1736 cons: SEQUENCE 5489 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 5490 15:d=1 hl=4 l=1721 cons: cont [ 0 ] 5491 19:d=2 hl=4 l=1717 cons: SEQUENCE 5492 23:d=3 hl=2 l= 1 prim: INTEGER :01 5493 26:d=3 hl=2 l= 13 cons: SET 5494 28:d=4 hl=2 l= 11 cons: SEQUENCE 5495 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 5496 41:d=3 hl=4 l= 888 cons: SEQUENCE 5497 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 5498 56:d=4 hl=4 l= 873 cons: cont [ 0 ] 5499 60:d=5 hl=4 l= 869 prim: OCTET STRING :{"ietf-voucher:voucher": 5500 933:d=3 hl=4 l= 483 cons: cont [ 0 ] 5501 937:d=4 hl=4 l= 479 cons: SEQUENCE 5502 941:d=5 hl=4 l= 356 cons: SEQUENCE 5503 945:d=6 hl=2 l= 3 cons: cont [ 0 ] 5504 947:d=7 hl=2 l= 1 prim: INTEGER :02 5505 950:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 5506 956:d=6 hl=2 l= 10 cons: SEQUENCE 5507 958:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5508 968:d=6 hl=2 l= 93 cons: SEQUENCE 5509 970:d=7 hl=2 l= 15 cons: SET 5510 972:d=8 hl=2 l= 13 cons: SEQUENCE 5511 974:d=9 hl=2 l= 3 prim: OBJECT :countryName 5512 979:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 5513 987:d=7 hl=2 l= 16 cons: SET 5514 989:d=8 hl=2 l= 14 cons: SEQUENCE 5515 991:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 5516 996:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 5517 1005:d=7 hl=2 l= 18 cons: SET 5518 1007:d=8 hl=2 l= 16 cons: SEQUENCE 5519 1009:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 5520 1014:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 5521 1025:d=7 hl=2 l= 36 cons: SET 5522 1027:d=8 hl=2 l= 34 cons: SEQUENCE 5523 1029:d=9 hl=2 l= 3 prim: OBJECT :commonName 5524 1034:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 5525 1063:d=6 hl=2 l= 30 cons: SEQUENCE 5526 1065:d=7 hl=2 l= 13 prim: UTCTIME :190212222241Z 5527 1080:d=7 hl=2 l= 13 prim: UTCTIME :210211222241Z 5528 1095:d=6 hl=2 l= 95 cons: SEQUENCE 5529 1097:d=7 hl=2 l= 15 cons: SET 5530 1099:d=8 hl=2 l= 13 cons: SEQUENCE 5531 1101:d=9 hl=2 l= 3 prim: OBJECT :countryName 5532 1106:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 5533 1114:d=7 hl=2 l= 16 cons: SET 5534 1116:d=8 hl=2 l= 14 cons: SEQUENCE 5535 1118:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 5536 1123:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 5537 1132:d=7 hl=2 l= 18 cons: SET 5538 1134:d=8 hl=2 l= 16 cons: SEQUENCE 5539 1136:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 5540 1141:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 5541 1152:d=7 hl=2 l= 38 cons: SET 5542 1154:d=8 hl=2 l= 36 cons: SEQUENCE 5543 1156:d=9 hl=2 l= 3 prim: OBJECT :commonName 5544 1161:d=9 hl=2 l= 29 prim: UTF8STRING :highway-test.example.com 5545 1192:d=6 hl=2 l= 89 cons: SEQUENCE 5546 1194:d=7 hl=2 l= 19 cons: SEQUENCE 5547 1196:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 5548 1205:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 5549 1215:d=7 hl=2 l= 66 prim: BIT STRING 5550 1283:d=6 hl=2 l= 16 cons: cont [ 3 ] 5551 1285:d=7 hl=2 l= 14 cons: SEQUENCE 5552 1287:d=8 hl=2 l= 12 cons: SEQUENCE 5553 1289:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 5554 1294:d=9 hl=2 l= 1 prim: BOOLEAN :255 5555 1297:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 5556 1301:d=5 hl=2 l= 10 cons: SEQUENCE 5557 1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5558 1313:d=5 hl=2 l= 105 prim: BIT STRING 5559 1420:d=3 hl=4 l= 316 cons: SET 5560 1424:d=4 hl=4 l= 312 cons: SEQUENCE 5561 1428:d=5 hl=2 l= 1 prim: INTEGER :01 5562 1431:d=5 hl=2 l= 101 cons: SEQUENCE 5563 1433:d=6 hl=2 l= 93 cons: SEQUENCE 5564 1435:d=7 hl=2 l= 15 cons: SET 5565 1437:d=8 hl=2 l= 13 cons: SEQUENCE 5566 1439:d=9 hl=2 l= 3 prim: OBJECT :countryName 5567 1444:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 5568 1452:d=7 hl=2 l= 16 cons: SET 5569 1454:d=8 hl=2 l= 14 cons: SEQUENCE 5570 1456:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 5571 1461:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 5572 1470:d=7 hl=2 l= 18 cons: SET 5573 1472:d=8 hl=2 l= 16 cons: SEQUENCE 5574 1474:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 5575 1479:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 5576 1490:d=7 hl=2 l= 36 cons: SET 5577 1492:d=8 hl=2 l= 34 cons: SEQUENCE 5578 1494:d=9 hl=2 l= 3 prim: OBJECT :commonName 5579 1499:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 5580 1528:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 5581 1534:d=5 hl=2 l= 11 cons: SEQUENCE 5582 1536:d=6 hl=2 l= 9 prim: OBJECT :sha256 5583 1547:d=5 hl=2 l= 105 cons: cont [ 0 ] 5584 1549:d=6 hl=2 l= 24 cons: SEQUENCE 5585 1551:d=7 hl=2 l= 9 prim: OBJECT :contentType 5586 1562:d=7 hl=2 l= 11 cons: SET 5587 1564:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 5588 1575:d=6 hl=2 l= 28 cons: SEQUENCE 5589 1577:d=7 hl=2 l= 9 prim: OBJECT :signingTime 5590 1588:d=7 hl=2 l= 15 cons: SET 5591 1590:d=8 hl=2 l= 13 prim: UTCTIME :200225213312Z 5592 1605:d=6 hl=2 l= 47 cons: SEQUENCE 5593 1607:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 5594 1618:d=7 hl=2 l= 34 cons: SET 5595 1620:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:146846F9F378D9 5596 1654:d=5 hl=2 l= 10 cons: SEQUENCE 5597 1656:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 5598 1666:d=5 hl=2 l= 72 prim: OCTET STRING [HEX DUMP]:30460221008ECD 5600 Appendix D. Additional References 5602 RFC EDITOR Please remove this section before publication. It exists 5603 just to include references to the things in the YANG descriptions 5604 which are not otherwise referenced in the text so that xml2rfc will 5605 not complain. 5607 [ITU.X690.1994] 5609 Authors' Addresses 5611 Max Pritikin 5612 Cisco 5614 Email: pritikin@cisco.com 5616 Michael C. Richardson 5617 Sandelman Software Works 5619 Email: mcr+ietf@sandelman.ca 5620 URI: http://www.sandelman.ca/ 5622 Toerless Eckert 5623 Futurewei Technologies Inc. USA 5624 2330 Central Expy 5625 Santa Clara, 95050 5626 United States of America 5628 Email: tte+ietf@cs.fau.de 5630 Michael H. Behringer 5632 Email: Michael.H.Behringer@gmail.com 5634 Kent Watsen 5635 Watsen Networks 5637 Email: kent+ietf@watsen.net