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