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