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