idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-19.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2019) is 1877 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4514' is mentioned on line 786, but not defined == Missing Reference: 'RFC3987' is mentioned on line 812, but not defined == Missing Reference: 'GRASP' is mentioned on line 1496, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1968, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC5209' is mentioned on line 2584, but not defined == Missing Reference: 'RFC2131' is mentioned on line 3567, but not defined == Missing Reference: 'HEX DUMP' is mentioned on line 4640, but not defined == Unused Reference: 'RFC5386' is defined on line 3346, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 3351, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 3355, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity' is defined on line 3431, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 3443, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 3474, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 3478, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 3488, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 3499, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 3523, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 8368 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-09 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-02 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-07 == 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) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 23 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: September 8, 2019 Sandelman 6 M. Behringer 8 S. Bjarnason 9 Arbor Networks 10 K. Watsen 11 Juniper Networks 12 March 7, 2019 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-19 17 Abstract 19 This document specifies automated bootstrapping of an Autonomic 20 Control Plane. To do this a remote secure key infrastructure (BRSKI) 21 is created using manufacturer installed X.509 certificate, in 22 combination with a manufacturer's authorizing service, both online 23 and offline. Bootstrapping a new device can occur using a routable 24 address and a cloud service, or using only link-local connectivity, 25 or on limited/disconnected networks. Support for lower security 26 models, including devices with minimal identity, is described for 27 legacy reasons but not encouraged. Bootstrapping is complete when 28 the cryptographic identity of the new key infrastructure is 29 successfully deployed to the device but the established secure 30 connection can be used to deploy a locally issued certificate to the 31 device as well. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 8, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 70 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10 71 1.3.1. Support environment . . . . . . . . . . . . . . . . . 10 72 1.3.2. Constrained environments . . . . . . . . . . . . . . 10 73 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 11 74 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 11 75 1.4. Leveraging the new key infrastructure / next steps . . . 11 76 1.5. Requirements for Autonomic Network Infrastructure (ANI) 77 devices . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12 79 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 14 80 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15 81 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16 82 2.3.1. Identification of the Pledge . . . . . . . . . . . . 16 83 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17 84 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 19 85 2.5. Architectural Components . . . . . . . . . . . . . . . . 21 86 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 21 87 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 21 88 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 21 89 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 21 90 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21 91 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22 92 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22 93 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 22 94 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 22 95 2.8. Determining the MASA to contact . . . . . . . . . . . . . 23 96 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 23 97 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 24 98 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24 99 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 100 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27 101 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 30 102 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 31 103 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32 104 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33 105 4.3. Proxy discovery and communication of Registrar . . . . . 33 106 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 35 107 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 108 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 37 109 5.3. Registrar Authorization of 110 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 38 111 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 39 112 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39 113 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 41 114 5.5.2. MASA verification of voucher-request signature 115 consistency . . . . . . . . . . . . . . . . . . . . . 41 116 5.5.3. MASA authentication of registrar (certificate) . . . 41 117 5.5.4. MASA revocation checking of registrar (certificate) . 42 118 5.5.5. MASA verification of pledge prior-signed-voucher- 119 request . . . . . . . . . . . . . . . . . . . . . . . 42 120 5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42 121 5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42 122 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 43 123 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45 124 5.6.2. Pledge authentication of provisional TLS connection . 46 125 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 47 126 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47 127 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 49 128 5.8.2. Registrar audit log verification . . . . . . . . . . 50 129 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 51 130 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 52 131 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 52 132 5.9.3. EST Client Certificate Request . . . . . . . . . . . 53 133 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 53 134 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 54 135 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 54 136 6. Reduced security operational modes . . . . . . . . . . . . . 54 137 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 55 138 6.2. Pledge security reductions . . . . . . . . . . . . . . . 55 139 6.3. Registrar security reductions . . . . . . . . . . . . . . 56 140 6.4. MASA security reductions . . . . . . . . . . . . . . . . 57 141 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 142 7.1. Well-known EST registration . . . . . . . . . . . . . . . 58 143 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58 144 7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58 145 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 59 146 7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59 147 8. Applicability to the Autonomic 148 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59 149 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60 150 9.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60 151 9.2. What BRSKI-MASA reveals to the manufacturer . . . . . . . 61 152 9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 63 153 9.4. Manufacturers and Grey market equipment . . . . . . . . . 64 154 9.5. Some mitigations for meddling by manufacturers . . . . . 64 155 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 156 10.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66 157 10.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67 158 10.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68 159 10.4. Manufacturer Maintainance of trust anchors . . . . . . . 69 160 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 161 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 162 12.1. Normative References . . . . . . . . . . . . . . . . . . 71 163 12.2. Informative References . . . . . . . . . . . . . . . . . 73 164 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76 165 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76 166 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 77 167 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 77 168 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 78 169 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 80 170 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 80 171 D.1.1. MASA key pair for voucher signatures . . . . . . . . 80 172 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 80 173 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 81 174 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 83 175 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 85 176 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 85 177 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 91 178 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 96 179 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 181 1. Introduction 183 BRSKI provides a solution for secure zero-touch (automated) bootstrap 184 of new (unconfigured) devices that are called pledges in this 185 document. 187 This document primarily provides for the needs of the ISP and 188 Enterprise focused ANIMA Autonomic Control Plane (ACP) 189 [I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI 190 protocol will need to provide separate applicability statements that 191 include privacy and security considerations appropriate to that 192 deployment. Section Section 8 explains the details applicability for 193 this the ACP usage. 195 This document describes how pledges discover (or be discovered by) an 196 element of the network domain to which the pledge belongs to perform 197 the bootstrap. This element (device) is called the registrar. 198 Before any other operation, pledge and registrar need to establish 199 mutual trust: 201 1. Registrar authenticating the pledge: "Who is this device? What 202 is its identity?" 204 2. Registrar authorizing the pledge: "Is it mine? Do I want it? 205 What are the chances it has been compromised?" 207 3. Pledge authenticating the registrar: "What is this registrar's 208 identity?" 210 4. Pledge authorizing the registrar: "Should I join it?" 212 This document details protocols and messages to answer the above 213 questions. It uses a TLS connection and an PKIX (X.509v3) 214 certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer 215 points 1 and 2. It uses a new artifact called a "voucher" that the 216 registrar receives from a "Manufacturer Authorized Signing Authority" 217 and passes to the pledge to answer points 3 and 4. 219 A proxy provides very limited connectivity between the pledge and the 220 registrar. 222 The syntactic details of vouchers are described in detail in 223 [RFC8366]. This document details automated protocol mechanisms to 224 obtain vouchers, including the definition of a 'voucher-request' 225 message that is a minor extension to the voucher format (see 226 Section 3) defined by [RFC8366]. 228 BRSKI results in the pledge storing an X.509 root certificate 229 sufficient for verifying the registrar identity. In the process a 230 TLS connection is established that can be directly used for 231 Enrollment over Secure Transport (EST). In effect BRSKI provides an 232 automated mechanism for the "Bootstrap Distribution of CA 233 Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge 234 "MUST [...] engage a human user to authorize the CA certificate using 235 out-of-band" information". With BRSKI the pledge now can automate 236 this process using the voucher. Integration with a complete EST 237 enrollment is optional but trivial. 239 BRSKI is agile enough to support bootstrapping alternative key 240 infrastructures, such as a symmetric key solutions, but no such 241 system is described in this document. 243 1.1. Prior Bootstrapping Approaches 245 To literally "pull yourself up by the bootstraps" is an impossible 246 action. Similarly the secure establishment of a key infrastructure 247 without external help is also an impossibility. Today it is commonly 248 accepted that the initial connections between nodes are insecure, 249 until key distribution is complete, or that domain-specific keying 250 material (often pre-shared keys, including mechanisms like SIM cards) 251 is pre-provisioned on each new device in a costly and non-scalable 252 manner. Existing automated mechanisms are known as non-secured 253 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 254 [Stajano99theresurrecting] or 'pre-staging'. 256 Another prior approach has been to try and minimize user actions 257 during bootstrapping, but not eliminate all user-actions. The 258 original EST protocol [RFC7030] does reduce user actions during 259 bootstrap but does not provide solutions for how the following 260 protocol steps can be made autonomic (not involving user actions): 262 o using the Implicit Trust Anchor [RFC7030] database to authenticate 263 an owner specific service (not an autonomic solution because the 264 URL must be securely distributed), 266 o engaging a human user to authorize the CA certificate using out- 267 of-band data (not an autonomic solution because the human user is 268 involved), 270 o using a configured Explicit TA database (not an autonomic solution 271 because the distribution of an explicit TA database is not 272 autonomic), 274 o and using a Certificate-Less TLS mutual authentication method (not 275 an autonomic solution because the distribution of symmetric key 276 material is not autonomic). 278 These "touch" methods do not meet the requirements for zero-touch. 280 There are "call home" technologies where the pledge first establishes 281 a connection to a well known manufacturer service using a common 282 client-server authentication model. After mutual authentication, 283 appropriate credentials to authenticate the target domain are 284 transfered to the pledge. This creates serveral problems and 285 limitations: 287 o the pledge requires realtime connectivity to the manufacturer 288 service, 290 o the domain identity is exposed to the manufacturer service (this 291 is a privacy concern), 293 o the manufacturer is responsible for making the authorization 294 decisions (this is a liability concern), 296 BRSKI addresses these issues by defining extensions to the EST 297 protocol for the automated distribution of vouchers. 299 1.2. Terminology 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 303 "OPTIONAL" in this document are to be interpreted as described in 304 [RFC2119]. 306 The following terms are defined for clarity: 308 domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT 309 STRING of the subjectPublicKey of the pinned-domain-cert leaf, 310 i.e. the Registrars' certificate. This is consistent with the 311 subject key identifier (Section 4.2.1.2 [RFC5280]). 313 drop ship: The physical distribution of equipment containing the 314 "factory default" configuration to a final destination. In zero- 315 touch scenarios there is no staging or pre-configuration during 316 drop-ship. 318 imprint: The process where a device obtains the cryptographic key 319 material to identify and trust future interactions with a network. 320 This term is taken from Konrad Lorenz's work in biology with new 321 ducklings: during a critical period, the duckling would assume 322 that anything that looks like a mother duck is in fact their 323 mother. An equivalent for a device is to obtain the fingerprint 324 of the network's root certification authority certificate. A 325 device that imprints on an attacker suffers a similar fate to a 326 duckling that imprints on a hungry wolf. Securely imprinting is a 327 primary focus of this document [imprinting]. The analogy to 328 Lorenz's work was first noted in [Stajano99theresurrecting]. 330 enrollment: The process where a device presents key material to a 331 network and acquires a network specific identity. For example 332 when a certificate signing request is presented to a certification 333 authority and a certificate is obtained in response. 335 Pledge: The prospective device, which has an identity installed at 336 the factory. 338 Voucher: A signed artifact from the MASA that indicates to a pledge 339 the cryptographic identity of the registrar it should trust. 340 There are different types of vouchers depending on how that trust 341 is asserted. Multiple voucher types are defined in [RFC8366] 343 Domain: The set of entities that share a common local trust anchor. 344 This includes the proxy, registrar, Domain Certificate Authority, 345 Management components and any existing entity that is already a 346 member of the domain. 348 Domain CA: The domain Certification Authority (CA) provides 349 certification functionalities to the domain. At a minimum it 350 provides certification functionalities to a registrar and manages 351 the private key that defines the domain. Optionally, it certifies 352 all elements. 354 Join Registrar (and Coordinator): A representative of the domain 355 that is configured, perhaps autonomically, to decide whether a new 356 device is allowed to join the domain. The administrator of the 357 domain interfaces with a "join registrar (and coordinator)" to 358 control this process. Typically a join registrar is "inside" its 359 domain. For simplicity this document often refers to this as just 360 "registrar". Within [I-D.ietf-anima-reference-model] this is 361 refered to as the "join registrar autonomic service agent". Other 362 communities use the abbreviation "JRC". 364 (Public) Key Infrastructure: The collection of systems and processes 365 that sustain the activities of a public key system. The registrar 366 acts as an [RFC5280] and [RFC5272] (see section 7) "Registration 367 Authority". 369 Join Proxy: A domain entity that helps the pledge join the domain. 370 A join proxy facilitates communication for devices that find 371 themselves in an environment where they are not provided 372 connectivity until after they are validated as members of the 373 domain. For simplicity this document sometimes uses the term of 374 'proxy' to indicate the join proxy. The pledge is unaware that 375 they are communicating with a proxy rather than directly with a 376 registrar. 378 Circuit Proxy: A stateful implementation of the join proxy. This is 379 the assumed type of proxy. 381 IPIP Proxy: A stateless proxy alternative. 383 MASA Service: A third-party Manufacturer Authorized Signing 384 Authority (MASA) service on the global Internet. The MASA signs 385 vouchers. It also provides a repository for audit log information 386 of privacy protected bootstrapping events. It does not track 387 ownership. 389 Ownership Tracker: An Ownership Tracker service on the global 390 internet. The Ownership Tracker uses business processes to 391 accurately track ownership of all devices shipped against domains 392 that have purchased them. Although optional, this component 393 allows vendors to provide additional value in cases where their 394 sales and distribution channels allow for accurately tracking of 395 such ownership. Ownership tracking information is indicated in 396 vouchers as described in [RFC8366] 398 IDevID: An Initial Device Identity X.509 certificate installed by 399 the vendor on new equipment. 401 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 402 where a pledge device makes no security decisions but rather 403 simply trusts the first registrar it is contacted by. This is 404 also known as the "resurrecting duckling" model. 406 nonced: a voucher (or request) that contains a nonce (the normal 407 case). 409 nonceless: a voucher (or request) that does not contain a nonce, 410 relying upon accurate clocks for expiration, or which does not 411 expire. 413 manufacturer: the term manufacturer is used throughout this document 414 to be the entity that created the device. This is typically the 415 "original equipment manufacturer" or OEM, but in more complex 416 situations it could be a "value added retailer" (VAR), or possibly 417 even a systems integrator. In general, it a goal of BRSKI to 418 eliminate small distinctions between different sales channels. 419 The reason for this is that it permits a single device, with a 420 uniform firmware load, to be shipped directly to all customers. 421 This eliminates costs for the manufacturer. This also reduces the 422 number of products supported in the field increasing the chance 423 that firmware will be more up to date. 425 ANI: The Autonomic Network Infrastructure as defined by 426 [I-D.ietf-anima-reference-model]. This document details specific 427 requirements for pledges, proxies and registrars when they are 428 part of an ANI. 430 offline: When an architectural component cannot perform realtime 431 communications with a peer, either due to network connectivity or 432 because the peer is turned off, the operation is said to be 433 occurring offline. 435 1.3. Scope of solution 437 1.3.1. Support environment 439 This solution (BRSKI) can support large router platforms with multi- 440 gigabit inter-connections, mounted in controlled access data centers. 441 But this solution is not exclusive to large equipment: it is intended 442 to scale to thousands of devices located in hostile environments, 443 such as ISP provided CPE devices which are drop-shipped to the end 444 user. The situation where an order is fulfilled from distributed 445 warehouse from a common stock and shipped directly to the target 446 location at the request of a domain owner is explicitly supported. 447 That stock ("SKU") could be provided to a number of potential domain 448 owners, and the eventual domain owner will not know a-priori which 449 device will go to which location. 451 The bootstrapping process can take minutes to complete depending on 452 the network infrastructure and device processing speed. The network 453 communication itself is not optimized for speed; for privacy reasons, 454 the discovery process allows for the pledge to avoid announcing its 455 presence through broadcasting. 457 Nomadic or mobile devices often need to aquire credentials to access 458 the network at the new location. An example of this is mobile phone 459 roaming among network operators, or even between cell towers. This 460 is usually called handoff. BRSKI does not provide a low-latency 461 handoff which is usually a requirement in such situations. For these 462 solutions BRSKI can be used to create a relationship (an LDevID) with 463 the "home" domain owner. The resulting credentials are then used to 464 provide credentials more appropriate for a low-latency handoff. 466 1.3.2. Constrained environments 468 Questions have been posed as to whether this solution is suitable in 469 general for Internet of Things (IoT) networks. This depends on the 470 capabilities of the devices in question. The terminology of 471 [RFC7228] is best used to describe the boundaries. 473 The solution described in this document is aimed in general at non- 474 constrained (i.e., class 2+) devices operating on a non-Challenged 475 network. The entire solution as described here is not intended to be 476 useable as-is by constrained devices operating on challenged networks 477 (such as 802.15.4 LLNs). 479 Specifically, there are protocol aspects described here that might 480 result in congestion collapse or energy-exhaustion of intermediate 481 battery powered routers in an LLN. Those types of networks SHOULD 482 NOT use this solution. These limitations are predominately related 483 to the large credential and key sizes required for device 484 authentication. Defining symmetric key techniques that meet the 485 operational requirements is out-of-scope but the underlying protocol 486 operations (TLS handshake and signing structures) have sufficient 487 algorithm agility to support such techniques when defined. 489 The imprint protocol described here could, however, be used by non- 490 energy constrained devices joining a non-constrained network (for 491 instance, smart light bulbs are usually mains powered, and speak 492 802.11). It could also be used by non-constrained devices across a 493 non-energy constrained, but challenged network (such as 802.15.4). 494 The certificate contents, and the process by which the four questions 495 above are resolved do apply to constrained devices. It is simply the 496 actual on-the-wire imprint protocol that could be inappropriate. 498 1.3.3. Network Access Controls 500 This document presumes that network access control has either already 501 occurred, is not required, or is integrated by the proxy and 502 registrar in such a way that the device itself does not need to be 503 aware of the details. Although the use of an X.509 Initial Device 504 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 505 alignment with 802.1X network access control methods, its use here is 506 for pledge authentication rather than network access control. 507 Integrating this protocol with network access control, perhaps as an 508 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 509 out-of-scope. 511 1.3.4. Bootstrapping is not Booting 513 This document describes "bootstrapping" as the protocol used to 514 obtain a local trust anchor. It is expected that this trust anchor, 515 along with any additional configuration information subsequently 516 installed, is persisted on the device across system restarts 517 ("booting"). Bootstrapping occurs only infrequently such as when a 518 device is transfered to a new owner or has been reset to factory 519 default settings. 521 1.4. Leveraging the new key infrastructure / next steps 523 As a result of the protocol described herein, the bootstrapped 524 devices have the Domain CA trust anchor in common. An end entity 525 certificate has optionally been issued from the Domain CA. This 526 makes it possible to securely deploy functionalities across the 527 domain, e.g: 529 o Device management. 531 o Routing authentication. 533 o Service discovery. 535 The major beneficiary is that it possible to use the credentials 536 deployed by this protocol to secure the Autonomic Control Plane (ACP) 537 ([I-D.ietf-anima-autonomic-control-plane]). 539 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 541 The BRSKI protocol can be used in a number of environments. Some of 542 the options in this document is the result of requirements that are 543 out of the ANI scope. This section defines the base requirements for 544 ANI devices. 546 For devices that intend to become part of an Autonomic Network 547 Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes 548 an Autonomic Control Plane 549 ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST 550 be implemented. 552 The pledge must perform discovery of the proxy as described in 553 Section 4.1 using GRASP M_FLOOD announcements. 555 Upon successfully validating a voucher artiface, a status telemetry 556 MUST be returned. See Section 5.7. 558 An ANIMA ANI pledge MUST implement the EST automation extensions 559 described in Section 5.9. They supplement the [RFC7030] EST to 560 better support automated devices that do not have an end user. 562 The ANI Join Registrar ASA MUST support all the BRSKI and above 563 listed EST operations. 565 All ANI devices SHOULD support the BRSKI proxy function, using 566 circuit proxies over the ACP. (See Section 4.3) 568 2. Architectural Overview 570 The logical elements of the bootstrapping framework are described in 571 this section. Figure 1 provides a simplified overview of the 572 components. 574 +------------------------+ 575 +--------------Drop Ship--------------->| Vendor Service | 576 | +------------------------+ 577 | | M anufacturer| | 578 | | A uthorized |Ownership| 579 | | S igning |Tracker | 580 | | A uthority | | 581 | +--------------+---------+ 582 | ^ 583 | | BRSKI- 584 V | MASA 585 +-------+ ............................................|... 586 | | . | . 587 | | . +------------+ +-----------+ | . 588 | | . | | | | | . 589 |Pledge | . | Join | | Domain <-------+ . 590 | | . | Proxy | | Registrar | . 591 | <-------->............<-------> (PKI RA) | . 592 | | | BRSKI-EST | | . 593 | | . | | +-----+-----+ . 594 |IDevID | . +------------+ | EST RFC7030 . 595 | | . +-----------------+----------+ . 596 | | . | Key Infrastructure | . 597 | | . | (e.g., PKI Certificate | . 598 +-------+ . | Authority) | . 599 . +----------------------------+ . 600 . . 601 ................................................ 602 "Domain" components 604 Figure 1 606 We assume a multi-vendor network. In such an environment there could 607 be a Manufacturer Service for each manufacturer that supports devices 608 following this document's specification, or an integrator could 609 provide a generic service authorized by multiple manufacturers. It 610 is unlikely that an integrator could provide Ownership Tracking 611 services for multiple manufacturers due to the required sales channel 612 integrations necessary to track ownership. 614 The domain is the managed network infrastructure with a Key 615 Infrastructure the pledge is joining. The domain provides initial 616 device connectivity sufficient for bootstrapping through a proxy. 617 The domain registrar authenticates the pledge, makes authorization 618 decisions, and distributes vouchers obtained from the Manufacturer 619 Service. Optionally the registrar also acts as a PKI Registration 620 Authority. 622 2.1. Behavior of a Pledge 624 The pledge goes through a series of steps, which are outlined here at 625 a high level. 627 ------------ 628 / Factory \ 629 \ default / 630 -----+------ 631 | 632 +------v-------+ 633 | (1) Discover | 634 +------------> | 635 | +------+-------+ 636 | | 637 | +------v-------+ 638 | | (2) Identity | 639 ^------------+ | 640 | rejected +------+-------+ 641 | | 642 | +------v-------+ 643 | | (3) Request | 644 | | Join | 645 | +------+-------+ 646 | | 647 | +------v-------+ 648 | | (4) Imprint | 649 ^------------+ | 650 | Bad MASA +------+-------+ 651 | response | send Voucher Status Telemetry 652 | +------v-------+ 653 | | (5) Enroll |<---+ (non-error HTTP codes ) 654 ^------------+ |\___/ (e.g. 201 'Retry-After') 655 | Enroll +------+-------+ 656 | Failure | 657 | -----v------ 658 | / Enrolled \ 659 ^------------+ | 660 Factory \------------/ 661 reset 663 Figure 2: pledge state diagram 665 State descriptions for the pledge are as follows: 667 1. Discover a communication channel to a registrar. 669 2. Identify itself. This is done by presenting an X.509 IDevID 670 credential to the discovered registrar (via the proxy) in a TLS 671 handshake. (The registrar credentials are only provisionally 672 accepted at this time). 674 3. Request to join the discovered registrar. A unique nonce is 675 included ensuring that any responses can be associated with this 676 particular bootstrapping attempt. 678 4. Imprint on the registrar. This requires verification of the 679 manufacturer service provided voucher. A voucher contains 680 sufficient information for the pledge to complete authentication 681 of a registrar. This document details this step in depth. 683 5. Enroll. After imprint an authenticated TLS (HTTPS) connection 684 exists between pledge and registrar. Enrollment over Secure 685 Transport (EST) [RFC7030] is then used to obtain a domain 686 certificate from a registrar. 688 The pledge is now a member of, and can be managed by, the domain and 689 will only repeat the discovery aspects of bootstrapping if it is 690 returned to factory default settings. 692 This specification details integration with EST enrollment so that 693 pledges can optionally obtain a locally issued certificate, although 694 any REST interface could be integrated in future work. 696 2.2. Secure Imprinting using Vouchers 698 A voucher is a cryptographically protected artifact (a digital 699 signature) to the pledge device authorizing a zero-touch imprint on 700 the registrar domain. 702 The format and cryptographic mechanism of vouchers is described in 703 detail in [RFC8366]. 705 Vouchers provide a flexible mechanism to secure imprinting: the 706 pledge device only imprints when a voucher can be validated. At the 707 lowest security levels the MASA can indiscriminately issue vouchers 708 and log claims of ownership by domains. At the highest security 709 levels issuance of vouchers can be integrated with complex sales 710 channel integrations that are beyond the scope of this document. The 711 sales channel integration would verify actual (legal) ownership of 712 the pledge by the domain. This provides the flexibility for a number 713 of use cases via a single common protocol mechanism on the pledge and 714 registrar devices that are to be widely deployed in the field. The 715 MASA services have the flexibility to leverage either the currently 716 defined claim mechanisms or to experiment with higher or lower 717 security levels. 719 Vouchers provide a signed but non-encrypted communication channel 720 among the pledge, the MASA, and the registrar. The registrar 721 maintains control over the transport and policy decisions allowing 722 the local security policy of the domain network to be enforced. 724 2.3. Initial Device Identifier 726 Pledge authentication and pledge voucher-request signing is via a 727 PKIX certificate installed during the manufacturing process. This is 728 the 802.1AR Initial Device Identifier (IDevID), and it provides a 729 basis for authenticating the pledge during the protocol exchanges 730 described here. There is no requirement for a common root PKI 731 hierarchy. Each device manufacturer can generate its own root 732 certificate. Specifically, the IDevID enables: 734 1. Uniquely identifying the pledge by the Distinguished Name (DN) 735 and subjectAltName (SAN) parameters in the IDevID. The unique 736 identification of a pledge in the voucher objects are derived 737 from those parameters as described below. 739 2. Provides a cryptographic authentication of the pledge to the 740 Registrar (see Section 5.3). 742 3. Secure auto-discovery of the pledge's MASA by the registrar (see 743 Section 2.8). 745 4. Signing of voucher-request by the pledge's IDevID (see 746 Section 3). 748 5. Provides a cryptographic authentication of the pledge to the MASA 749 (see Section 5.5.5). 751 Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage 752 extensions in the IDevID certificate. Any restrictions included 753 reduce the utility of the IDevID and so this specification RECOMMENDS 754 that no key usage restrictions be included. Additionally, [RFC5280] 755 section 4.2.1.3 does not require key usage restrictions for end 756 entity certificates. 758 2.3.1. Identification of the Pledge 760 In the context of BRSKI, pledges are uniquely identified by a 761 "serial-number". This serial-number is used both in the "serial- 762 number" field of voucher or voucher-requests (see Section 3) and in 763 local policies on registrar or MASA (see Section 5). 765 The following fields are defined in [IDevID] and [RFC5280]: 767 o The subject field's DN encoding MUST include the "serialNumber" 768 attribute with the device's unique serial number. (from [IDevID] 769 section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard 770 attributes) 772 o The subject-alt field's encoding MAY include a non-critical 773 version of the RFC4108 defined HardwareModuleName. (from [IDevID] 774 section 7.2.9) If the IDevID is stored in a Trusted Platform 775 Module (TPM), then this field MAY contain the TPM identification 776 rather than the device's serial number. If both fields are 777 present, then the subject field takes precedence. 779 and they are used as follows by the pledge to build the "serial- 780 number" that is placed in the voucher-request. In order to build it, 781 the fields need to be converted into a serial-number of "type 782 string". The following methods are used depending on the first 783 available IDevID certificate field (attempted in this order): 785 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the 786 Distinguished Name "serialNumber" attribute. [RFC4514] indicates 787 this is a printable string so no encoding is necessary. 789 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is 790 base64 encoded to convert it to a printable string format. 792 The above process to locate the serial-number MUST be performed by 793 the pledge when filling out the voucher-request. Signed voucher- 794 requests are always passed up to the MASA, and the connection between 795 the serial-number in the voucher-request and the serial number in the 796 IDevID certificate. 798 As explained in Section 5.5 the Registrar MUST extract the serial- 799 number again itself from the pledge's TLS certificate. It may 800 consult the serial-number in the pledge-request if there are any 801 possible confusion about the source of the serial-number (hwSerialNum 802 vs serialNumber). 804 2.3.2. MASA URI extension 806 This docucment defines a new PKIX non-critical certificate extension 807 to carry the MASA URI. This extension is intended to be used in the 808 IDevID certificate. The URI is represented as described in 809 Section 7.4 of [RFC5280]. 811 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 812 URIs as specified in Section 3.1 of [RFC3987] before they are placed 813 in the certificate extension. The IRI provides the authority 814 information. The BRSKI "/.well-known" tree ([RFC5785]) is described 815 in Section 5. 817 As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in 818 this extension, including the scheme, iauthority, and ipath. As a 819 consideration to constrained systems, this MAY be reduced to only the 820 iauthority, in which case a scheme of "https://" and ipath of 821 "/.well-known/est" is to be assumed, as explained in section 822 Section 5. 824 The registrary can assume that only the iauthority is present in the 825 extension, if there are no slash ("/") characters in the extension. 827 Section 7.4 of [RFC5280] calls out various schemes that MUST be 828 supported, including ldap, http and ftp. However, the registrar MUST 829 use https for the BRSKI-MASA connection. 831 The new extension is identified as follows: 833 835 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 836 internet(1) security(5) mechanisms(5) pkix(7) 837 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 839 DEFINITIONS IMPLICIT TAGS ::= BEGIN 841 -- EXPORTS ALL -- 843 IMPORTS 844 EXTENSION 845 FROM PKIX-CommonTypes-2009 846 { iso(1) identified-organization(3) dod(6) internet(1) 847 security(5) mechanisms(5) pkix(7) id-mod(0) 848 id-mod-pkixCommon-02(57) } 850 id-pe 851 FROM PKIX1Explicit-2009 852 { iso(1) identified-organization(3) dod(6) internet(1) 853 security(5) mechanisms(5) pkix(7) id-mod(0) 854 id-mod-pkix1-explicit-02(51) } ; 855 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 856 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 857 IDENTIFIED BY id-pe-masa-url } 859 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 861 MASAURLSyntax ::= IA5String 863 END 865 867 The choice of id-pe is based on guidance found in Section 4.2.2 of 868 [RFC5280], "These extensions may be used to direct applications to 869 on-line information about the issuer or the subject". The MASA URL 870 is precisely that: online information about the particular subject. 872 2.4. Protocol Flow 874 A representative flow is shown in Figure 3: 876 +--------+ +---------+ +------------+ +------------+ 877 | Pledge | | Circuit | | Domain | | Vendor | 878 | | | Join | | Registrar | | Service | 879 | | | Proxy | | (JRC) | | (MASA) | 880 +--------+ +---------+ +------------+ +------------+ 881 | | | Internet | 882 [discover] | | | 883 |<-RFC4862 IPv6 addr | | | 884 |<-RFC3927 IPv4 addr | Appendix A | Legend | 885 |-------------------->| | C - circuit | 886 | optional: mDNS query| Appendix B | join proxy | 887 | RFC6763/RFC6762 | | P - provisional | 888 |<--------------------| | TLS connection | 889 | GRASP M_FLOOD | | | 890 | periodic broadcast| | | 891 [identity] | | | 892 |<------------------->C<----------------->| | 893 | TLS via the Join Proxy | | 894 |<--Registrar TLS server authentication---| | 895 [PROVISIONAL accept of server cert] | | 896 P---X.509 client authentication---------->| | 897 [request join] | | 898 P---Voucher Request(w/nonce for voucher)->| | 899 P /------------------- | | 900 P | [accept device?] | 901 P | [contact Vendor] | 902 P | |--Pledge ID-------->| 903 P | |--Domain ID-------->| 904 P | |--optional:nonce--->| 905 P optional: | [extract DomainID] 906 P can occur in advance | [update audit log] 907 P if nonceleess | | 908 P | |<- voucher ---------| 909 P \------------------- | w/nonce if provided| 910 P<------voucher---------------------------| | 911 [imprint] | | 912 |-------voucher status telemetry--------->| | 913 | |<-device audit log--| 914 | [verify audit log and voucher] | 915 |<--------------------------------------->| | 916 [enroll] | | 917 | Continue with RFC7030 enrollment | | 918 | using now bidirectionally authenticated | | 919 | TLS session. | | 920 [enrolled] | | 922 Figure 3 924 2.5. Architectural Components 926 2.5.1. Pledge 928 The pledge is the device that is attempting to join. Until the 929 pledge completes the enrollment process, it has link-local network 930 connectivity only to the proxy. 932 2.5.2. Join Proxy 934 The join proxy provides HTTPS connectivity between the pledge and the 935 registrar. A circuit proxy mechanism is described in Section 4. 936 Additional mechanisms, including a CoAP mechanism and a stateless 937 IPIP mechanism are the subject of future work. 939 2.5.3. Domain Registrar 941 The domain's registrar operates as the BRSKI-MASA client when 942 requesting vouchers from the MASA (see Section 5.4). The registrar 943 operates as the BRSKI-EST server when pledges request vouchers (see 944 Section 5.1). The registrar operates as the BRSKI-EST server 945 "Registration Authority" if the pledge requests an end entity 946 certificate over the BRSKI-EST connection (see Section 5.9). 948 The registrar uses an Implicit Trust Anchor database for 949 authenticating the BRSKI-MASA TLS connection MASA certificate. The 950 registrar uses a different Implicit Trust Anchor database for 951 authenticating the BRSKI-EST TLS connection pledge client 952 certificate. Configuration or distribution of these trust anchor 953 databases is out-of-scope of this specification. 955 2.5.4. Manufacturer Service 957 The Manufacturer Service provides two logically seperate functions: 958 the Manufacturer Authorized Signing Authority (MASA) described in 959 Section 5.5 and Section 5.6, and an ownership tracking/auditing 960 function described in Section 5.7 and Section 5.8. 962 2.5.5. Public Key Infrastructure (PKI) 964 The Public Key Infrastructure (PKI) administers certificates for the 965 domain of concerns, providing the trust anchor(s) for it and allowing 966 enrollment of pledges with domain certificates. 968 The voucher provides a method for the distribution of a single PKI 969 trust anchor (as the "pinned-domain-cert"). A distribution of the 970 full set of current trust anchors is possible using the optional EST 971 integration. 973 The domain's registrar acts as an [RFC5272] Registration Authority, 974 requesting certificates for pledges from the Key Infrastructure. 976 The expectations of the PKI are unchanged from EST [[RFC7030]]. This 977 document does not place any additional architectural requirements on 978 the Public Key Infrastructure. 980 2.6. Certificate Time Validation 982 2.6.1. Lack of realtime clock 984 Many devices when bootstrapping do not have knowledge of the current 985 time. Mechanisms such as Network Time Protocols cannot be secured 986 until bootstrapping is complete. Therefore bootstrapping is defined 987 in a method that does not require knowledge of the current time. A 988 pledge MAY ignore all time stamps in the voucher and in the 989 certificate validity periods if it does not know the current time. 991 The pledge is exposed to dates in the following five places: 992 registrar certificate notBefore, registrar certificiate notAfter, 993 voucher created-on, and voucher expires-on. Additionally, CMS 994 signatures contain a signingTime. 996 If the voucher contains a nonce then the pledge MUST confirm the 997 nonce matches the original pledge voucher-request. This ensures the 998 voucher is fresh. See Section 5.2. 1000 2.6.2. Infinite Lifetime of IDevID 1002 [RFC5280] explains that long lived pledge certificates "SHOULD be 1003 assigned the GeneralizedTime value of 99991231235959Z". Registrars 1004 MUST support such lifetimes and SHOULD support ignoring pledge 1005 lifetimes if they did not follow the RFC5280 recommendations. 1007 For example, IDevID may have incorrect lifetime of N <= 3 years, 1008 rendering replacement pledges from storage useless after N years 1009 unless registrars support ignoring such a lifetime. 1011 2.7. Cloud Registrar 1013 There exist operationally open network wherein devices gain 1014 unauthenticated access to the internet at large. In these use cases 1015 the management domain for the device needs to be discovered within 1016 the larger internet. These are less likely within the anima scope 1017 but may be more important in the future. 1019 There are additionally some greenfield situations involving an 1020 entirely new installation where a device may have some kind of 1021 management uplink that it can use (such as via 3G network for 1022 instance). In such a future situation, the device might use this 1023 management interface to learn that it should configure itself to 1024 become the local registrar. 1026 In order to support these scenarios, the pledge MAY contact a well 1027 known URI of a cloud registrar if a local registrar cannot be 1028 discovered or if the pledge's target use cases do not include a local 1029 registrar. 1031 If the pledge uses a well known URI for contacting a cloud registrar 1032 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 1033 authenticate service as described in [RFC6125]. This is consistent 1034 with the human user configuration of an EST server URI in [RFC7030] 1035 which also depends on RFC6125. 1037 2.8. Determining the MASA to contact 1039 The registrar needs to be able to contact a MASA that is trusted by 1040 the pledge in order to obtain vouchers. There are three mechanisms 1041 described: 1043 The device's Initial Device Identifier (IDevID) will normally contain 1044 the MASA URL as detailed in Section 2.3. This is the RECOMMENDED 1045 mechanism. 1047 If the registrar is integrated with [I-D.ietf-opsawg-mud] and the 1048 pledge IDevID contains the id-pe-mud-url then the registrar MAY 1049 attempt to obtain the MASA URL from the MUD file. The MUD file 1050 extension for the MASA URL is defined in Appendix C. 1052 It can be operationally difficult to ensure the necessary X.509 1053 extensions are in the pledge's IDevID due to the difficulty of 1054 aligning current pledge manufacturing with software releases and 1055 development. As a final fallback the registrar MAY be manually 1056 configured or distributed with a MASA URL for each manufacturer. 1057 Note that the registrar can only select the configured MASA URL based 1058 on the trust anchor -- so manufacturers can only leverage this 1059 approach if they ensure a single MASA URL works for all pledge's 1060 associated with each trust anchor. 1062 3. Voucher-Request artifact 1064 Voucher-requests are how vouchers are requested. The semantics of 1065 the vouchers are described below, in the YANG model. 1067 A pledge forms the "pledge voucher-request" and submits it to the 1068 registrar. 1070 The registrar in turn forms the "registrar voucher-request", and 1071 submits it to the MASA. 1073 The "proximity-registrar-cert" leaf is used in the pledge voucher- 1074 requests. This provides a method for the pledge to assert the 1075 registrar's proximity. 1077 The "prior-signed-voucher-request" leaf is used in registrar voucher- 1078 requests. If present, it is the encoded (signed form) of the pledge 1079 voucher-request. This provides a method for the registrar to forward 1080 the pledge's signed request to the MASA. This completes transmission 1081 of the signed "proximity-registrar-cert" leaf. 1083 Unless otherwise signaled (outside the voucher-request artifact), the 1084 signing structure is as defined for vouchers, see [RFC8366]. 1086 3.1. Nonceless Voucher Requests 1088 A registrar MAY also retrieve nonceless vouchers by sending nonceless 1089 voucher-requests to the MASA in order to obtain vouchers for use when 1090 the registrar does not have connectivity to the MASA. No "prior- 1091 signed-voucher-request" leaf would be included. The registrar will 1092 also need to know the serial number of the pledge. This document 1093 does not provide a mechanism for the registrar to learn that in an 1094 automated fashion. Typically this will be done via scanning of bar- 1095 code or QR-code on packaging, or via some sales channel integration. 1097 3.2. Tree Diagram 1099 The following tree diagram illustrates a high-level view of a 1100 voucher-request document. The voucher-request builds upon the 1101 voucher artifact described in [RFC8366]. The tree diagram is 1102 described in [RFC8340]. Each node in the diagram is fully described 1103 by the YANG module in Section 3.4. Please review the YANG module for 1104 a detailed description of the voucher-request format. 1106 module: ietf-voucher-request 1108 grouping voucher-request-grouping 1109 +-- voucher 1110 +-- created-on? yang:date-and-time 1111 +-- expires-on? yang:date-and-time 1112 +-- assertion? enumeration 1113 +-- serial-number string 1114 +-- idevid-issuer? binary 1115 +-- pinned-domain-cert? binary 1116 +-- domain-cert-revocation-checks? boolean 1117 +-- nonce? binary 1118 +-- last-renewal-date? yang:date-and-time 1119 +-- prior-signed-voucher-request? binary 1120 +-- proximity-registrar-cert? binary 1122 3.3. Examples 1124 This section provides voucher-request examples for illustration 1125 purposes. For detailed examples, see Appendix D.2. These examples 1126 conform to the encoding rules defined in [RFC7951]. 1128 Example (1) The following example illustrates a pledge voucher- 1129 request. The assertion leaf is indicated as 'proximity' 1130 and the registrar's TLS server certificate is included 1131 in the 'proximity-registrar-cert' leaf. See 1132 Section 5.2. 1134 { 1135 "ietf-voucher-request:voucher": { 1136 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1137 "created-on": "2017-01-01T00:00:00.000Z", 1138 "proximity-registrar-cert": "base64encodedvalue==" 1139 } 1140 } 1142 Example (2) The following example illustrates a registrar voucher- 1143 request. The 'prior-signed-voucher-request' leaf is 1144 populated with the pledge's voucher-request (such as the 1145 prior example). The pledge's voucher-request, if a 1146 signed artifact with a CMS format signature is a binary 1147 object. In the JSON encoding used here it must be 1148 base64 encoded. The nonce, created-on and assertion is 1149 carried forward. The serial-number is extracted from 1150 the pledge's Client Certificate from the TLS connection. 1151 See Section 5.5. 1153 { 1154 "ietf-voucher-request:voucher": { 1155 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1156 "created-on": "2017-01-01T00:00:02.000Z", 1157 "idevid-issuer": "base64encodedvalue==" 1158 "serial-number": "JADA123456789" 1159 "prior-signed-voucher-request": "base64encodedvalue==" 1160 } 1161 } 1163 Example (3) The following example illustrates a registrar voucher- 1164 request. The 'prior-signed-voucher-request' leaf is not 1165 populated with the pledge's voucher-request nor is the 1166 nonce leaf. This form might be used by a registrar 1167 requesting a voucher when the pledge can not communicate 1168 with the registrar (such as when it is powered down, or 1169 still in packaging), and therefore could not submit a 1170 nonce. This scenario is most useful when the registrar 1171 is aware that it will not be able to reach the MASA 1172 during deployment. See Section 5.5. 1174 { 1175 "ietf-voucher-request:voucher": { 1176 "created-on": "2017-01-01T00:00:02.000Z", 1177 "idevid-issuer": "base64encodedvalue==" 1178 "serial-number": "JADA123456789" 1179 } 1180 } 1182 Example (4) The following example illustrates a registrar voucher- 1183 request. The 'prior-signed-voucher-request' leaf is not 1184 populated with the pledge voucher-request because the 1185 pledge did not sign its own request. This form might be 1186 used when more constrained pledges are being deployed. 1187 The nonce is populated from the pledge's request. See 1188 Section 5.5. 1190 { 1191 "ietf-voucher-request:voucher": { 1192 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1193 "created-on": "2017-01-01T00:00:02.000Z", 1194 "idevid-issuer": "base64encodedvalue==" 1195 "serial-number": "JADA123456789" 1196 } 1197 } 1199 3.4. YANG Module 1201 Following is a YANG [RFC7950] module formally extending the [RFC8366] 1202 voucher into a voucher-request. 1204 file "ietf-voucher-request@2018-02-14.yang" 1205 module ietf-voucher-request { 1206 yang-version 1.1; 1208 namespace 1209 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 1210 prefix "vch"; 1212 import ietf-restconf { 1213 prefix rc; 1214 description "This import statement is only present to access 1215 the yang-data extension defined in RFC 8040."; 1216 reference "RFC 8040: RESTCONF Protocol"; 1217 } 1219 import ietf-voucher { 1220 prefix v; 1221 description "This module defines the format for a voucher, 1222 which is produced by a pledge's manufacturer or 1223 delegate (MASA) to securely assign a pledge to 1224 an 'owner', so that the pledge may establish a secure 1225 conn ection to the owner's network infrastructure"; 1227 reference "RFC YYYY: Voucher Profile for Bootstrapping Protocols"; 1228 } 1230 organization 1231 "IETF ANIMA Working Group"; 1233 contact 1234 "WG Web: 1235 WG List: 1236 Author: Kent Watsen 1237 1238 Author: Max Pritikin 1239 1240 Author: Michael Richardson 1241 1242 Author: Toerless Eckert 1243 "; 1245 description 1246 "This module defines the format for a voucher request. 1248 It is a superset of the voucher itself. 1249 This artifact may be optionally signed. 1250 It provides content to the MASA for consideration 1251 during a voucher request. 1253 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 1254 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 1255 the module text are to be interpreted as described in RFC 2119. 1257 Copyright (c) 2017 IETF Trust and the persons identified as 1258 authors of the code. All rights reserved. 1260 Redistribution and use in source and binary forms, with or without 1261 modification, is permitted pursuant to, and subject to the license 1262 terms contained in, the Simplified BSD License set forth in Section 1263 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1264 (http://trustee.ietf.org/license-info). 1266 This version of this YANG module is part of RFC XXXX; see the RFC 1267 itself for full legal notices."; 1269 revision "2018-02-14" { 1270 description 1271 "Initial version"; 1272 reference 1273 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 1274 } 1276 // Top-level statement 1277 rc:yang-data voucher-request-artifact { 1278 uses voucher-request-grouping; 1279 } 1281 // Grouping defined for future usage 1282 grouping voucher-request-grouping { 1283 description 1284 "Grouping to allow reuse/extensions in future work."; 1286 uses v:voucher-artifact-grouping { 1287 refine "voucher/created-on" { 1288 mandatory false; 1289 } 1291 refine "voucher/pinned-domain-cert" { 1292 mandatory false; 1293 } 1295 refine "voucher/domain-cert-revocation-checks" { 1296 description "The domain-cert-revocation-checks field 1297 is not valid in a voucher request, and 1298 any occurance MUST be ignored"; 1299 } 1301 refine "voucher/assertion" { 1302 mandatory false; 1303 description "Any assertion included in voucher 1304 requests SHOULD be ignored by the MASA."; 1305 } 1307 augment "voucher" { 1308 description 1309 "Adds leaf nodes appropriate for requesting vouchers."; 1311 leaf prior-signed-voucher-request { 1312 type binary; 1313 description 1314 "If it is necessary to change a voucher, or re-sign and 1315 forward a voucher that was previously provided along a 1316 protocol path, then the previously signed voucher SHOULD be 1317 included in this field. 1319 For example, a pledge might sign a voucher request 1320 with a proximity-registrar-cert, and the registrar 1321 then includes it in the prior-signed-voucher-request field. 1322 This is a simple mechanism for a chain of trusted 1323 parties to change a voucher request, while 1324 maintaining the prior signature information. 1326 The Registrar and MASA MAY examine the prior signed 1327 voucher information for the 1328 purposes of policy decisions. For example this information 1329 could be useful to a MASA to determine that both pledge and 1330 registrar agree on proximity assertions. The MASA SHOULD 1331 remove all prior-signed-voucher-request information when 1332 signing a voucher for imprinting so as to minimize the 1333 final voucher size."; 1334 } 1336 leaf proximity-registrar-cert { 1337 type binary; 1338 description 1339 "An X.509 v3 certificate structure as specified by RFC 5280, 1340 Section 4 encoded using the ASN.1 distinguished encoding 1341 rules (DER), as specified in ITU-T X.690. 1343 The first certificate in the Registrar TLS server 1344 certificate_list sequence (see [RFC5246]) presented by 1345 the Registrar to the Pledge. This MUST be populated in a 1346 Pledge's voucher request if a proximity assertion is 1347 requested."; 1348 } 1349 } 1350 } 1351 } 1353 } 1355 1357 4. Proxying details (Pledge - Proxy - Registrar) 1359 The role of the proxy is to facilitate communications. The proxy 1360 forwards packets between the pledge and a registrar that has been 1361 provisioned to the proxy via GRASP discovery. 1363 This section defines a stateful proxy mechanism which is refered to 1364 as a "circuit" proxy. 1366 The proxy does not terminate the TLS handshake: it passes streams of 1367 bytes onward without examination. A proxy MUST NOT assume any 1368 specific TLS version. 1370 A Registrar can directly provide the proxy announcements described 1371 below, in which case the announced port can point directly to the 1372 Registrar itself. In this scenario the pledge is unaware that there 1373 is no proxing occuring. This is useful for Registrars servicing 1374 pledges on directly connected networks. 1376 As a result of the proxy Discovery process in Section 4.1.1, the port 1377 number exposed by the proxy does not need to be well known, or 1378 require an IANA allocation. 1380 During the discovery of the Registrar by the Join Proxy, the Join 1381 Proxy will also learn which kinds of proxy mechanisms are available. 1382 This will allow the Join Proxy to use the lowest impact mechanism 1383 which the Join Proxy and Registrar have in common. 1385 In order to permit the proxy functionality to be implemented on the 1386 maximum variety of devices the chosen mechanism SHOULD use the 1387 minimum amount of state on the proxy device. While many devices in 1388 the ANIMA target space will be rather large routers, the proxy 1389 function is likely to be implemented in the control plane CPU of such 1390 a device, with available capabilities for the proxy function similar 1391 to many class 2 IoT devices. 1393 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1394 more extensive analysis and background of the alternative proxy 1395 methods. 1397 4.1. Pledge discovery of Proxy 1399 The result of discovery is a logical communication with a registrar, 1400 through a proxy. The proxy is transparent to the pledge. The 1401 communication between the pledge is over IPv6 Link-Local addresses. 1403 To discover the proxy the pledge performs the following actions: 1405 1. MUST: Obtains a local address using IPv6 methods as described in 1406 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1407 [RFC4941] temporary addresses is encouraged. To limit pervasive 1408 monitoring ( [RFC7258]), a new temporary address MAY use a short 1409 lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). 1410 Pledges will generally prefer use of IPv6 Link-Local addresses, 1411 and discovery of proxy will be by Link-Local mechanisms. IPv4 1412 methods are described in Appendix A 1414 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1415 announcements of the objective: "AN_Proxy". See section 1416 Section 4.1.1 for the details of the objective. The pledge MAY 1417 listen concurrently for other sources of information, see 1418 Appendix B. 1420 Once a proxy is discovered the pledge communicates with a registrar 1421 through the proxy using the bootstrapping protocol defined in 1422 Section 5. 1424 While the GRASP M_FLOOD mechanism is passive for the pledge, the 1425 optional other methods (mDNS, and IPv4 methods) are active. The 1426 pledge SHOULD run those methods in parallel with listening to for the 1427 M_FLOOD. The active methods SHOULD exponentially back-off to a 1428 maximum of one hour to avoid overloading the network with discovery 1429 attempts. Detection of change of physical link status (ethernet 1430 carrier for instance) SHOULD reset the exponential back off. 1432 The pledge could discover more than one proxy on a given physical 1433 interface. The pledge can have a multitude of physical interfaces as 1434 well: a layer-2/3 ethernet switch may have hundreds of physical 1435 ports. 1437 Each possible proxy offer SHOULD be attempted up to the point where a 1438 voucher is received: while there are many ways in which the attempt 1439 may fail, it does not succeed until the voucher has been validated. 1441 The connection attempts via a single proxy SHOULD exponentially back- 1442 off to a maximum of one hour to avoid overloading the network 1443 infrastructure. The back-off timer for each MUST be independent of 1444 other connection attempts. 1446 Connection attempts SHOULD be run in parallel to avoid head of queue 1447 problems wherein an attacker running a fake proxy or registrar could 1448 perform protocol actions intentionally slowly. The pledge SHOULD 1449 continue to listen to for additional GRASP M_FLOOD messages during 1450 the connection attempts. 1452 Once a connection to a registrar is established (e.g. establishment 1453 of a TLS session key) there are expectations of more timely 1454 responses, see Section 5.2. 1456 Once all discovered services are attempted (assuming that none 1457 succeeded) the device MUST return to listening for GRASP M_FLOOD. It 1458 SHOULD periodically retry the manufacturer specific mechanisms. The 1459 pledge MAY prioritize selection order as appropriate for the 1460 anticipated environment. 1462 4.1.1. Proxy GRASP announcements 1464 A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. 1465 This announcement can be within the same message as the ACP 1466 announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. 1467 The M_FLOOD is formatted as follows: 1469 [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, 1470 ["AN_Proxy", 4, 1, ""], 1471 [O_IPv6_LOCATOR, 1472 h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] 1474 Figure 6b: Proxy Discovery 1476 The formal CDDL [I-D.ietf-cbor-cddl] definition is: 1478 flood-message = [M_FLOOD, session-id, initiator, ttl, 1479 +[objective, (locator-option / [])]] 1481 objective = ["AN_Proxy", objective-flags, loop-count, 1482 objective-value] 1484 ttl = 180000 ; 180,000 ms (3 minutes) 1485 initiator = ACP address to contact Registrar 1486 objective-flags = sync-only ; as in GRASP spec 1487 sync-only = 4 ; M_FLOOD only requires synchronization 1488 loop-count = 1 ; one hop only 1489 objective-value = any ; none 1491 locator-option = [ O_IPv6_LOCATOR, ipv6-address, 1492 transport-proto, port-number ] 1493 ipv6-address = the v6 LL of the Proxy 1494 transport-proto /= IPPROTO_TCP ; note this can be any value from the 1495 ; IANA protocol registry, as per 1496 ; [GRASP] section 2.9.5.1, note 3. 1497 port-number = selected by Proxy 1499 Figure 6c: AN_Proxy CDDL 1501 On a small network the Registrar MAY include the GRASP M_FLOOD 1502 announcements to locally connected networks. 1504 The $transport-proto above indicates the method that the pledge- 1505 proxy-registrar will use. The TCP method described here is 1506 mandatory, and other proxy methods, such as CoAP methods not defined 1507 in this document are optional. Other methods MUST NOT be enabled 1508 unless the Join Registrar ASA indicates support for them in it's own 1509 announcement. 1511 4.2. CoAP connection to Registrar 1513 The use of CoAP to connect from pledge to registrar is out of scope 1514 for this document, and is described in future work. See 1515 [I-D.ietf-anima-constrained-voucher]. 1517 4.3. Proxy discovery and communication of Registrar 1519 The registrar SHOULD announce itself so that proxies can find it and 1520 determine what kind of connections can be terminated. 1522 The registrar announces itself using ACP instance of GRASP using 1523 M_FLOOD messages. ANI proxies MUST support GRASP discovery of 1524 registrars. 1526 The M_FLOOD is formatted as follows: 1528 [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, 1529 ["AN_join_registrar", 4, 255, "EST-TLS"], 1530 [O_IPv6_LOCATOR, 1531 h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 80]] 1533 Figure 7a: Registrar Discovery 1535 The formal CDDL definition is: 1537 flood-message = [M_FLOOD, session-id, initiator, ttl, 1538 +[objective, (locator-option / [])]] 1540 objective = ["AN_join_registrar", objective-flags, loop-count, 1541 objective-value] 1543 initiator = ACP address to contact Registrar 1544 objective-flags = sync-only ; as in GRASP spec 1545 sync-only = 4 ; M_FLOOD only requires synchronization 1546 loop-count = 255 ; mandatory maximum 1547 objective-value = text ; name of the (list of) of supported 1548 ; protocols: "EST-TLS" for RFC7030. 1550 Figure 7: AN_join_registrar CDDL 1552 The M_FLOOD message MUST be sent periodically. The period is subject 1553 to network administrator policy (EST server configuration). It must 1554 be sufficiently low that the aggregate amount of periodic M_FLOODs 1555 from all EST servers causes negligible traffic across the ACP. 1557 Here are some examples of locators for illustrative purposes. Only 1558 the first one (transport-protocol = 6, TCP) is defined in this 1559 document and is mandatory to implement. 1561 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1562 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1563 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1565 A protocol of 6 indicates that TCP proxying on the indicated port is 1566 desired. 1568 Registrars MUST announce the set of protocols that they support. 1569 They MUST support TCP traffic. 1571 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1573 Registrars MUST support ANI TLS circuit proxy and therefore BRSKI 1574 across HTTPS/TLS native across the ACP. 1576 In the ANI, the Autonomic Control Plane (ACP) secured instance of 1577 GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI 1578 registrar ACP addresses and ports by ANI proxies. The TCP leg of the 1579 proxy connection between ANI proxy and ANI registrar therefore also 1580 runs across the ACP. 1582 5. Protocol Details (Pledge - Registrar - MASA) 1584 The pledge MUST initiate BRSKI after boot if it is unconfigured. The 1585 pledge MUST NOT automatically initiate BRSKI if it has been 1586 configured or is in the process of being configured. 1588 BRSKI is described as extensions to EST [RFC7030]. The goal of these 1589 extensions is to reduce the number of TLS connections and crypto 1590 operations required on the pledge. The registrar implements the 1591 BRSKI REST interface within the same "/.well-known" URI tree as the 1592 existing EST URIs as described in EST [RFC7030] section 3.2.2. The 1593 communication channel between the pledge and the registrar is 1594 referred to as "BRSKI-EST" (see Figure 1). 1596 The communication channel between the registrar and MASA is similarly 1597 described as extensions to EST within the same "/.well-known" tree. 1598 For clarity this channel is referred to as "BRSKI-MASA". (See 1599 Figure 1). 1601 MASA URI is "https://" iauthority "/.well-known/est". 1603 BRSKI uses existing CMS message formats for existing EST operations. 1604 BRSKI uses JSON [RFC7159] for all new operations defined here, and 1605 voucher formats. 1607 While EST section 3.2 does not insist upon use of HTTP 1.1 persistent 1608 connections, BRSKI-EST connections SHOULD use persistent connections. 1609 The intention of this guidance is to ensure the provisional TLS state 1610 occurs only once, and that the subsequent resolution of the provision 1611 state is not subject to a MITM attack during a critical phase. 1613 Summarized automation extensions for the BRSKI-EST flow are: 1615 o The pledge either attempts concurrent connections via each 1616 discovered proxy, or it times out quickly and tries connections in 1617 series, as explained at the end of Section 5.1. 1619 o The pledge provisionally accepts the registrar certificate during 1620 the TLS handshake as detailed in Section 5.1. 1622 o The pledge requests and validates a voucher using the new REST 1623 calls described below. 1625 o The pledge completes authentication of the server certificate as 1626 detailed in Section 5.6.1. This moves the BRSKI-EST TLS 1627 connection out of the provisional state. 1629 o Mandatory boostrap steps conclude with voucher status telemetry 1630 (see Section 5.7). 1632 The BRSKI-EST TLS connection can now be used for EST enrollment. 1634 The extensions for a registrar (equivalent to EST server) are: 1636 o Client authentication is automated using Initial Device Identity 1637 (IDevID) as per the EST certificate based client authentication. 1638 The subject field's DN encoding MUST include the "serialNumber" 1639 attribute with the device's unique serial number. 1641 o In the language of [RFC6125] this provides for a SERIALNUM-ID 1642 category of identifier that can be included in a certificate and 1643 therefore that can also be used for matching purposes. The 1644 SERIALNUM-ID whitelist is collated according to manufacturer trust 1645 anchor since serial numbers are not globally unique. 1647 o The registrar requests and validates the voucher from the MASA. 1649 o The registrar forwards the voucher to the pledge when requested. 1651 o The registrar performs log verifications in addition to local 1652 authorization checks before accepting optional pledge device 1653 enrollment requests. 1655 5.1. BRSKI-EST TLS establishment details 1657 The pledge establishes the TLS connection with the registrar through 1658 the circuit proxy (see Section 4) but the TLS handshake is with the 1659 registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST 1660 registrar is the TLS server. All security associations established 1661 are between the pledge and the registrar regardless of proxy 1662 operations. 1664 Establishment of the BRSKI-EST TLS connection is as specified in EST 1665 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1666 [RFC7030] wherein the client is authenticated with the IDevID 1667 certificate, and the EST server (the registrar) is provisionally 1668 authenticated with an unverified server certificate. 1670 The pledge maintains a security paranoia concerning the provisional 1671 state, and all data received, until a voucher is received and 1672 verified as specified in Section 5.6.1 1674 A Pledge that can connect to multiple registries concurrently, SHOULD 1675 do so. Some devices may be unable to do so for lack of threading, or 1676 resource issues. Concurrent connections defeat atttempts by a 1677 malicious proxy from causing a TCP Slowloris-like attack (see 1678 [slowloris]). 1680 A pledge that can not maintain as many connections as there are 1681 eligible proxies. If no connection is making process after 5 seconds 1682 then the pledge SHOULD drop the oldest connection and go on to a 1683 different proxy: the proxy that has been communicated with least 1684 recently. If there were no other proxies discovered, the pledge MAY 1685 continue to wait, as long as it is concurrently listening for new 1686 proxy announcements. 1688 5.2. Pledge Requests Voucher from the Registrar 1690 When the pledge bootstraps it makes a request for a voucher from a 1691 registrar. 1693 This is done with an HTTPS POST using the operation path value of 1694 "/.well-known/est/requestvoucher". 1696 The request media types are: 1698 application/voucher-cms+json The request is a "YANG-defined JSON 1699 document that has been signed using a CMS structure" as described 1700 in Section 3 using the JSON encoding described in [RFC7951]. The 1701 pledge SHOULD sign the request using the Section 2.3 credential. 1703 application/json The request is the "YANG-defined JSON document" as 1704 described in Section 3 with the exception that it is not within a 1705 CMS structure. It is protected only by the TLS client 1706 authentication. This reduces the cryptographic requirements on 1707 the pledge. 1709 For simplicity the term 'voucher-request' is used to refer to either 1710 of these media types. Registrar impementations SHOULD anticipate 1711 future media types but of course will simply fail the request if 1712 those types are not yet known. 1714 The pledge populates the voucher-request fields as follows: 1716 created-on: Pledges that have a realtime clock are RECOMMENDED to 1717 populate this field. This provides additional information to the 1718 MASA. 1720 nonce: The pledge voucher-request MUST contain a cryptographically 1721 strong random or pseudo-random number nonce. (see [RFC4086]) Doing 1722 so ensures Section 2.6.1 functionality. The nonce MUST NOT be 1723 reused for multiple bootstrapping attempts. (The registrar 1724 voucher-request MAY omit the nonce as per Section 3.1) 1726 proximity-registrar-cert: In a pledge voucher-request this is the 1727 first certificate in the TLS server 'certificate_list' sequence 1728 (see [RFC5246]) presented by the registrar to the pledge. This 1729 MUST be populated in a pledge voucher-request if the "proximity" 1730 assertion is populated. 1732 All other fields MAY be omitted in the pledge voucher-request. 1734 An example JSON payload of a pledge voucher-request is in Section 3.3 1735 Example 1. 1737 The registrar validates the client identity as described in EST 1738 [RFC7030] section 3.3.2. If the request is signed the registrar 1739 confirms that the associated 'proximity-registrar-cert' is correct. 1741 5.3. Registrar Authorization of Pledge 1743 In a fully automated network all devices must be securely identified 1744 and authorized to join the domain. 1746 A Registrar accepts or declines a request to join the domain, based 1747 on the authenticated identity presented. Automated acceptance 1748 criteria include: 1750 o allow any device of a specific type (as determined by the X.509 1751 IDevID), 1753 o allow any device from a specific vendor (as determined by the 1754 X.509 IDevID), 1756 o allow a specific device from a vendor (as determined by the X.509 1757 IDevID) against a domain white list. (The mechanism for checking 1758 a shared white list potentially used by multiple Registrars is out 1759 of scope). 1761 If these validations fail the registrar SHOULD respond with an 1762 appropriate HTTP error code. 1764 If authorization is successful the registrar obtains a voucher from 1765 the MASA service (see Section 5.5) and returns that MASA signed 1766 voucher to the pledge as described in Section 5.6. 1768 5.4. BRSKI-MASA TLS establishment details 1770 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1771 appropriate for HTTPS REST interfaces. The registrar initiates the 1772 connection and uses the MASA URL obtained as described in Section 2.8 1773 for [RFC6125] authentication of the MASA. 1775 The primary method of registrar "authentication" by the MASA is 1776 detailed in Section 5.5. As detailed in Section 10 the MASA might 1777 find it necessary to request additional registrar authentication. 1779 The MASA and the registrars SHOULD be prepared to support TLS client 1780 certificate authentication and/or HTTP Basic or Digest authentication 1781 as described in RFC7030 for EST clients. This connection MAY also 1782 have no client authentication at all (Section 6.4) 1784 The authentication of the BRSKI-MASA connection does not affect the 1785 voucher-request process, as voucher-requests are already signed by 1786 the registrar. Instead, this authentication provides access control 1787 to the audit log. 1789 Implementors are advised that contacting the MASA is to establish a 1790 secured REST connection with a web service and that there are a 1791 number of authentication models being explored within the industry. 1792 Registrars are RECOMMENDED to fail gracefully and generate useful 1793 administrative notifications or logs in the advent of unexpected HTTP 1794 401 (Unauthorized) responses from the MASA. 1796 5.5. Registrar Requests Voucher from MASA 1798 When a registrar receives a pledge voucher-request it in turn submits 1799 a registrar voucher-request to the MASA service via an HTTPS RESTful 1800 interface ([RFC7231]). 1802 This is done with an HTTP POST using the operation path value of 1803 "/.well-known/est/requestvoucher". 1805 The request media type is defined in [RFC8366] and is application/ 1806 voucher-cms+json. It is a JSON document that has been signed using a 1807 CMS structure. The registrar MUST sign the registrar voucher- 1808 request. The entire registrar certificate chain, up to and including 1809 the Domain CA, MUST be included in the CMS structure. 1811 MASA impementations SHOULD anticipate future media types but of 1812 course will simply fail the request if those types are not yet known. 1814 The registrar populates the voucher-request fields as follows: 1816 created-on: Registrars are RECOMMENDED to populate this field. This 1817 provides additional information to the MASA. 1819 nonce: This is the value from the pledge voucher-request. The 1820 registrar voucher-request MAY omit the nonce as per Section 3.1) 1822 serial-number: The serial number of the pledge the registrar would 1823 like a voucher for. The registrar determines this value by 1824 parsing the authenticated pledge IDevID certificate. See 1825 Section 2.3. The registrar MUST verify that the serial number 1826 field it parsed matches the serial number field the pledge 1827 provided in its voucher-request. This provides a sanity check 1828 useful for detecting error conditions and logging. The registrar 1829 MUST NOT simply copy the serial number field from a pledge voucher 1830 request as that field is claimed but not certified. 1832 idevid-issuer: The idevid-issuer value from the pledge certificate 1833 is included to ensure a statistically unique identity. 1835 prior-signed-voucher-request: If a signed pledge voucher-request was 1836 received then it SHOULD be included in the registrar voucher- 1837 request. (NOTE: what is included is the complete pledge voucher- 1838 request, inclusive of the 'assertion', 'proximity-registrar-cert', 1839 etc wrapped by the pledge's original signature). If a signed 1840 voucher-request was not recieved from the pledge then this leaf is 1841 omitted from the registrar voucher request. 1843 A nonceless registrar voucher-request MAY be submitted to the MASA. 1844 Doing so allows the registrar to request a voucher when the pledge is 1845 offline, or when the registrar anticipates not being able to connect 1846 to the MASA while the pledge is being deployed. Some use cases 1847 require the registrar to learn the appropriate IDevID SerialNumber 1848 field from the physical device labeling or from the sales channel 1849 (out-of-scope for this document). 1851 All other fields MAY be omitted in the registrar voucher-request. 1853 Example JSON payloads of registrar voucher-requests are in 1854 Section 3.3 Examples 2 through 4. 1856 The MASA verifies that the registrar voucher-request is internally 1857 consistent but does not necessarily authenticate the registrar 1858 certificate since the registrar is not known to the MASA in advance. 1860 The MASA performs the actions and validation checks described in the 1861 following sub-sections before issuing a voucher. 1863 5.5.1. MASA renewal of expired vouchers 1865 As described in [RFC8366] vouchers are normally short lived to avoid 1866 revocation issues. If the request is for a previous (expired) 1867 voucher using the same registrar then the request for a renewed 1868 voucher SHOULD be automatically authorized. The MASA has sufficient 1869 information to determine this by examining the request, the registrar 1870 authentication, and the existing audit log. The issuance of a 1871 renewed voucher is logged as detailed in Section 5.6. 1873 To inform the MASA that existing vouchers are not to be renewed one 1874 can update or revoke the registrar credentials used to authorize the 1875 request (see Section 5.5.3 and Section 5.5.4). More flexible methods 1876 will likely involve sales channel integration and authorizations 1877 (details are out-of-scope of this document). 1879 5.5.2. MASA verification of voucher-request signature consistency 1881 The MASA MUST verify that the registrar voucher-request is signed by 1882 a registrar. This is confirmed by verifying that the id-kp-cmcRA 1883 extended key usage extension field (as detailed in EST RFC7030 1884 section 3.6.1) exists in the certificate of the entity that signed 1885 the registrar voucher-request. This verification is only a 1886 consistency check that the unauthenticated domain CA intended the 1887 voucher-request signer to be a registrar. Performing this check 1888 provides value to the domain PKI by assuring the domain administrator 1889 that the MASA service will only respect claims from authorized 1890 Registration Authorities of the domain. 1892 The MASA verifies that the domain CA certificate is included in the 1893 CMS structure as detailed in Section 5.5. 1895 5.5.3. MASA authentication of registrar (certificate) 1897 If a nonceless voucher-request is submitted the MASA MUST 1898 authenticate the registrar as described in either EST [RFC7030] 1899 section 3.2, section 3.3, or by validating the registrar's 1900 certificate used to sign the registrar voucher-request. Any of these 1901 methods reduce the risk of DDoS attacks and provide an authenticated 1902 identity as an input to sales channel integration and authorizations 1903 (details are out-of-scope of this document). 1905 In the nonced case, validation of the registrar MAY be omitted if the 1906 device policy is to accept audit-only vouchers. 1908 5.5.4. MASA revocation checking of registrar (certificate) 1910 As noted in Section 5.5.3 the MASA performs registrar authentication 1911 in a subset of situations (e.g. nonceless voucher requests). Normal 1912 PKIX revocation checking is assumed during either EST client 1913 authentication or voucher-request signature validation. Similarly, 1914 as noted in Section 5.5.2, the MASA performs normal PKIX revocation 1915 checking during signature consistency checks (a signature by a 1916 registrar certificate that has been revoked is an inconsistency). 1918 5.5.5. MASA verification of pledge prior-signed-voucher-request 1920 The MASA MAY verify that the registrar voucher-request includes the 1921 'prior-signed-voucher-request' field. If so the prior-signed- 1922 voucher-request MUST include a 'proximity-registrar-cert' that is 1923 consistent with the certificate used to sign the registrar voucher- 1924 request. Additionally the voucher-request serial-number leaf MUST 1925 match the pledge serial-number that the MASA extracts from the 1926 signing certificate of the prior-signed-voucher-request. The MASA is 1927 aware of which pledges support signing of their voucher requests and 1928 can use this information to confirm proximity of the pledge with the 1929 registrar, thus ensuring that the BRSKI-EST TLS connection has no 1930 man-in-the-middle. 1932 If these checks succeed the MASA updates the voucher and audit log 1933 assertion leafs with the "proximity" assertion. 1935 5.5.6. MASA pinning of registrar 1937 The registrar's certificate chain is extracted from the signature 1938 method. The chain includes the domain CA certificate as specified in 1939 Section 5.5. This certificate is used to populate the "pinned- 1940 domain-cert" of the voucher being issued. The domainID (e.g., hash 1941 of the root public key) is determined from the pinned-domain-cert and 1942 is used to update the audit log. 1944 5.5.7. MASA nonce handling 1946 The MASA does not verify the nonce itself. If the registrar voucher- 1947 request contains a nonce, and the prior-signed-voucher-request is 1948 exist, then the MASA MUST verify that the nonce is consistent. 1949 (Recall from above that the voucher-request might not contain a 1950 nonce, see Section 5.5 and Section 5.5.3). 1952 The MASA MUST use the nonce from the registrar voucher-request for 1953 the resulting voucher and audit log. The prior-signed-voucher- 1954 request nonce is ignored during this operation. 1956 5.6. MASA and Registrar Voucher Response 1958 The MASA voucher response to the registrar is forwarded without 1959 changes to the pledge; therefore this section applies to both the 1960 MASA and the registrar. The HTTP signaling described applies to both 1961 the MASA and registrar responses. A registrar either caches prior 1962 MASA responses or dynamically requests a new voucher based on local 1963 policy (it does not generate or sign a voucher). 1965 If the voucher-request is successful, the server (MASA responding to 1966 registrar or registrar responding to pledge) response MUST contain an 1967 HTTP 200 response code. The server MUST answer with a suitable 4xx 1968 or 5xx HTTP [RFC2616] error code when a problem occurs. In this 1969 case, the response data from the MASA MUST be a plaintext human- 1970 readable (ASCII, English) error message containing explanatory 1971 information describing why the request was rejected. 1973 The registrar MAY respond with an HTTP 202 ("the request has been 1974 accepted for processing, but the processing has not been completed") 1975 as described in EST [RFC7030] section 4.2.3 wherein the client "MUST 1976 wait at least the specified 'Retry-After' time before repeating the 1977 same request". (see [RFC7231] section 6.6.4) The pledge is 1978 RECOMMENDED to provide local feedback (blinked LED etc) during this 1979 wait cycle if mechanisms for this are available. To prevent an 1980 attacker registrar from significantly delaying bootstrapping the 1981 pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the 1982 pledge would keep track of the appropriate Retry-After header values 1983 for any number of outstanding registrars but this would involve a 1984 state table on the pledge. Instead the pledge MAY ignore the exact 1985 Retry-After value in favor of a single hard coded value (a registrar 1986 that is unable to complete the transaction after the first 60 seconds 1987 has another chance a minute later). A pledge SHOULD only maintain a 1988 202 retry-state for up to 4 days, which is longer than a long 1989 weekend, after which time the enrollment attempt fails and the pledge 1990 returns to discovery state. 1992 In order to avoid infinite redirect loops, which a malicious 1993 registrar might do in order to keep the pledge from discovering the 1994 correct registrar, the pledge MUST NOT follow more than one 1995 redirection (3xx code) to another web origins. EST supports 1996 redirection but requires user input; this change allows the pledge to 1997 follow a single redirection without a user interaction. 1999 A 403 (Forbidden) response is appropriate if the voucher-request is 2000 not signed correctly, stale, or if the pledge has another outstanding 2001 voucher that cannot be overridden. 2003 A 404 (Not Found) response is appropriate when the request is for a 2004 device that is not known to the MASA. 2006 A 406 (Not Acceptable) response is appropriate if a voucher of the 2007 desired type or using the desired algorithms (as indicated by the 2008 Accept: headers, and algorithms used in the signature) cannot be 2009 issued such as because the MASA knows the pledge cannot process that 2010 type. The registrar SHOULD use this response if it determines the 2011 pledge is unacceptable due to inventory control, MASA audit logs, or 2012 any other reason. 2014 A 415 (Unsupported Media Type) response is approriate for a request 2015 that has a voucher encoding that is not understood. 2017 The response media type is: 2019 application/voucher-cms+json The response is a "YANG-defined JSON 2020 document that has been signed using a CMS structure" as described 2021 in [RFC8366] using the JSON encoded described in [RFC7951]. The 2022 MASA MUST sign the response. 2024 The syntactic details of vouchers are described in detail in 2025 [RFC8366]. For example, the voucher consists of: 2027 { 2028 "ietf-voucher:voucher": { 2029 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 2030 "assertion": "logging" 2031 "pinned-domain-cert": "base64encodedvalue==" 2032 "serial-number": "JADA123456789" 2033 } 2034 } 2036 The MASA populates the voucher fields as follows: 2038 nonce: The nonce from the pledge if available. See Section 5.5.7. 2040 assertion: The method used to verify assertion. See Section 5.5.5. 2042 pinned-domain-cert: The domain CA cert. See Section 5.5.6. This 2043 figure is illustrative, for an example, see Appendix D.2 2045 serial-number: The serial-number as provided in the voucher-request. 2046 Also see Section 5.5.5. 2048 domain-cert-revocation-checks: Set as appropriate for the pledge's 2049 capabilities and as documented in [RFC8366]. The MASA MAY set 2050 this field to 'false' since setting it to 'true' would require 2051 that revocation information be available to the pledge and this 2052 document does not make normative requirements for [RFC6961] or 2053 equivalent integrations. 2055 expires-on: This is set for nonceless vouchers. The MASA ensures 2056 the voucher lifetime is consistent with any revocation or pinned- 2057 domain-cert consistency checks the pledge might perform. See 2058 section Section 2.6.1. There are three times to consider: (a) a 2059 configured voucher lifetime in the MASA, (b) the expiry time for 2060 the registrar's certificate, (c) any certificate revocation 2061 information (CRL) lifetime. The expires-on field SHOULD be before 2062 the earliest of these three values. Typically (b) will be some 2063 significant time in the future, but (c) will typically be short 2064 (on the order of a week or less). The RECOMMENDED period for (a) 2065 is on the order of 20 minutes, so it will typically determine the 2066 lifespan of the resulting voucher. 20 minutes is sufficent time 2067 to reach the post-provisional state in the pledge, at which point 2068 there is an established trust relationship between pledge and 2069 registrar. The subsequent operations can take as long as required 2070 from that point onwards. The lifetime of the voucher has no 2071 impact on the lifespan of the ownership relationship. 2073 Whenever a voucher is issued the MASA MUST update the audit log 2074 appropriately. The internal state requirements to maintain the audit 2075 log are out-of-scope. See Section 5.8.1 for a discussion of 2076 reporting the log to a registrar. 2078 5.6.1. Pledge voucher verification 2080 The pledge MUST verify the voucher signature using the manufacturer 2081 installed trust anchor(s) associated with the manufacturer's MASA 2082 (this is likely included in the pledge's firmware). Management of 2083 the manufacter installed trust anchor(s) is out-of-scope of this 2084 document; this protocol does not update these trust anchor(s). 2086 The pledge MUST verify the serial-number field of the signed voucher 2087 matches the pledge's own serial-number. 2089 The pledge MUST verify that the voucher nonce field is accurate and 2090 matches the nonce the pledge submitted to this registrar, or that the 2091 voucher is nonceless (see Section 6.2). 2093 The pledge MUST be prepared to parse and fail gracefully from a 2094 voucher response that does not contain a 'pinned-domain-cert' field. 2095 The pledge MUST be prepared to ignore additional fields that it does 2096 not recognize. 2098 5.6.2. Pledge authentication of provisional TLS connection 2100 The 'pinned-domain-cert' element of the voucher contains the domain 2101 CA's public key. The pledge MUST use the 'pinned-domain-cert' trust 2102 anchor to immediately complete authentication of the provisional TLS 2103 connection. 2105 If a registrar's credentials cannot be verified using the pinned- 2106 domain-cert trust anchor from the voucher then the TLS connection is 2107 immediately discarded and the pledge abandons attempts to bootstrap 2108 with this discovered registrar. The pledge SHOULD send voucher 2109 status telemetry (described below) before closing the TLS connection. 2110 The pledge MUST attempt to enroll using any other proxies it has 2111 found. It SHOULD return to the same proxy again after attempting 2112 with other proxies. Attempts should be attempted in the exponential 2113 backoff described earlier. Attempts SHOULD be repeated as failure 2114 may be the result of a temporary inconsistently (an inconsistently 2115 rolled registrar key, or some other mis-configuration). The 2116 inconsistently could also be the result an active MITM attack on the 2117 EST connection. 2119 The registrar MUST use a certificate that chains to the pinned- 2120 domain-cert as its TLS server certificate. 2122 The pledge's PKIX path validation of a registrar certificate's 2123 validity period information is as described in Section 2.6.1. Once 2124 the PKIX path validation is successful the TLS connection is no 2125 longer provisional. 2127 The pinned-domain-cert MAY be installed as an trust anchor for future 2128 operations such as enrollment (e.g. [RFC7030] as recommended) or 2129 trust anchor management or raw protocols that do not need full PKI 2130 based key management. It can be used to authenticate any dynamically 2131 discovered EST server that contain the id-kp-cmcRA extended key usage 2132 extension as detailed in EST RFC7030 section 3.6.1; but to reduce 2133 system complexity the pledge SHOULD avoid additional discovery 2134 operations. Instead the pledge SHOULD communicate directly with the 2135 registrar as the EST server. The 'pinned-domain-cert' is not a 2136 complete distribution of the [RFC7030] section 4.1.3 CA Certificate 2137 Response, which is an additional justification for the recommendation 2138 to proceed with EST key management operations. Once a full CA 2139 Certificate Response is obtained it is more authoritative for the 2140 domain than the limited 'pinned-domain-cert' response. 2142 5.7. Pledge BRSKI Status Telemetry 2144 The domain is expected to provide indications to the system 2145 administrators concerning device lifecycle status. To facilitate 2146 this it needs telemetry information concerning the device's status. 2148 To indicate pledge status regarding the voucher, the pledge MUST post 2149 a status message. 2151 The posted data media type: application/json 2153 The client HTTP POSTs the following to the server at the EST well 2154 known URI "/voucher_status". The Status field indicates if the 2155 voucher was acceptable. If it was not acceptable the Reason string 2156 indicates why. In the failure case this message may be sent to an 2157 unauthenticated, potentially malicious registrar and therefore the 2158 Reason string SHOULD NOT provide information beneficial to an 2159 attacker. The operational benefit of this telemetry information is 2160 balanced against the operational costs of not recording that an 2161 voucher was ignored by a client the registrar expected to continue 2162 joining the domain. 2164 { 2165 "version":"1", 2166 "Status":FALSE /* TRUE=Success, FALSE=Fail" 2167 "Reason":"Informative human readable message" 2168 "reason-context": { additional JSON } 2169 } 2171 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2172 an HTTP 404 error. The client ignores any response. Within the 2173 server logs the server SHOULD capture this telemetry information. 2175 The reason-context attribute is an arbitrary JSON object (literal 2176 value or hash of values) which provides additional information 2177 specific to this pledge. The contents of this field are not subject 2178 to standardization. 2180 Additional standard JSON fields in this POST MAY be added, see 2181 Section 7.3. 2183 5.8. Registrar audit log request 2185 After receiving the pledge status telemetry Section 5.7, the 2186 registrar SHOULD request the MASA audit log from the MASA service. 2188 This is done with an HTTP GET using the operation path value of 2189 "/.well-known/est/requestauditlog". 2191 The registrar SHOULD HTTP POST the same registrar voucher-request as 2192 it did when requesting a voucher. It is posted to the 2193 /requestauditlog URI instead. The "idevid-issuer" and "serial- 2194 number" informs the MASA which log is requested so the appropriate 2195 log can be prepared for the response. Using the same media type and 2196 message minimizes cryptographic and message operations although it 2197 results in additional network traffic. The relying MASA 2198 implementation MAY leverage internal state to associate this request 2199 with the original, and by now already validated, voucher-request so 2200 as to avoid an extra crypto validation. 2202 A registrar MAY request logs at future times. If the registrar 2203 generates a new request then the MASA is forced to perform the 2204 additional cryptographic operations to verify the new request. 2206 A MASA that receives a request for a device that does not exist, or 2207 for which the requesting owner was never an owner returns an HTTP 404 2208 ("Not found") code. 2210 Rather than returning the audit log as a response to the POST (with a 2211 return code 200), the MASA MAY instead return a 201 ("Created") 2212 RESTful response ([RFC7231] section 7.1) containing a URL to the 2213 prepared (and easily cachable) audit response. 2215 In order to avoid enumeration of device audit logs, MASA that return 2216 URLs SHOULD take care to make the returned URL unguessable. For 2217 instance, rather than returning URLs containing a database number 2218 such as https://example.com/auditlog/1234 or the EUI of the device 2219 such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD 2220 return a randomly generated value (a "slug" in web parlance). The 2221 value is used to find the relevant database entry. 2223 A MASA that returns a code 200 MAY also include a Location: header 2224 for future reference by the registrar. 2226 The request media type is: 2228 application/voucher-cms+json The request is a "YANG-defined JSON 2229 document that has been signed using a CMS structure" as described 2230 in Section 3 using the JSON encoded described in [RFC7951]. The 2231 registrar MUST sign the request. The entire registrar certificate 2232 chain, up to and including the Domain CA, MUST be included in the 2233 CMS structure. 2235 5.8.1. MASA audit log response 2237 A log data file is returned consisting of all log entries associated 2238 with the the device selected by the IDevID presented in the request. 2239 The audit log may be truncated of old or repeated values as explained 2240 below. The returned data is in JSON format ([RFC7951]), and the 2241 Content-Type SHOULD be "application/json". For example: 2243 { 2244 "version":"1", 2245 "events":[ 2246 { 2247 "date":"", 2248 "domainID":"", 2249 "nonce":"" 2250 "assertion":"" 2251 "truncated":"" 2252 }, 2253 { 2254 "date":"", 2255 "domainID":"", 2256 "nonce":"" 2257 "assertion":"" 2258 } 2259 ], 2260 "truncation": { 2261 "nonced duplicates": "", 2262 "nonceless duplicates": "", 2263 "arbitrary": "" 2264 } 2265 } 2267 Distribution of a large log is less than ideal. This structure can 2268 be optimized as follows: Nonced or Nonceless entries for the same 2269 domainID MAY be truncated from the log leaving only the single most 2270 recent nonced or nonceless entry for that domainID. In the case of 2271 truncation the 'event' truncation value SHOULD contain a count of the 2272 number of events for this domainID that were truncated. The log 2273 SHOULD NOT be further reduced but there could exist operational 2274 situation where maintaining the full log is not possible. In such 2275 situations the log MAY be arbitrarily truncated for length, with the 2276 number of removed entries indicated as 'arbitrary'. 2278 If the truncation count exceeds 1024 then the MASA MAY use this value 2279 without further incrementing it. 2281 A log where duplicate entries for the same domain have been truncated 2282 ("nonced duplicates" and/or "nonceless duplicates) could still be 2283 acceptable for informed decisions. A log that has had "arbitrary" 2284 truncations is less acceptable but manufacturer transparency is 2285 better than hidden truncations. 2287 This document specifies a simple log format as provided by the MASA 2288 service to the registrar. This format could be improved by 2289 distributed consensus technologies that integrate vouchers with 2290 technologies such as block-chain or hash trees or optimized logging 2291 approaches. Doing so is out of the scope of this document but is an 2292 anticipated improvement for future work. As such, the registrar 2293 client SHOULD anticipate new kinds of responses, and SHOULD provide 2294 operator controls to indicate how to process unknown responses. 2296 5.8.2. Registrar audit log verification 2298 Each time the Manufacturer Authorized Signing Authority (MASA) issues 2299 a voucher, it places it into the audit log for that device. The 2300 details are described in Section 5.8. The contents of the audit log 2301 can express a variety of trust levels, and this section explains what 2302 kind of trust a registrar can derive from the entries. 2304 While the audit log provides a list of vouchers that were issued by 2305 the MASA, the vouchers are issued in response to voucher-requests, 2306 and it is the contents of the voucher-requests which determines how 2307 meaningful the audit log entries are. 2309 A registrar SHOULD use the log information to make an informed 2310 decision regarding the continued bootstrapping of the pledge. The 2311 exact policy is out of scope of this document as it depends on the 2312 security requirements within the registrar domain. Equipment that is 2313 purchased pre-owned can be expected to have an extensive history. 2314 The following dicussion is provided to help explain the value of each 2315 log element: 2317 date: The date field provides the registrar an opportunity to divide 2318 the log around known events such as the purchase date. Depending 2319 on context known to the registrar or administrator evens before/ 2320 after certain dates can have different levels of importance. For 2321 example for equipment that is expected to be new, and thus have no 2322 history, it would be a surprise to find prior entries. 2324 domainID: If the log includes an unexpected domainID then the pledge 2325 could have imprinted on an unexpected domain. The registrar can 2326 be expected to use a variety of techniques to define "unexpected" 2327 ranging from white lists of prior domains to anomoly detection 2328 (e.g. "this device was previously bound to a different domain than 2329 any other device deployed"). Log entries can also be compared 2330 against local history logs in search of discrepancies (e.g. "this 2331 device was re-deployed some number of times internally but the 2332 external audit log shows additional re-deployments our internal 2333 logs are unaware of"). 2335 nonce: Nonceless entries mean the logged domainID could 2336 theoretically trigger a reset of the pledge and then take over 2337 management by using the existing nonceless voucher. 2339 assertion: The assertion leaf in the voucher and audit log indicates 2340 why the MASA issued the voucher. A "verified" entry means that 2341 the MASA issued the associated voucher as a result of positive 2342 verification of ownership but this can still be problematic for 2343 registrar's that expected only new (not pre-owned) pledges. A 2344 "logged" assertion informs the registrar that the prior vouchers 2345 were issued with minimal verification. A "proximity" assertion 2346 assures the registrar that the pledge was truly communicating with 2347 the prior domain and thus provides assurance that the prior domain 2348 really has deployed the pledge. 2350 A relatively simple policy is to white list known (internal or 2351 external) domainIDs and to require all vouchers to have a nonce and/ 2352 or require that all nonceless vouchers be from a subset (e.g. only 2353 internal) domainIDs. A simple action is to revoke any locally issued 2354 credentials for the pledge in question or to refuse to forward the 2355 voucher. A registrar MAY be configured to ignore the history of the 2356 device but it is RECOMMENDED that this only be configured if hardware 2357 assisted NEA [RFC5209] is supported. 2359 5.9. EST Integration for PKI bootstrapping 2361 The pledge SHOULD follow the BRSKI operations with EST enrollment 2362 operations including "CA Certificates Request", "CSR Attributes" and 2363 "Client Certificate Request" or "Server-Side Key Generation", etc. 2364 This is a relatively seamless integration since BRSKI REST calls 2365 provide an automated alternative to the manual bootstrapping method 2366 described in [RFC7030]. As noted above, use of HTTP 1.1 persistent 2367 connections simplifies the pledge state machine. 2369 Although EST allows clients to obtain multiple certificates by 2370 sending multiple CSR requests BRSKI mandates use of the CSR 2371 Attributes request and mandates that the registrar validate the CSR 2372 against the expected attributes. This implies that client requests 2373 will "look the same" and therefore result in a single logical 2374 certificate being issued even if the client were to make multiple 2375 requests. Registrars MAY contain more complex logic but doing so is 2376 out-of-scope of this specification. BRSKI does not signal any 2377 enhancement or restriction to this capability. 2379 5.9.1. EST Distribution of CA Certificates 2381 The pledge SHOULD request the full EST Distribution of CA 2382 Certificates message. See RFC7030, section 4.1. 2384 This ensures that the pledge has the complete set of current CA 2385 certificates beyond the pinned-domain-cert (see Section 5.6.1 for a 2386 discussion of the limitations inherent in having a single certificate 2387 instead of a full CA Certificates response.) Although these 2388 limitations are acceptable during initial bootstrapping, they are not 2389 appropriate for ongoing PKIX end entity certificate validation. 2391 5.9.2. EST CSR Attributes 2393 Automated bootstrapping occurs without local administrative 2394 configuration of the pledge. In some deployments it is plausible 2395 that the pledge generates a certificate request containing only 2396 identity information known to the pledge (essentially the X.509 2397 IDevID information) and ultimately receives a certificate containing 2398 domain specific identity information. Conceptually the CA has 2399 complete control over all fields issued in the end entity 2400 certificate. Realistically this is operationally difficult with the 2401 current status of PKI certificate authority deployments, where the 2402 CSR is submitted to the CA via a number of non-standard protocols. 2403 Even with all standardized protocols used, it could operationally be 2404 problematic to expect that service specific certificate fields can be 2405 created by a CA that is likely operated by a group that has no 2406 insight into different network services/protocols used. For example, 2407 the CA could even be outsourced. 2409 To alleviate these operational difficulties, the pledge MUST request 2410 the EST "CSR Attributes" from the EST server and the EST server needs 2411 to be able to reply with the attributes necessary for use of the 2412 certificate in its intended protocols/services. This approach allows 2413 for minimal CA integrations and instead the local infrastructure (EST 2414 server) informs the pledge of the proper fields to include in the 2415 generated CSR. This approach is beneficial to automated boostrapping 2416 in the widest number of environments. 2418 If the hardwareModuleName in the X.509 IDevID is populated then it 2419 SHOULD by default be propagated to the LDevID along with the 2420 hwSerialNum. The EST server SHOULD support local policy concerning 2421 this functionality. 2423 In networks using the BRSKI enrolled certificate to authenticate the 2424 ACP (Autonomic Control Plane), the EST attributes MUST include the 2425 "ACP information" field. See 2426 [I-D.ietf-anima-autonomic-control-plane] for more details. 2428 The registrar MUST also confirm that the resulting CSR is formatted 2429 as indicated before forwarding the request to a CA. If the registrar 2430 is communicating with the CA using a protocol such as full CMC, which 2431 provides mechanisms to override the CSR attributes, then these 2432 mechanisms MAY be used even if the client ignores CSR Attribute 2433 guidance. 2435 5.9.3. EST Client Certificate Request 2437 The pledge MUST request a new client certificate. See RFC7030, 2438 section 4.2. 2440 5.9.4. Enrollment Status Telemetry 2442 For automated bootstrapping of devices, the adminstrative elements 2443 providing bootstrapping also provide indications to the system 2444 administrators concerning device lifecycle status. This might 2445 include information concerning attempted bootstrapping messages seen 2446 by the client, MASA provides logs and status of credential 2447 enrollment. [RFC7030] assumes an end user and therefore does not 2448 include a final success indication back to the server. This is 2449 insufficient for automated use cases. 2451 To indicate successful enrollment the client SHOULD re-negotiate the 2452 EST TLS session using the newly obtained credentials. This occurs by 2453 the client initiating a new TLS ClientHello message on the existing 2454 TLS connection. The client MAY simply close the old TLS session and 2455 start a new one. The server MUST support either model. 2457 In the case of a FAIL, the Reason string indicates why the most 2458 recent enrollment failed. The SubjectKeyIdentifier field MUST be 2459 included if the enrollment attempt was for a keypair that is locally 2460 known to the client. If EST /serverkeygen was used and failed then 2461 the field is omitted from the status telemetry. 2463 In the case of a SUCCESS the Reason string is omitted. The 2464 SubjectKeyIdentifier is included so that the server can record the 2465 successful certificate distribution. 2467 Status media type: application/json 2469 The client HTTP POSTs the following to the server at the new EST well 2470 known URI /enrollstatus. 2472 { 2473 "version":"1", 2474 "Status":TRUE /* TRUE=Success, FALSE=Fail" 2475 "Reason":"Informative human readable message" 2476 "reason-context": "Additional information" 2477 } 2479 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2480 an HTTP 404 error. 2482 Within the server logs the server MUST capture if this message was 2483 received over an TLS session with a matching client certificate. 2484 This allows for clients that wish to minimize their crypto operations 2485 to simply POST this response without renegotiating the TLS session - 2486 at the cost of the server not being able to accurately verify that 2487 enrollment was truly successful. 2489 5.9.5. Multiple certificates 2491 Pledges that require multiple certificates could establish direct EST 2492 connections to the registrar. 2494 5.9.6. EST over CoAP 2496 This document describes extensions to EST for the purposes of 2497 bootstrapping of remote key infrastructures. Bootstrapping is 2498 relevant for CoAP enrollment discussions as well. The defintion of 2499 EST and BRSKI over CoAP is not discussed within this document beyond 2500 ensuring proxy support for CoAP operations. Instead it is 2501 anticipated that a definition of CoAP mappings will occur in 2502 subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP 2503 mappings for BRSKI will be discussed either there or in future work. 2505 6. Reduced security operational modes 2507 A common requirement of bootstrapping is to support less secure 2508 operational modes for support specific use cases. The following 2509 sections detail specific ways that the pledge, registrar and MASA can 2510 be configured to run in a less secure mode for the indicated reasons. 2512 This section is considered non-normative: use suggested methods MUST 2513 be detailed in specific profiles of BRSKI. This is the subject for 2514 future work. 2516 6.1. Trust Model 2518 This section explains the trust relationships detailed in 2519 Section 2.4: 2521 +--------+ +---------+ +------------+ +------------+ 2522 | Pledge | | Join | | Domain | |Manufacturer| 2523 | | | Proxy | | Registrar | | Service | 2524 | | | | | | | (Internet) | 2525 +--------+ +---------+ +------------+ +------------+ 2527 Figure 10 2529 Pledge: The pledge could be compromised and providing an attack 2530 vector for malware. The entity is trusted to only imprint using 2531 secure methods described in this document. Additional endpoint 2532 assessment techniques are RECOMMENDED but are out-of-scope of this 2533 document. 2535 Join Proxy: Provides proxy functionalities but is not involved in 2536 security considerations. 2538 Registrar: When interacting with a MASA a registrar makes all 2539 decisions. For Ownership Audit Vouchers (see [RFC8366]) the 2540 registrar is provided an opportunity to accept MASA decisions. 2542 Vendor Service, MASA: This form of manufacturer service is trusted 2543 to accurately log all claim attempts and to provide authoritative 2544 log information to registrars. The MASA does not know which 2545 devices are associated with which domains. These claims could be 2546 strengthened by using cryptographic log techniques to provide 2547 append only, cryptographic assured, publicly auditable logs. 2548 Current text provides only for a trusted manufacturer. 2550 Vendor Service, Ownership Validation: This form of manufacturer 2551 service is trusted to accurately know which device is owned by 2552 which domain. 2554 6.2. Pledge security reductions 2556 The pledge can choose to accept vouchers using less secure methods. 2557 These methods enable offline and emergency (touch based) deployment 2558 use cases: 2560 1. The pledge MUST accept nonceless vouchers. This allows for a use 2561 case where the registrar can not connect to the MASA at the 2562 deployment time. Logging and validity periods address the 2563 security considerations of supporting these use cases. 2565 2. Many devices already support "trust on first use" for physical 2566 interfaces such as console ports. This document does not change 2567 that reality. Devices supporting this protocol MUST NOT support 2568 "trust on first use" on network interfaces. This is because 2569 "trust on first use" over network interfaces would undermine the 2570 logging based security protections provided by this 2571 specification. 2573 3. The pledge MAY have an operational mode where it skips voucher 2574 validation one time. For example if a physical button is 2575 depressed during the bootstrapping operation. This can be useful 2576 if the manufacturer service is unavailable. This behavior SHOULD 2577 be available via local configuration or physical presence methods 2578 (such as use of a serial/craft console) to ensure new entities 2579 can always be deployed even when autonomic methods fail. This 2580 allows for unsecured imprint. 2582 It is RECOMMENDED that "trust on first use" or any method of skipping 2583 voucher validation (including use of craft serial console) only be 2584 available if hardware assisted Network Endpoint Assessment [RFC5209] 2585 is supported. This recommendation ensures that domain network 2586 monitoring can detect innappropriate use of offline or emergency 2587 deployment procedures when voucher-based bootstrapping is not used. 2589 6.3. Registrar security reductions 2591 A registrar can choose to accept devices using less secure methods. 2592 These methods are acceptable when low security models are needed, as 2593 the security decisions are being made by the local administrator, but 2594 they MUST NOT be the default behavior: 2596 1. A registrar MAY choose to accept all devices, or all devices of a 2597 particular type, at the administrator's discretion. This could 2598 occur when informing all registrars of unique identifiers of new 2599 entities might be operationally difficult. 2601 2. A registrar MAY choose to accept devices that claim a unique 2602 identity without the benefit of authenticating that claimed 2603 identity. This could occur when the pledge does not include an 2604 X.509 IDevID factory installed credential. New Entities without 2605 an X.509 IDevID credential MAY form the Section 5.2 request using 2606 the Section 5.5 format to ensure the pledge's serial number 2607 information is provided to the registrar (this includes the 2608 IDevID AuthorityKeyIdentifier value, which would be statically 2609 configured on the pledge.) The pledge MAY refuse to provide a 2610 TLS client certificate (as one is not available.) The pledge 2611 SHOULD support HTTP-based or certificate-less TLS authentication 2612 as described in EST RFC7030 section 3.3.2. A registrar MUST NOT 2613 accept unauthenticated New Entities unless it has been configured 2614 to do so by an administrator that has verified that only expected 2615 new entities can communicate with a registrar (presumably via a 2616 physically secured perimeter.) 2618 3. A registrar MAY submit a nonceless voucher-requests to the MASA 2619 service (by not including a nonce in the voucher-request.) The 2620 resulting vouchers can then be stored by the registrar until they 2621 are needed during bootstrapping operations. This is for use 2622 cases where the target network is protected by an air gap and 2623 therefore cannot contact the MASA service during pledge 2624 deployment. 2626 4. A registrar MAY ignore unrecognized nonceless log entries. This 2627 could occur when used equipment is purchased with a valid history 2628 being deployed in air gap networks that required permanent 2629 vouchers. 2631 6.4. MASA security reductions 2633 Lower security modes chosen by the MASA service affect all device 2634 deployments unless bound to the specific device identities. In which 2635 case these modes can be provided as additional features for specific 2636 customers. The MASA service can choose to run in less secure modes 2637 by: 2639 1. Not enforcing that a nonce is in the voucher. This results in 2640 distribution of a voucher that never expires and in effect makes 2641 the Domain an always trusted entity to the pledge during any 2642 subsequent bootstrapping attempts. That this occurred is 2643 captured in the log information so that the registrar can make 2644 appropriate security decisions when a pledge joins the Domain. 2645 This is useful to support use cases where registrars might not be 2646 online during actual device deployment. Because this results in 2647 a long lived voucher and does not require the proof that the 2648 device is online, this is only accepted when the registrar is 2649 authenticated by the MASA and authorized to provide this 2650 functionality. The MASA is RECOMMENDED to use this functionality 2651 only in concert with an enhanced level of ownership tracking 2652 (out-of-scope.) If the pledge device is known to have a real- 2653 time-clock that is set from the factory, use of a voucher 2654 validity period is RECOMMENDED. 2656 2. Not verifying ownership before responding with a voucher. This 2657 is expected to be a common operational model because doing so 2658 relieves the manufacturer providing MASA services from having to 2659 track ownership during shipping and supply chain and allows for a 2660 very low overhead MASA service. A registrar uses the audit log 2661 information as a defense in depth strategy to ensure that this 2662 does not occur unexpectedly (for example when purchasing new 2663 equipment the registrar would throw an error if any audit log 2664 information is reported.) The MASA SHOULD verify the 'prior- 2665 signed-voucher-request' information for pledges that support that 2666 functionality. This provides a proof-of-proximity check that 2667 reduces the need for ownership verification. 2669 7. IANA Considerations 2671 This document requires the following IANA actions: 2673 7.1. Well-known EST registration 2675 This document extends the definitions of "est" (so far defined via 2676 RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ 2677 well-known-uris.xhtml" registry as follows: 2679 o add /.well-known/est/requestvoucher (see Section 5.5 ) 2681 o add /.well-known/est/requestauditlog (see Section 5.7) 2683 7.2. PKIX Registry 2685 IANA is requested to register the following: 2687 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 2688 the pkix(7) id-mod(0) Registry. 2690 This document has received an early allocation from the id-pe 2691 registry (SMI Security for PKIX Certificate Extension) for id-pe- 2692 masa-url with the value 32, resulting in an OID of 2693 1.3.6.1.5.5.7.1.32. 2695 7.3. Pledge BRSKI Status Telemetry 2697 IANA is requested to create a new Registry entitled: "BRSKI 2698 Parameters", and within that Registry to create a table called: 2699 "Pledge BRSKI Status Telemetry Attributes". New items can be added 2700 using the Specification Required. The following items are to be in 2701 the initial registration, with this document (Section 5.7) as the 2702 reference: 2704 o version 2706 o Status 2708 o Reason 2709 o reason-context 2711 7.4. DNS Service Names 2713 IANA is requested to register the following Service Names: 2715 Service Name: _brski-proxy 2716 Transport Protocol(s): tcp 2717 Assignee: IESG . 2718 Contact: IESG 2719 Description: The Bootstrapping Remote Secure Key 2720 Infrastructures Proxy 2721 Reference: [This document] 2723 Service Name: _brski-registrar 2724 Transport Protocol(s): tcp 2725 Assignee: IESG . 2726 Contact: IESG 2727 Description: The Bootstrapping Remote Secure Key 2728 Infrastructures Registrar 2729 Reference: [This document] 2731 7.5. MUD File Extension for the MASA 2733 The IANA is requested to list the name "masa" in the MUD extensions 2734 registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in 2735 Appendix C. 2737 8. Applicability to the Autonomic Control Plane 2739 This document provides a solution to the requirements for secure 2740 bootstrap set out in Using an Autonomic Control Plane for Stable 2741 Connectivity of Network Operations, Administration, and Maintenance 2742 [RFC8368], A Reference Model for Autonomic Networking 2743 [I-D.ietf-anima-reference-model] and specifically the An Autonomic 2744 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section 2745 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 2746 Network). 2748 The protocol described in this document has appeal in a number of 2749 other non-ANIMA use cases. Such uses of the protocol will be 2750 deploying into other environments with different tradeoffs of 2751 privacy, security, reliability and autonomy from manufacturers. As 2752 such those use cases will need to provide their own applicability 2753 statements, and will need to address unique privacy and security 2754 considerations for the environments in which they are used. 2756 The autonomic control plane that this document provides bootstrap for 2757 is typically a medium to large Internet Service Provider 2758 organization, or an equivalent Enterprise that has signficant layer-3 2759 router connectivity. (A network consistenting of primarily layer-2 2760 is not excluded, but the adjacencies that the ACP will create and 2761 maintain will not reflect the topology until all devices participate 2762 in the ACP). 2764 As specified in the ANIMA charter, this work "..focuses on 2765 professionally-managed networks." Such a network has an operator and 2766 can do things like like install, configure and operate the Registrar 2767 function. The operator makes purchasing decisions and is aware of 2768 what manufacturers it expects to see on it's network. 2770 Such an operator also is capable of performing the traditional (craft 2771 serial-console) based bootstrap of devices. The zero-touch mechanism 2772 presented in this and the ACP document represents a signficiant 2773 efficiency: in particular it reduces the need to put senior experts 2774 on airplanes to configure devices in person. There is a recognition 2775 as the technology evolves that not every situation may work out, and 2776 occasionally a human still still have to visit. 2778 The BRSKI protocol is going into environments where there have 2779 already been quite a number of vendor proprietary management systems. 2780 Those are not expected to go away quickly, but rather to leverage the 2781 secure credentials that are provisioned by BRSKI. The connectivity 2782 requirements of said management systems are provided by the ACP. 2784 9. Privacy Considerations 2786 9.1. MASA audit log 2788 The MASA audit log includes a hash of the domainID for each Registrar 2789 a voucher has been issued to. This information is closely related to 2790 the actual domain identity, especially when paired with the anti-DDoS 2791 authentication information the MASA might collect. This could 2792 provide sufficient information for the MASA service to build a 2793 detailed understanding the devices that have been provisioned within 2794 a domain. 2796 There are a number of design choices that mitigate this risk. The 2797 domain can maintain some privacy since it has not necessarily been 2798 authenticated and is not authoritatively bound to the supply chain. 2800 Additionally the domainID captures only the unauthenticated subject 2801 key identifier of the domain. A privacy sensitive domain could 2802 theoretically generate a new domainID for each device being deployed. 2803 Similarly a privacy sensitive domain would likely purchase devices 2804 that support proximity assertions from a manufacturer that does not 2805 require sales channel integrations. This would result in a 2806 significant level of privacy while maintaining the security 2807 characteristics provided by Registrar based audit log inspection. 2809 9.2. What BRSKI-MASA reveals to the manufacturer 2811 The so-called "call-home" mechanism that occurs as part of the BRSKI- 2812 MASA connection standardizes what has been deemed by some as a 2813 sinister mechanism for corporate oversight of individuals. 2814 ([livingwithIoT] and [IoTstrangeThings] for a small sample). 2816 As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted 2817 at individual usage of IoT devices, but rather at the Enterprise and 2818 ISP creation of networks in a zero-touch fashion, the "call-home" 2819 represents a different kind of concern. 2821 It needs to be re-iterated that the BRSKI-MASA mechanism only occurs 2822 once during the comissioning of the device. It is well defined, and 2823 although encrypted with TLS, it could in theory be made auditable as 2824 the contents are well defined. This connection does not occur when 2825 the device powers on or is restarted for normal routines. It is 2826 conceivable that a device could be forced to go through a full 2827 factory reset during an exceptional firmware update situation, after 2828 which enrollment would have be repeated. 2830 The BRSKI call-home mechanism is mediated via the owner's Registrar, 2831 and the information that is transmitted is directly auditable by the 2832 device owner. This is in stark constrast to many "call-home" 2833 protocols where the device autonomously calls home and uses an 2834 undocumented protocol. 2836 While the contents of the signed part of the pledge voucher request 2837 can not be changed, they are not encrypted at the registrar. The 2838 ability to audit the messages by the owner of the network prevents 2839 exfiltration of data by a nefarious pledge. The contents of an 2840 unsigned voucher request are, however, completely changeable by the 2841 Registrar. Both are, to re-iterate, encrypted by TLS while in 2842 transit. 2844 The BRSKI-MASA exchange reveals the following information to the 2845 manufacturer: 2847 o the identity of the device being enrolled (down to the serial- 2848 number!). 2850 o an identity of the domain owner in the form of the domain trust 2851 anchor. However, this is not a global PKI anchored name within 2852 the WebPKI, so this identity could be pseudonymous. If there is 2853 sales channel integration, then the MASA will have authenticated 2854 the domain owner, either via pinned certificate, or perhaps 2855 another HTTP authentication method, as per Section 5.5.3. 2857 o the time the device is activated, 2859 o the IP address of the domain Owner's Registrar. For ISPs and 2860 Enterprises, the IP address provides very clear geolocation of the 2861 owner. No amount of IP address privacy extensions ([RFC4941]) can 2862 do anything about this, as a simple whois lookup likely identifies 2863 the ISP or Enterprise from the upper bits anyway. A passive 2864 attacker who observes the connection definitely may conclude that 2865 the given enterprise/ISP is a customer of the particular equipment 2866 vendor. The precise model that is being enrolled will remain 2867 private. 2869 The above situation is to be distinguished from a residential/ 2870 individual person who registers a device from a manufacturer: that an 2871 enterprise/ISP purchases routing products is hardly worth mentioning. 2872 Deviations would, however, be notable. 2874 The situation is not improved by the enterprise/ISP using 2875 anonymization services such as ToR [Dingledine2004], as a TLS 1.2 2876 connection will reveal the ClientCertificate used, clearly 2877 identifying the enterprise/ISP involved. TLS 1.3 is better in this 2878 regard, but an active attacker can still discover the parties 2879 involved by performing a Man-In-The-Middle-Attack on the first 2880 attempt (breaking/killing it with a TCP RST), and then letting 2881 subsequent connection pass through. 2883 A manufacturer could attempt to mix the BRSKI-MASA traffic in with 2884 general traffic their site by hosting the MASA behind the same (set) 2885 of load balancers that the companies normal marketing site is hosted 2886 behind. This makes lots of sense from a straight capacity planning 2887 point of view as the same set of services (and the same set of 2888 Distributed Denial of Service mitigations) may be used. 2889 Unfortunately, as the BRSKI-MASA connections include TLS 2890 ClientCertificate exchanges, this may easily be observed in TLS 1.2, 2891 and a traffic analysis may reveal it even in TLS 1.3. This does not 2892 make such a plan irrelevant. There may be other organizational 2893 reasons to keep the marketing site (which is often subject to 2894 frequent redesigs, outsourcing, etc.) seperate from the MASA, which 2895 may need to operate reliably for decades. 2897 9.3. Manufacturers and Used or Stolen Equipment 2899 As explained above, the manufacturer receives information each time 2900 that a device which is in factory-default mode does a zero-touch 2901 bootstrap, and attempts to enroll into a domain owner's registrar. 2903 The manufacturer is therefore in a position to decline to issue a 2904 voucher if it detects that the new owner is not the same as the 2905 previous owner. 2907 1. This can be seen as a feature if the equipment is believed to 2908 have been stolen. If the legitimate owner notifies the 2909 manufacturer of the theft, then when the new owner brings the 2910 device up, if they use the zero-touch mechanism, the new 2911 (illegitimate) owner reveals their location and identity. 2913 2. In the case of Used equipment, the initial owner could inform the 2914 manufacturer of the sale, or the manufacturer may just permit 2915 resales unless told otherwise. In which case, the transfer of 2916 ownership simply occurs. 2918 3. A manufacturer could however decide not to issue a new voucher in 2919 response to a transfer of ownership. This is essentially the 2920 same as the stolen case, with the manufacturer having decided 2921 that the sale was not legitimate. 2923 4. There is a fourth case, if the manufacturer is providing 2924 protection against stolen devices. The manufacturer then has a 2925 responsability to protect the legitimate owner against fraudulent 2926 claims that the the equipment was stolen. Such a claim would 2927 cause the manufacturer to refuse to issue a new voucher. Should 2928 the device go through a deep factory reset (for instance, 2929 replacement of a damaged main board component, the device would 2930 not bootstrap. 2932 5. Finally, there is a fifth case: the manufacturer has decided to 2933 end-of-line the device, or the owner has not paid a yearly 2934 support amount, and the manufacturer refuses to issue new 2935 vouchers at that point. This last case is not new to the 2936 industry: many license systems are already deployed that have 2937 significantly worse effect. 2939 This section has outlined five situations in which a manufacturer 2940 could use the voucher system to enforce what are clearly license 2941 terms. A manufacturer that attempted to enforce license terms via 2942 vouchers would find it rather ineffective as the terms would only be 2943 enforced when the device is enrolled, and this is not (to repeat), a 2944 daily or even monthly occurrance. 2946 9.4. Manufacturers and Grey market equipment 2948 Manufacturers of devices often sell different products into different 2949 regional markets. Which product is available in which market can be 2950 driven by price differentials, support issues (some markets may 2951 require manuals and tech-support to be done in the local language), 2952 government export regulation (such as whether strong crypto is 2953 permitted to be exported, or permitted to be used in a particular 2954 market). When an domain owner obtains a device from a different 2955 market (they can be new) and transfers it to a different location, 2956 this is called a Grey Market. 2958 A manufacturer could decide not to issue a voucher to an enterprise/ 2959 ISP based upon their location. There are a number of ways which this 2960 could be determined: from the geolocation of the registrar, from 2961 sales channel knowledge about the customer, and what products are 2962 (un-)available in that market. If the device has a GPS the 2963 coordinates of the device could even be placed into an extension of 2964 the voucher. 2966 The above actions are not illegal, and not new. Many manufacturers 2967 have shipped crypto-weak (exportable) versions of firmware as the 2968 default on equipment for decades. The first task of an enterprise/ 2969 ISP has always been to login to a manufacturer system, show one's 2970 "entitlement" (country informatin, proof that support payments have 2971 been made), and receive either a new updated firmware, or a license 2972 key that will activate the correct firmware. 2974 BRSKI permits the above process to automated (in an autonomic 2975 fashion), and therefore perhaps encourages this kind of 2976 differentiation by reducing the cost of doing it. 2978 An issue that manufacturers will need to deal with in the above 2979 automated process is when a device is shipped to one country with one 2980 set of rules (or laws or entitlements), but the domain registry is in 2981 another one. Which rules apply is something will have to be worked 2982 out: the manufacturer could come to believe they are dealing with 2983 Grey market equipment, when it is simply dealing with a global 2984 enterprise. 2986 9.5. Some mitigations for meddling by manufacturers 2988 The most obvious mitigation is not to buy the product. Pick 2989 manufacturers that are up-front about their policies, who do not 2990 change them gratutiously. 2992 A manufacturer could provide a mechanism to manage the trust anchors 2993 and built-in certificates (IDevID) as an extension. This is a 2994 substantial amount of work, and may be an area for future 2995 standardization work. 2997 Replacement of the voucher validation anchors (usually pointing to 2998 the original manufacturer's MASA) with those of the new owner permits 2999 the new owner to issue vouchers to subsequent owners. This would be 3000 done by having the selling (old) owner to run a MASA. 3002 In order to automatically find the new MASA, the mechanism describe 3003 in this document is to look for the MASA URL extension in the IDevID. 3004 A new owner could override this in their Registrar, or the 3005 manufacturer could provide a mechanism to update or replace the 3006 IDevID prior to sale. 3008 Once the voucher trust anchor and the IDevID is replaced, then the 3009 device will no longer trust the manufacturer in any way. When a new 3010 owner performs a bootstrap, the device will point to a MASA that has 3011 been chosen, and will validate vouchers from this new entity. 3013 The BRSKI protocol depends upon a trust anchor on the device and an 3014 identity on the device. Management of these these entities 3015 facilitiates a few new operatonal modes without making any changes to 3016 the BRSKI protocol. Those modes include: offline modes where the 3017 domain owner operates an internal MASA for all devices, resell modes 3018 where the first domain owner becomes the MASA for the next (resold- 3019 to) domain owner, and services where an aggregator acquires a large 3020 variety of devices, and then acts as a pseudonymized MASA for a 3021 variety of devices from a variety of manufacturers. 3023 Some manufacturers may wish to consider replacement of the IDevID as 3024 an indication that the device's warantee is terminated. For others, 3025 the privacy requiments of some deployments might consider this a 3026 standard operating practice. 3028 As discussed at the end of Section 5.8.1, new work could be done to 3029 use a distributed consensus technology for the audit log. This would 3030 permit the audit log to continue to be useful, even when there is a 3031 chain of MASA due to changes of ownership. 3033 10. Security Considerations 3035 This document details a protocol for bootstrapping that balances 3036 operational concerns against security concerns. As detailed in the 3037 introduction, and touched on again in Section 6, the protocol allows 3038 for reduced security modes. These attempt to deliver additional 3039 control to the local administrator and owner in cases where less 3040 security provides operational benefits. This section goes into more 3041 detail about a variety of specific considerations. 3043 To facilitate logging and administrative oversight, in addition to 3044 triggering Registration verification of MASA logs, the pledge reports 3045 on voucher parsing status to the registrar. In the case of a 3046 failure, this information is informative to a potentially malicious 3047 registrar. This is mandated anyway because of the operational 3048 benefits of an informed administrator in cases where the failure is 3049 indicative of a problem. The registrar is RECOMMENDED to verify MASA 3050 logs if voucher status telemetry is not received. 3052 To facilitate truely limited clients EST RFC7030 section 3.3.2 3053 requirements that the client MUST support a client authentication 3054 model have been reduced in Section 6 to a statement that the 3055 registrar "MAY" choose to accept devices that fail cryptographic 3056 authentication. This reflects current (poor) practices in shipping 3057 devices without a cryptographic identity that are NOT RECOMMENDED. 3059 During the provisional period of the connection the pledge MUST treat 3060 all HTTP header and content data as untrusted data. HTTP libraries 3061 are regularly exposed to non-secured HTTP traffic: mature libraries 3062 should not have any problems. 3064 Pledges might chose to engage in protocol operations with multiple 3065 discovered registrars in parallel. As noted above they will only do 3066 so with distinct nonce values, but the end result could be multiple 3067 vouchers issued from the MASA if all registrars attempt to claim the 3068 device. This is not a failure and the pledge choses whichever 3069 voucher to accept based on internal logic. The registrars verifying 3070 log information will see multiple entries and take this into account 3071 for their analytics purposes. 3073 10.1. DoS against MASA 3075 There are uses cases where the MASA could be unavailable or 3076 uncooperative to the Registrar. They include active DoS attacks, 3077 planned and unplanned network partitions, changes to MASA policy, or 3078 other instances where MASA policy rejects a claim. These introduce 3079 an operational risk to the Registrar owner in that MASA behavior 3080 might limit the ability to bootstrap a pledge device. For example 3081 this might be an issue during disaster recovery. This risk can be 3082 mitigated by Registrars that request and maintain long term copies of 3083 "nonceless" vouchers. In that way they are guaranteed to be able to 3084 bootstrap their devices. 3086 The issuance of nonceless vouchers themselves creates a security 3087 concern. If the Registrar of a previous domain can intercept 3088 protocol communications then it can use a previously issued nonceless 3089 voucher to establish management control of a pledge device even after 3090 having sold it. This risk is mitigated by recording the issuance of 3091 such vouchers in the MASA audit log that is verified by the 3092 subsequent Registrar and by Pledges only bootstrapping when in a 3093 factory default state. This reflects a balance between enabling MASA 3094 independence during future bootstrapping and the security of 3095 bootstrapping itself. Registrar control over requesting and auditing 3096 nonceless vouchers allows device owners to choose an appropriate 3097 balance. 3099 The MASA is exposed to DoS attacks wherein attackers claim an 3100 unbounded number of devices. Ensuring a registrar is representative 3101 of a valid manufacturer customer, even without validating ownership 3102 of specific pledge devices, helps to mitigate this. Pledge 3103 signatures on the pledge voucher-request, as forwarded by the 3104 registrar in the prior-signed-voucher-request field of the registrar 3105 voucher-request, significantly reduce this risk by ensuring the MASA 3106 can confirm proximity between the pledge and the registrar making the 3107 request. This mechanism is optional to allow for constrained 3108 devices. Supply chain integration ("know your customer") is an 3109 additional step that MASA providers and device vendors can explore. 3111 10.2. Freshness in Voucher-Requests 3113 A concern has been raised that the pledge voucher-request should 3114 contain some content (a nonce) provided by the registrar and/or MASA 3115 in order for those actors to verify that the pledge voucher-request 3116 is fresh. 3118 There are a number of operational problems with getting a nonce from 3119 the MASA to the pledge. It is somewhat easier to collect a random 3120 value from the registrar, but as the registrar is not yet vouched 3121 for, such a registrar nonce has little value. There are privacy and 3122 logistical challenges to addressing these operational issues, so if 3123 such a thing were to be considered, it would have to provide some 3124 clear value. This section examines the impacts of not having a fresh 3125 pledge voucher-request. 3127 Because the registrar authenticates the pledge, a full Man-in-the- 3128 Middle attack is not possible, despite the provisional TLS 3129 authentication by the pledge (see Section 5.) Instead we examine the 3130 case of a fake registrar (Rm) that communicates with the pledge in 3131 parallel or in close time proximity with the intended registrar. 3132 (This scenario is intentionally supported as described in 3133 Section 4.1.) 3135 The fake registrar (Rm) can obtain a voucher signed by the MASA 3136 either directly or through arbitrary intermediaries. Assuming that 3137 the MASA accepts the registrar voucher-request (either because Rm is 3138 collaborating with a legitimate registrar according to supply chain 3139 information, or because the MASA is in audit-log only mode), then a 3140 voucher linking the pledge to the registrar Rm is issued. 3142 Such a voucher, when passed back to the pledge, would link the pledge 3143 to registrar Rm, and would permit the pledge to end the provisional 3144 state. It now trusts Rm and, if it has any security vulnerabilities 3145 leveragable by an Rm with full administrative control, can be assumed 3146 to be a threat against the intended registrar. 3148 This flow is mitigated by the intended registrar verifying the audit 3149 logs available from the MASA as described in Section 5.8. Rm might 3150 chose to collect a voucher-request but wait until after the intended 3151 registrar completes the authorization process before submitting it. 3152 This pledge voucher-request would be 'stale' in that it has a nonce 3153 that no longer matches the internal state of the pledge. In order to 3154 successfully use any resulting voucher the Rm would need to remove 3155 the stale nonce or anticipate the pledge's future nonce state. 3156 Reducing the possibility of this is why the pledge is mandated to 3157 generate a strong random or pseudo-random number nonce. 3159 Additionally, in order to successfully use the resulting voucher the 3160 Rm would have to attack the pledge and return it to a bootstrapping 3161 enabled state. This would require wiping the pledge of current 3162 configuration and triggering a re-bootstrapping of the pledge. This 3163 is no more likely than simply taking control of the pledge directly 3164 but if this is a consideration the target network is RECOMMENDED to 3165 take the following steps: 3167 o Ongoing network monitoring for unexpected bootstrapping attempts 3168 by pledges. 3170 o Retreival and examination of MASA log information upon the 3171 occurance of any such unexpected events. Rm will be listed in the 3172 logs along with nonce information for analysis. 3174 10.3. Trusting manufacturers 3176 The BRSKI extensions to EST permit a new pledge to be completely 3177 configured with domain specific trust anchors. The link from built- 3178 in manufacturer-provided trust anchors to domain-specific trust 3179 anchors is mediated by the signed voucher artifact. 3181 If the manufacturer's IDevID signing key is not properly validated, 3182 then there is a risk that the network will accept a pledge that 3183 should not be a member of the network. As the address of the 3184 manufacturer's MASA is provided in the IDevID using the extension 3185 from Section 2.3, the malicious pledge will have no problem 3186 collaborating with it's MASA to produce a completely valid voucher. 3188 BRSKI does not, however, fundamentally change the trust model from 3189 domain owner to manufacturer. Assuming that the pledge used its 3190 IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs 3191 to trust the manufacturer. 3193 Establishing this trust between domain and manufacturer is outside 3194 the scope of BRSKI. There are a number of mechanisms that can 3195 adopted including: 3197 o Manually configuring each manufacturer's trust anchor. 3199 o A Trust-On-First-Use (TOFU) mechanism. A human would be queried 3200 upon seeing a manufacturer's trust anchor for the first time, and 3201 then the trust anchor would be installed to the trusted store. 3202 There are risks with this; even if the key to name is validated 3203 using something like the WebPKI, there remains the possibility 3204 that the name is a look alike: e.g, c1sco.com, .. 3206 o scanning the trust anchor from a QR code that came with the 3207 packaging (this is really a manual TOFU mechanism) 3209 o some sales integration process where trust anchors are provided as 3210 part of the sales process, probably included in a digital packing 3211 "slip", or a sales invoice. 3213 o consortium membership, where all manufacturers of a particular 3214 device category (e.g, a light bulb, or a cable-modem) are signed 3215 by an certificate authority specifically for this. This is done 3216 by CableLabs today. It is used for authentication and 3217 authorization as part of TR-79: [docsisroot] and [TR069]. 3219 The existing WebPKI provides a reasonable anchor between manufacturer 3220 name and public key. It authenticates the key. It does not provide 3221 a reasonable authorization for the manufacturer, so it is not 3222 directly useable on it's own. 3224 10.4. Manufacturer Maintainance of trust anchors 3226 BRSKI depends upon the manufacturer building in trust anchors to the 3227 pledge device. The voucher artifact which is signed by the MASA will 3228 be validated by the pledge using that anchor. This implies that the 3229 manufacturer needs to maintain access to a signing key that the 3230 pledge can validate. 3232 The manufacturer will need to maintain the ability to make signatures 3233 that can be validated for the lifetime that the device could be 3234 onboarded. Whether this onboarding lifetime is less than the device 3235 lifetime depends upon how the device is used. An inventory of 3236 devices kept in a warehouse as spares might not be onboarded for many 3237 decades. 3239 There are good cryptographic hygiene reasons why a manufacturer would 3240 not want to maintain access to a private key for many decades. A 3241 manufacturer in that situation can leverage a long-term certificate 3242 authority anchor, built-in to the pledge, and then a certificate 3243 chain may be incorporated using the normal CMS certificate set. This 3244 may increase the size of the voucher artifacts, but that is not a 3245 significant issues in non-constrained environements. 3247 There are a few other operational variations that manufacturers could 3248 consider. For instance, there is no reason that every device need 3249 have the same set of trust anchors pre-installed. Devices built in 3250 different factories, or on different days, or any other consideration 3251 could have different trust anchors built in, and the record of which 3252 batch the device is in would be recorded in the asset database. The 3253 manufacturer would then know which anchor to sign an artifact 3254 against. 3256 Aside from the concern about long-term access to private keys, a 3257 major limiting factor for the shelf-life of many devices will be the 3258 age of the cryptographic algorithms included. A device produced in 3259 2019 will have hardware and software capable of validating algorithms 3260 common in 2019, and will have no defense against attacks (both 3261 quantum and von-neuman brute force attacks) which have not yet been 3262 invented. This concern is orthogonal to the concern about access to 3263 private keys, but this concern likely dominates and limits the 3264 lifespan of a device in a warehouse. If any update to firmware to 3265 support new cryptographic mechanism were possible (while the device 3266 was in a warehouse), updates to trust anchors would also be done at 3267 the same time. 3269 11. Acknowledgements 3271 We would like to thank the various reviewers for their input, in 3272 particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu 3273 Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, 3274 Peter van der Stok, and Thomas Werner 3276 Significant reviews were done by Jari Arko, Christian Huitema and 3277 Russ Housley. 3279 12. References 3280 12.1. Normative References 3282 [I-D.ietf-anima-autonomic-control-plane] 3283 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 3284 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 3285 plane-18 (work in progress), August 2018. 3287 [I-D.ietf-anima-grasp] 3288 Bormann, C., Carpenter, B., and B. Liu, "A Generic 3289 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 3290 grasp-15 (work in progress), July 2017. 3292 [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, 3293 . 3296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3297 Requirement Levels", BCP 14, RFC 2119, 3298 DOI 10.17487/RFC2119, March 1997, 3299 . 3301 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3302 Levkowetz, Ed., "Extensible Authentication Protocol 3303 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 3304 . 3306 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 3307 Configuration of IPv4 Link-Local Addresses", RFC 3927, 3308 DOI 10.17487/RFC3927, May 2005, 3309 . 3311 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3312 "Randomness Requirements for Security", BCP 106, RFC 4086, 3313 DOI 10.17487/RFC4086, June 2005, 3314 . 3316 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 3317 (LDAP): Schema for User Applications", RFC 4519, 3318 DOI 10.17487/RFC4519, June 2006, 3319 . 3321 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3322 Address Autoconfiguration", RFC 4862, 3323 DOI 10.17487/RFC4862, September 2007, 3324 . 3326 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3327 Extensions for Stateless Address Autoconfiguration in 3328 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3329 . 3331 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3332 (TLS) Protocol Version 1.2", RFC 5246, 3333 DOI 10.17487/RFC5246, August 2008, 3334 . 3336 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 3337 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 3338 . 3340 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3341 Housley, R., and W. Polk, "Internet X.509 Public Key 3342 Infrastructure Certificate and Certificate Revocation List 3343 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3344 . 3346 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 3347 Security: An Unauthenticated Mode of IPsec", RFC 5386, 3348 DOI 10.17487/RFC5386, November 2008, 3349 . 3351 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3352 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3353 . 3355 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 3356 RFC 5660, DOI 10.17487/RFC5660, October 2009, 3357 . 3359 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3360 Verification of Domain-Based Application Service Identity 3361 within Internet Public Key Infrastructure Using X.509 3362 (PKIX) Certificates in the Context of Transport Layer 3363 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3364 2011, . 3366 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 3367 DOI 10.17487/RFC6762, February 2013, 3368 . 3370 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 3371 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 3372 . 3374 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3375 "Enrollment over Secure Transport", RFC 7030, 3376 DOI 10.17487/RFC7030, October 2013, 3377 . 3379 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3380 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 3381 2014, . 3383 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3384 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3385 . 3387 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 3388 RFC 7951, DOI 10.17487/RFC7951, August 2016, 3389 . 3391 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3392 "A Voucher Artifact for Bootstrapping Protocols", 3393 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3394 . 3396 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 3397 Control Plane for Stable Connectivity of Network 3398 Operations, Administration, and Maintenance (OAM)", 3399 RFC 8368, DOI 10.17487/RFC8368, May 2018, 3400 . 3402 12.2. Informative References 3404 [Dingledine2004] 3405 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 3406 second-generation onion router", 2004, 3407 . 3409 [docsisroot] 3410 "CableLabs Digital Certificate Issuance Service", February 3411 2018, . 3414 [I-D.ietf-ace-coap-est] 3415 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 3416 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 3417 est-09 (work in progress), February 2019. 3419 [I-D.ietf-anima-constrained-voucher] 3420 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 3421 Voucher Artifacts for Bootstrapping Protocols", draft- 3422 ietf-anima-constrained-voucher-02 (work in progress), 3423 September 2018. 3425 [I-D.ietf-anima-reference-model] 3426 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 3427 and J. Nobre, "A Reference Model for Autonomic 3428 Networking", draft-ietf-anima-reference-model-10 (work in 3429 progress), November 2018. 3431 [I-D.ietf-anima-stable-connectivity] 3432 Eckert, T. and M. Behringer, "Using Autonomic Control 3433 Plane for Stable Connectivity of Network OAM", draft-ietf- 3434 anima-stable-connectivity-10 (work in progress), February 3435 2018. 3437 [I-D.ietf-cbor-cddl] 3438 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 3439 definition language (CDDL): a notational convention to 3440 express CBOR and JSON data structures", draft-ietf-cbor- 3441 cddl-07 (work in progress), February 2019. 3443 [I-D.ietf-netconf-zerotouch] 3444 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 3445 Touch Provisioning (SZTP)", draft-ietf-netconf- 3446 zerotouch-29 (work in progress), January 2019. 3448 [I-D.ietf-opsawg-mud] 3449 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 3450 Description Specification", draft-ietf-opsawg-mud-25 (work 3451 in progress), June 2018. 3453 [I-D.richardson-anima-state-for-joinrouter] 3454 Richardson, M., "Considerations for stateful vs stateless 3455 join router in ANIMA bootstrap", draft-richardson-anima- 3456 state-for-joinrouter-02 (work in progress), January 2018. 3458 [imprinting] 3459 "Wikipedia article: Imprinting", July 2015, 3460 . 3462 [IoTstrangeThings] 3463 "IoT of toys stranger than fiction: Cybersecurity and data 3464 privacy update (accessed 2018-12-02)", March 2017, 3465 . 3468 [livingwithIoT] 3469 "What is it actually like to live in a house filled with 3470 IoT devices? (accessed 2018-12-02)", February 2018, 3471 . 3474 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3475 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 3476 December 1998, . 3478 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3479 Translator (NAT) Terminology and Considerations", 3480 RFC 2663, DOI 10.17487/RFC2663, August 1999, 3481 . 3483 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3484 Uniform Resource Identifiers (URIs)", RFC 5785, 3485 DOI 10.17487/RFC5785, April 2010, 3486 . 3488 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3489 Galperin, S., and C. Adams, "X.509 Internet Public Key 3490 Infrastructure Online Certificate Status Protocol - OCSP", 3491 RFC 6960, DOI 10.17487/RFC6960, June 2013, 3492 . 3494 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 3495 Multiple Certificate Status Request Extension", RFC 6961, 3496 DOI 10.17487/RFC6961, June 2013, 3497 . 3499 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 3500 Interface Identifiers with IPv6 Stateless Address 3501 Autoconfiguration (SLAAC)", RFC 7217, 3502 DOI 10.17487/RFC7217, April 2014, 3503 . 3505 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 3506 Constrained-Node Networks", RFC 7228, 3507 DOI 10.17487/RFC7228, May 2014, 3508 . 3510 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3511 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 3512 DOI 10.17487/RFC7231, June 2014, 3513 . 3515 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 3516 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 3517 2014, . 3519 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 3520 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 3521 December 2014, . 3523 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 3524 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 3525 Networking: Definitions and Design Goals", RFC 7575, 3526 DOI 10.17487/RFC7575, June 2015, 3527 . 3529 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3530 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3531 . 3533 [slowloris] 3534 "Slowloris (computer security)", February 2019, 3535 . 3538 [Stajano99theresurrecting] 3539 Stajano, F. and R. Anderson, "The resurrecting duckling: 3540 security issues for ad-hoc wireless networks", 1999, 3541 . 3544 [TR069] "TR-69: CPE WAN Management Protocol", February 2018, 3545 . 3548 Appendix A. IPv4 and non-ANI operations 3550 The secification of BRSKI in Section 4 intentionally only covers the 3551 mechanisms for an IPv6 pledge using Link-Local addresses. This 3552 section describes non-normative extensions that can be used in other 3553 environments. 3555 A.1. IPv4 Link Local addresses 3557 Instead of an IPv6 link-local address, an IPv4 address may be 3558 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 3559 Addresses. 3561 In the case that an IPv4 Link-Local address is formed, then the 3562 bootstrap process would continue as in the IPv6 case by looking for a 3563 (circuit) proxy. 3565 A.2. Use of DHCPv4 3567 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 3568 provided parameters for the Domain Name System can be used to perform 3569 DNS operations if all local discovery attempts fail. 3571 Appendix B. mDNS / DNSSD proxy discovery options 3573 Pledge discovery of the proxy (Section 4.1) MAY be performed with 3574 DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to 3575 discover the proxy at "_brski-proxy._tcp.local.". 3577 Proxy discovery of the registrar (Section 4.3) MAY be performed with 3578 DNS-based Service Discovery over Multicast DNS to discover registrars 3579 by searching for the service "_brski-registrar._tcp.local.". 3581 To prevent unaccceptable levels of network traffic, when using mDNS, 3582 the congestion avoidance mechanisms specified in [RFC6762] section 7 3583 MUST be followed. The pledge SHOULD listen for an unsolicited 3584 broadcast response as described in [RFC6762]. This allows devices to 3585 avoid announcing their presence via mDNS broadcasts and instead 3586 silently join a network by watching for periodic unsolicited 3587 broadcast responses. 3589 Discovery of registrar MAY also be performed with DNS-based service 3590 discovery by searching for the service "_brski- 3591 registrar._tcp.example.com". In this case the domain "example.com" 3592 is discovered as described in [RFC6763] section 11 (Appendix A.2 3593 suggests the use of DHCP parameters). 3595 If no local proxy or registrar service is located using the GRASP 3596 mechanisms or the above mentioned DNS-based Service Discovery methods 3597 the pledge MAY contact a well known manufacturer provided 3598 bootstrapping server by performing a DNS lookup using a well known 3599 URI such as "brski-registrar.manufacturer.example.com". The details 3600 of the URI are manufacturer specific. Manufacturers that leverage 3601 this method on the pledge are responsible for providing the registrar 3602 service. Also see Section 2.7. 3604 The current DNS services returned during each query are maintained 3605 until bootstrapping is completed. If bootstrapping fails and the 3606 pledge returns to the Discovery state, it picks up where it left off 3607 and continues attempting bootstrapping. For example, if the first 3608 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 3609 second and third responses are tried. If these fail the pledge moves 3610 on to normal DNS-based Service Discovery. 3612 Appendix C. MUD Extension 3614 The following extension augments the MUD model to include a single 3615 node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the 3616 following sample module that has the following tree structure: 3618 module: ietf-mud-brski-masa 3619 augment /ietf-mud:mud: 3620 +--rw masa-server? inet:uri 3622 The model is defined as follows: 3624 file "ietf-mud-extension@2018-02-14.yang" 3625 module ietf-mud-brski-masa { 3626 yang-version 1.1; 3627 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 3628 prefix ietf-mud-brski-masa; 3629 import ietf-mud { 3630 prefix ietf-mud; 3631 } 3632 import ietf-inet-types { 3633 prefix inet; 3634 } 3636 organization 3637 "IETF ANIMA (Autonomic Networking Integrated Model and 3638 Approach) Working Group"; 3639 contact 3640 "WG Web: http://tools.ietf.org/wg/anima/ 3641 WG List: anima@ietf.org 3642 "; 3643 description 3644 "BRSKI extension to a MUD file to indicate the 3645 MASA URL."; 3647 revision 2018-02-14 { 3648 description 3649 "Initial revision."; 3650 reference 3651 "RFC XXXX: Manufacturer Usage Description 3652 Specification"; 3653 } 3655 augment "/ietf-mud:mud" { 3656 description 3657 "BRSKI extension to a MUD file to indicate the 3658 MASA URL."; 3659 leaf masa-server { 3660 type inet:uri; 3661 description 3662 "This value is the URI of the MASA server"; 3663 } 3664 } 3665 } 3666 3668 The MUD extensions string "masa" is defined, and MUST be included in 3669 the extensions array of the mud container of a MUD file when this 3670 extension is used. 3672 Appendix D. Example Vouchers 3674 Three entities are involved in a voucher: the MASA issues (signs) it, 3675 the registrar's public key is mentioned in the voucher, and the 3676 pledge validates it. In order to provide reproduceable examples the 3677 public and private keys for an example MASA and registrar are first 3678 listed. 3680 D.1. Keys involved 3682 The Manufacturer has a Certificate Authority that signs the pledge's 3683 IDevID. In addition the Manufacturer's signing authority (the MASA) 3684 signs the vouchers, and that certificate must distributed to the 3685 devices at manufacturing time so that vouchers can be validated. 3687 D.1.1. MASA key pair for voucher signatures 3689 This private key signs vouchers: 3691 -----BEGIN EC PRIVATE KEY----- 3692 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 3693 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 3694 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 3695 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 3696 -----END EC PRIVATE KEY----- 3698 This public key validates vouchers: 3700 -----BEGIN CERTIFICATE----- 3701 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3702 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3703 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 3704 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 3705 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 3706 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 3707 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 3708 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 3709 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 3710 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 3711 -----END CERTIFICATE----- 3713 D.1.2. Manufacturer key pair for IDevID signatures 3715 This private key signs IDevID certificates: 3717 -----BEGIN EC PRIVATE KEY----- 3718 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 3719 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 3720 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 3721 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 3722 -----END EC PRIVATE KEY----- 3724 This public key validates IDevID certificates: 3726 -----BEGIN CERTIFICATE----- 3727 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3728 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3729 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 3730 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 3731 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 3732 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 3733 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 3734 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 3735 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 3736 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 3737 -----END CERTIFICATE----- 3739 D.1.3. Registrar key pair 3741 The registrar key (or chain) is the representative of the domain 3742 owner. This key signs registrar voucher-requests: 3744 -----BEGIN EC PRIVATE KEY----- 3745 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 3746 AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g 3747 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 3748 -----END EC PRIVATE KEY----- 3750 The public key is indicated in a pledge voucher-request to show 3751 proximity. 3753 -----BEGIN CERTIFICATE----- 3754 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC 3755 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n 3756 IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 3757 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw 3758 EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N 3759 w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ 3760 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 3761 /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC 3762 MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR 3763 c3o= 3764 -----END CERTIFICATE----- 3765 The registrar public certificate as decoded by openssl's x509 3766 utility. Note that the registrar certificate is marked with the 3767 cmcRA extension. 3769 Certificate: 3770 Data: 3771 Version: 3 (0x2) 3772 Serial Number: 3 (0x3) 3773 Signature Algorithm: ecdsa-with-SHA384 3774 Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA 3775 Validity 3776 Not Before: Sep 5 01:12:45 2017 GMT 3777 Not After : Sep 5 01:12:45 2019 GMT 3778 Subject: DC=ca, DC=sandelman, CN=localhost 3779 Subject Public Key Info: 3780 Public Key Algorithm: id-ecPublicKey 3781 Public-Key: (256 bit) 3782 pub: 3783 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 3784 8:17: 3785 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 3786 3:3e: 3787 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 3788 9:ba: 3789 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 3790 f:96: 3791 e9:9d:e2:bc:b2 3792 ASN1 OID: prime256v1 3793 X509v3 extensions: 3794 X509v3 Basic Constraints: 3795 CA:FALSE 3796 Signature Algorithm: ecdsa-with-SHA384 3797 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 3798 5b: 3799 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 3800 b6: 3801 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 3802 02: 3803 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 3804 c3: 3805 ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: 3806 4b: 3807 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 3809 D.1.4. Pledge key pair 3811 The pledge has an IDevID key pair built in at manufacturing time: 3813 -----BEGIN EC PRIVATE KEY----- 3814 MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49 3815 AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p 3816 r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg== 3817 -----END EC PRIVATE KEY----- 3819 The public key is used by the registrar to find the MASA. The MASA 3820 URL is in an extension described in Section 2.3. RFC-EDITOR: Note 3821 that these certificates are using a Private Enterprise Number for the 3822 not-yet-assigned by IANA MASA URL, and need to be replaced before 3823 AUTH48. 3825 -----BEGIN CERTIFICATE----- 3826 MIICMjCCAbegAwIBAgIBDDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3827 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3828 IEhpZ2h3YXkgQ0EwIBcNMTcxMDEyMTM1MjUyWhgPMjk5OTEyMzEwMDAwMDBaMEsx 3829 EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEa 3830 MBgGA1UEAwwRMDAtRDAtRTUtRjItMDAtMDIwWTATBgcqhkjOPQIBBggqhkjOPQMB 3831 BwNCAARJp5i0dU1aUnR2u8wMRwgkNupNbNM7m1n0mj+0KJZjcPIqID+trPjTSobt 3832 uIdpRPfGZ8hU/nIUveqwyoYI8BPbo4GHMIGEMB0GA1UdDgQWBBQdMRZhthFQmzz6 3833 E7YVXzkL7XZDKjAJBgNVHRMEAjAAMCsGA1UdEQQkMCKgIAYJKwYBBAGC7lIBoBMM 3834 ETAwLUQwLUU1LUYyLTAwLTAyMCsGCSsGAQQBgu5SAgQeDBxodHRwczovL2hpZ2h3 3835 YXkuc2FuZGVsbWFuLmNhMAoGCCqGSM49BAMCA2kAMGYCMQDhJ1N+eanW1U/e5qoM 3836 SGvUvWHR7uic8cJbh7vXy580nBs8bpNn60k/+IzvEUetMzICMQCr1uxvdYeKq7mb 3837 RXCR4ZCJsw67fJ7jyXZbCUSir+3wBT2+lWggzPDRgYB5ABb7sAw= 3838 -----END CERTIFICATE----- 3840 The pledge public certificate as decoded by openssl's x509 utility so 3841 that the extensions can be seen. A second custom Extension is 3842 included to provided to contain the EUI48/EUI64 that the pledge will 3843 configure. 3845 Certificate: 3846 Data: 3847 Version: 3 (0x2) 3848 Serial Number: 12 (0xc) 3849 Signature Algorithm: ecdsa-with-SHA256 3850 Issuer: DC=ca, DC=sandelman, CN=Unstrung Highway CA 3851 Validity 3852 Not Before: Oct 12 13:52:52 2017 GMT 3853 Not After : Dec 31 00:00:00 2999 GMT 3854 Subject: DC=ca, DC=sandelman, CN=00-D0-E5-F2-00-02 3855 Subject Public Key Info: 3856 Public Key Algorithm: id-ecPublicKey 3857 Public-Key: (256 bit) 3858 pub: 3859 04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0 3860 c:47: 3861 08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 3862 4:28: 3863 96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 3864 d:b8: 3865 87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b 3866 0:ca: 3867 86:08:f0:13:db 3868 ASN1 OID: prime256v1 3869 X509v3 extensions: 3870 X509v3 Subject Key Identifier: 3871 1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39 3872 :0B:ED:76:43:2A 3873 X509v3 Basic Constraints: 3874 CA:FALSE 3875 X509v3 Subject Alternative Name: 3876 othername: 3877 1.3.6.1.4.1.46930.2: 3878 ..https://highway.sandelman.ca 3879 Signature Algorithm: ecdsa-with-SHA256 3880 30:66:02:31:00:e1:27:53:7e:79:a9:d6:d5:4f:de:e6:aa: 3881 0c: 3882 48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f: 3883 34: 3884 9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32: 3885 02: 3886 31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90: 3887 89: 3888 b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d: 3889 be: 3890 95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c 3892 D.2. Example process 3894 RFC-EDITOR: these examples will need to be replaced with CMS versions 3895 once IANA has assigned the eContentType in [RFC8366]. 3897 D.2.1. Pledge to Registrar 3899 As described in Section 5.2, the pledge will sign a pledge voucher- 3900 request containing the registrar's public key in the proximity- 3901 registrar-cert field. The base64 has been wrapped at 60 characters 3902 for presentation reasons. 3904 MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC 3905 Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 3906 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 3907 OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw 3908 LTAyIiwibm9uY2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGlt 3909 aXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFL 3910 QmdncWhrak9QUVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH 3911 VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJB 3912 TU1GRlZ1YzNSeWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRB 3913 eE1USTBOVm9YRFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21U 3914 OGl4a0FSa1dBbU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNi 3915 V0Z1TVJJd0VBWURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BR 3916 SUJCZ2dxaGtqT1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3Ra 3917 OTR3YUFJVjBpL29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgv 3918 d2ZBcFI2c3ZsdW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdT 3919 TTQ5QkFNREEya0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FD 3920 NnFqSWVZMmprRHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjll 3921 ZmJUTGJkdERrM3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0 3922 MWx5Rk0rMGZZcFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqG 3923 SM49BAMCME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkW 3924 CXNhbmRlbG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0x 3925 NzEwMTIxMzUyNTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixk 3926 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEw 3927 MC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmn 3928 mLR1TVpSdHa7zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE 3929 98ZnyFT+chS96rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoT 3930 thVfOQvtdkMqMAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGg 3931 EwwRMDAtRDAtRTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8v 3932 aGlnaHdheS5zYW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355 3933 qdbVT97mqgxIa9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIx 3934 AKvW7G91h4qruZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkA 3935 FvuwDDGCAaUwggGhAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 3936 CZImiZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdo 3937 d2F5IENBAgEMMA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkq 3938 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjE3NTQzMFowLwYJKoZI 3939 hvcNAQkEMSIEIP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkG 3940 CSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglg 3941 hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 3942 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEYw 3943 RAIgYUy0NTdP+xTkm/Et69eI++S/2z3dQwPKOwdL0cDCSvACIAh3jJbybMnK 3944 cf7DKKnsn2G/O06HeB/8imMI+hnA7CfN 3946 file: examples/vr_00-D0-E5-F2-00-02.pkcs 3948 The ASN1 decoding of the artifact: 3950 0:d=0 hl=4 l=1820 cons: SEQUENCE 3951 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 3953 Data 3954 15:d=1 hl=4 l=1805 cons: cont [ 0 ] 3955 19:d=2 hl=4 l=1801 cons: SEQUENCE 3956 23:d=3 hl=2 l= 1 prim: INTEGER :01 3957 26:d=3 hl=2 l= 15 cons: SET 3958 28:d=4 hl=2 l= 13 cons: SEQUENCE 3959 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 3960 41:d=5 hl=2 l= 0 prim: NULL 3961 43:d=3 hl=4 l= 782 cons: SEQUENCE 3962 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 3963 58:d=4 hl=4 l= 767 cons: cont [ 0 ] 3964 62:d=5 hl=4 l= 763 prim: OCTET STRING :{"ietf-vouch 3965 er-request:voucher":{"assertion":"proximity","created-on":"2 3966 017-09-01","serial-number":"00-D0-E5-F2-00-02","nonce":"Dss9 3967 9sBr3pNMOACe-LYY7w","proximity-registrar-cert":"MIIBrjCCATOg 3968 AwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAX 3969 BgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5nIEZv 3970 dW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 3971 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFu 3972 MRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC 3973 AAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/p 3974 uhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49 3975 BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNi 3976 fVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR 3977 54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 3978 829:d=3 hl=4 l= 566 cons: cont [ 0 ] 3979 833:d=4 hl=4 l= 562 cons: SEQUENCE 3980 837:d=5 hl=4 l= 439 cons: SEQUENCE 3981 841:d=6 hl=2 l= 3 cons: cont [ 0 ] 3982 843:d=7 hl=2 l= 1 prim: INTEGER :02 3983 846:d=6 hl=2 l= 1 prim: INTEGER :0C 3984 849:d=6 hl=2 l= 10 cons: SEQUENCE 3985 851:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3986 HA256 3987 861:d=6 hl=2 l= 77 cons: SEQUENCE 3988 863:d=7 hl=2 l= 18 cons: SET 3989 865:d=8 hl=2 l= 16 cons: SEQUENCE 3990 867:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3991 ent 3992 879:d=9 hl=2 l= 2 prim: IA5STRING :ca 3993 883:d=7 hl=2 l= 25 cons: SET 3994 885:d=8 hl=2 l= 23 cons: SEQUENCE 3995 887:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3996 ent 3997 899:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3998 910:d=7 hl=2 l= 28 cons: SET 3999 912:d=8 hl=2 l= 26 cons: SEQUENCE 4000 914:d=9 hl=2 l= 3 prim: OBJECT :commonName 4001 919:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4002 hway CA 4003 940:d=6 hl=2 l= 32 cons: SEQUENCE 4004 942:d=7 hl=2 l= 13 prim: UTCTIME :171012135252 4005 Z 4006 957:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :299912310000 4007 00Z 4008 974:d=6 hl=2 l= 75 cons: SEQUENCE 4009 976:d=7 hl=2 l= 18 cons: SET 4010 978:d=8 hl=2 l= 16 cons: SEQUENCE 4011 980:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4012 ent 4013 992:d=9 hl=2 l= 2 prim: IA5STRING :ca 4014 996:d=7 hl=2 l= 25 cons: SET 4015 998:d=8 hl=2 l= 23 cons: SEQUENCE 4016 1000:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4017 ent 4018 1012:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4019 1023:d=7 hl=2 l= 26 cons: SET 4020 1025:d=8 hl=2 l= 24 cons: SEQUENCE 4021 1027:d=9 hl=2 l= 3 prim: OBJECT :commonName 4022 1032:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2- 4023 00-02 4024 1051:d=6 hl=2 l= 89 cons: SEQUENCE 4025 1053:d=7 hl=2 l= 19 cons: SEQUENCE 4026 1055:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 4027 ey 4028 1064:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 4029 1074:d=7 hl=2 l= 66 prim: BIT STRING 4030 1142:d=6 hl=3 l= 135 cons: cont [ 3 ] 4031 1145:d=7 hl=3 l= 132 cons: SEQUENCE 4032 1148:d=8 hl=2 l= 29 cons: SEQUENCE 4033 1150:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subje 4034 ct Key Identifier 4035 1155:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04 4036 141D311661B611509B3CFA13B6155F390BED76432A 4037 1179:d=8 hl=2 l= 9 cons: SEQUENCE 4038 1181:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 4039 Constraints 4040 1186:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 4041 00 4042 1190:d=8 hl=2 l= 43 cons: SEQUENCE 4043 1192:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subje 4044 ct Alternative Name 4045 1197:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:30 4046 22A02006092B0601040182EE5201A0130C1130302D44302D45352D46322D 4047 30302D3032 4048 1235:d=8 hl=2 l= 43 cons: SEQUENCE 4049 1237:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1. 4050 46930.2 4051 1248:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C 4052 1C68747470733A2F2F686967687761792E73616E64656C6D616E2E6361 4053 1280:d=5 hl=2 l= 10 cons: SEQUENCE 4054 1282:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4055 HA256 4056 1292:d=5 hl=2 l= 105 prim: BIT STRING 4057 1399:d=3 hl=4 l= 421 cons: SET 4058 1403:d=4 hl=4 l= 417 cons: SEQUENCE 4059 1407:d=5 hl=2 l= 1 prim: INTEGER :01 4060 1410:d=5 hl=2 l= 82 cons: SEQUENCE 4061 1412:d=6 hl=2 l= 77 cons: SEQUENCE 4062 1414:d=7 hl=2 l= 18 cons: SET 4063 1416:d=8 hl=2 l= 16 cons: SEQUENCE 4064 1418:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4065 ent 4066 1430:d=9 hl=2 l= 2 prim: IA5STRING :ca 4067 1434:d=7 hl=2 l= 25 cons: SET 4068 1436:d=8 hl=2 l= 23 cons: SEQUENCE 4069 1438:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4070 ent 4071 1450:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4072 1461:d=7 hl=2 l= 28 cons: SET 4073 1463:d=8 hl=2 l= 26 cons: SEQUENCE 4074 1465:d=9 hl=2 l= 3 prim: OBJECT :commonName 4075 1470:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4076 hway CA 4077 1491:d=6 hl=2 l= 1 prim: INTEGER :0C 4078 1494:d=5 hl=2 l= 13 cons: SEQUENCE 4079 1496:d=6 hl=2 l= 9 prim: OBJECT :sha256 4080 1507:d=6 hl=2 l= 0 prim: NULL 4081 1509:d=5 hl=3 l= 228 cons: cont [ 0 ] 4082 1512:d=6 hl=2 l= 24 cons: SEQUENCE 4083 1514:d=7 hl=2 l= 9 prim: OBJECT :contentType 4084 1525:d=7 hl=2 l= 11 cons: SET 4085 1527:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4086 1538:d=6 hl=2 l= 28 cons: SEQUENCE 4087 1540:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4088 1551:d=7 hl=2 l= 15 cons: SET 4089 1553:d=8 hl=2 l= 13 prim: UTCTIME :171012175430 4090 Z 4091 1568:d=6 hl=2 l= 47 cons: SEQUENCE 4092 1570:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 4093 t 4094 1581:d=7 hl=2 l= 34 cons: SET 4095 1583:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:FE 4096 7D72E29500F90A38E95021A215FD6D40B1629B99598177DC054AE0F9C8B6 4097 9F 4098 1617:d=6 hl=2 l= 121 cons: SEQUENCE 4099 1619:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 4100 ilities 4101 1630:d=7 hl=2 l= 108 cons: SET 4102 1632:d=8 hl=2 l= 106 cons: SEQUENCE 4103 1634:d=9 hl=2 l= 11 cons: SEQUENCE 4104 1636:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 4105 1647:d=9 hl=2 l= 11 cons: SEQUENCE 4106 1649:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 4107 1660:d=9 hl=2 l= 11 cons: SEQUENCE 4108 1662:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 4109 1673:d=9 hl=2 l= 10 cons: SEQUENCE 4110 1675:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 4111 1685:d=9 hl=2 l= 14 cons: SEQUENCE 4112 1687:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4113 1697:d=10 hl=2 l= 2 prim: INTEGER :80 4114 1701:d=9 hl=2 l= 13 cons: SEQUENCE 4115 1703:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4116 1713:d=10 hl=2 l= 1 prim: INTEGER :40 4117 1716:d=9 hl=2 l= 7 cons: SEQUENCE 4118 1718:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 4119 1725:d=9 hl=2 l= 13 cons: SEQUENCE 4120 1727:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4121 1737:d=10 hl=2 l= 1 prim: INTEGER :28 4122 1740:d=5 hl=2 l= 10 cons: SEQUENCE 4123 1742:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4124 HA256 4125 1752:d=5 hl=2 l= 70 prim: OCTET STRING [HEX DUMP]:30 4126 440220614CB435374FFB14E49BF12DEBD788FBE4BFDB3DDD4303CA3B074B 4127 D1C0C24AF0022008778C96F26CC9CA71FEC328A9EC9F61BF3B4E87781FFC 4128 8A6308FA19C0EC27CD 4130 The JSON contained in the voucher request: 4132 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr 4133 eated-on":"2017-09-01","serial-number":"00-D0-E5-F2-00-02"," 4134 nonce":"Dss99sBr3pNMOACe-LYY7w","proximity-registrar-cert":" 4135 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQB 4136 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVu 4137 c3RydW5nIEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAx 4138 MTI0NVowQzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJ 4139 c2FuZGVsbWFuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggq 4140 hkjOPQMBBwNCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6 4141 MwF5z+Dpb8/puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAA 4142 MAoGCCqGSM49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY 4143 2jkDx062nuNifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77 4144 XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 4146 D.2.2. Registrar to MASA 4148 As described in Section 5.5 the registrar will sign a registrar 4149 voucher-request, and will include pledge's voucher request in the 4150 prior-signed-voucher-request. 4152 MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC 4153 Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 4154 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 4155 OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi 4156 SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu 4157 ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI 4158 RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT 4159 SWIzRFFFSEFhQ0NBdjhFZ2dMN2V5SnBaWFJtTFhadmRXTm9aWEl0Y21WeGRX 4160 VnpkRHAyYjNWamFHVnlJanA3SW1GemMyVnlkR2x2YmlJNkluQnliM2hwYlds 4161 MGVTSXNJbU55WldGMFpXUXRiMjRpT2lJeU1ERTNMVEE1TFRBeElpd2ljMlZ5 4162 YVdGc0xXNTFiV0psY2lJNklqQXdMVVF3TFVVMUxVWXlMVEF3TFRBeUlpd2li 4163 bTl1WTJVaU9pSkVjM001T1hOQ2NqTndUazFQUVVObExVeFpXVGQzSWl3aWNI 4164 SnZlR2x0YVhSNUxYSmxaMmx6ZEhKaGNpMWpaWEowSWpvaVRVbEpRbkpxUTBO 4165 QlZFOW5RWGRKUWtGblNVSkJla0ZMUW1kbmNXaHJhazlRVVZGRVFYcENUMDFT 4166 U1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlExa3lSWGhIVkVGWVFtZHZT 4167 bXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRGbFhOSGhJVkVGaVFt 4168 ZE9Wa0pCVFUxR1JsWjFZek5TZVdSWE5XNUpSVnAyWkZjMU1GbFhiSFZKUlU1 4169 Q1RVSTBXRVJVUlROTlJHdDNUbFJCZUUxVVNUQk9WbTlZUkZSRk5VMUVhM2RP 4170 VkVGNFRWUkpNRTVXYjNkUmVrVlRUVUpCUjBObmJWTktiMjFVT0dsNGEwRlNh 4171 MWRCYlU1b1RWSnJkMFozV1V0RFdrbHRhVnBRZVV4SFVVSkhVbGxLWXpKR2RW 4172 cEhWbk5pVjBaMVRWSkpkMFZCV1VSV1VWRkVSRUZzYzJJeVRtaGlSMmgyWXpO 4173 UmQxZFVRVlJDWjJOeGFHdHFUMUJSU1VKQ1oyZHhhR3RxVDFCUlRVSkNkMDVE 4174 UVVGUk1WcEJOMDUzTUhoVFRTOVJNblV4T1RSR2VsRk5hM1JhT1RSM1lVRkpW 4175 akJwTDI5V1ZGQm5UMG80ZWxjMlRYZEdOWG9yUkhCaU9DOXdkV2hQWWtwTldq 4176 QlZOa2d2ZDJaQmNGSTJjM1pzZFcxa05ISjVlVzkzTUhkRGVrRktRbWRPVmto 4177 U1RVVkJha0ZCVFVGdlIwTkRjVWRUVFRRNVFrRk5SRUV5YTBGTlIxbERUVkZE 4178 TXk5cFZGRktNMlYyV1ZsaloySllhR0p0ZW5Kd05qUjBNMUZETm5GcVNXVlpN 4179 bXByUkhnd05qSnVkVTVwWmxaTGRIbGhZWEpoTTBZek1FRkphMHRUUlVOTlVV 4180 UnBNamxsWm1KVVRHSmtkRVJyTTNSbFkxa3Zja1EzVmpjM1dHRktObTVaUTIx 4181 a1JFTlNOVFJVY2xOR1RreG5lSFowTVd4NVJrMHJNR1paY0ZsU1l6TnZQU0o5 4182 ZmFDQ0FqWXdnZ0l5TUlJQnQ2QURBZ0VDQWdFTU1Bb0dDQ3FHU000OUJBTUNN 4183 RTB4RWpBUUJnb0praWFKay9Jc1pBRVpGZ0pqWVRFWk1CY0dDZ21TSm9tVDhp 4184 eGtBUmtXQ1hOaGJtUmxiRzFoYmpFY01Cb0dBMVVFQXd3VFZXNXpkSEoxYm1j 4185 Z1NHbG5hSGRoZVNCRFFUQWdGdzB4TnpFd01USXhNelV5TlRKYUdBOHlPVGs1 4186 TVRJek1UQXdNREF3TUZvd1N6RVNNQkFHQ2dtU0pvbVQ4aXhrQVJrV0FtTmhN 4187 Umt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdWc2JXRnVNUm93R0FZRFZR 4188 UUREQkV3TUMxRU1DMUZOUzFHTWkwd01DMHdNakJaTUJNR0J5cUdTTTQ5QWdF 4189 R0NDcUdTTTQ5QXdFSEEwSUFCRW1ubUxSMVRWcFNkSGE3ekF4SENDUTI2azFz 4190 MHp1YldmU2FQN1FvbG1Odzhpb2dQNjJzK05OS2h1MjRoMmxFOThabnlGVCtj 4191 aFM5NnJES2hnandFOXVqZ1ljd2dZUXdIUVlEVlIwT0JCWUVGQjB4Rm1HMkVW 4192 Q2JQUG9UdGhWZk9RdnRka01xTUFrR0ExVWRFd1FDTUFBd0t3WURWUjBSQkNR 4193 d0lxQWdCZ2tyQmdFRUFZTHVVZ0dnRXd3Uk1EQXRSREF0UlRVdFJqSXRNREF0 4194 TURJd0t3WUpLd1lCQkFHQzdsSUNCQjRNSEdoMGRIQnpPaTh2YUdsbmFIZGhl 4195 UzV6WVc1a1pXeHRZVzR1WTJFd0NnWUlLb1pJemowRUF3SURhUUF3WmdJeEFP 4196 RW5VMzU1cWRiVlQ5N21xZ3hJYTlTOVlkSHU2Snp4d2x1SHU5ZkxuelNjR3p4 4197 dWsyZnJTVC80ak84UlI2MHpNZ0l4QUt2VzdHOTFoNHFydVp0RmNKSGhrSW16 4198 RHJ0OG51UEpkbHNKUktLdjdmQUZQYjZWYUNETThOR0JnSGtBRnZ1d0RER0NB 4199 YVl3Z2dHaUFnRUJNRkl3VFRFU01CQUdDZ21TSm9tVDhpeGtBUmtXQW1OaE1S 4200 a3dGd1lLQ1pJbWlaUHlMR1FCR1JZSmMyRnVaR1ZzYldGdU1Sd3dHZ1lEVlFR 4201 RERCTlZibk4wY25WdVp5QklhV2RvZDJGNUlFTkJBZ0VNTUEwR0NXQ0dTQUZs 4202 QXdRQ0FRVUFvSUhrTUJnR0NTcUdTSWIzRFFFSkF6RUxCZ2txaGtpRzl3MEJC 4203 d0V3SEFZSktvWklodmNOQVFrRk1ROFhEVEUzTVRBeE1qRXpOVGd5TTFvd0x3 4204 WUpLb1pJaHZjTkFRa0VNU0lFSVA1OWN1S1ZBUGtLT09sUUlhSVYvVzFBc1dL 4205 Ym1WbUJkOXdGU3VENXlMYWZNSGtHQ1NxR1NJYjNEUUVKRHpGc01Hb3dDd1lK 4206 WUlaSUFXVURCQUVxTUFzR0NXQ0dTQUZsQXdRQkZqQUxCZ2xnaGtnQlpRTUVB 4207 UUl3Q2dZSUtvWklodmNOQXdjd0RnWUlLb1pJaHZjTkF3SUNBZ0NBTUEwR0ND 4208 cUdTSWIzRFFNQ0FnRkFNQWNHQlNzT0F3SUhNQTBHQ0NxR1NJYjNEUU1DQWdF 4209 b01Bb0dDQ3FHU000OUJBTUNCRWN3UlFJZ0VNZzFkSkw3RmNkdHJWRHg4cUNh 4210 em9lOSsyMk56NFp3UkI5Z0FUR0w3TU1DSVFEanNzVWxaekpxcDIva0NkNFdo 4211 eFVoc2FDcFRGd1Bybk5ldzV3Q2tZVUY4UT09In19oIIBsjCCAa4wggEzoAMC 4212 AQICAQMwCgYIKoZIzj0EAwMwTjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 4213 CZImiZPyLGQBGRYJc2FuZGVsbWFuMR0wGwYDVQQDDBRVbnN0cnVuZyBGb3Vu 4214 dGFpbiBDQTAeFw0xNzA5MDUwMTEyNDVaFw0xOTA5MDUwMTEyNDVaMEMxEjAQ 4215 BgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjES 4216 MBAGA1UEAwwJbG9jYWxob3N0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 4217 NWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g6W/P6boT 4218 myTGdFOh/8HwKUerL5bpneK8sqMNMAswCQYDVR0TBAIwADAKBggqhkjOPQQD 4219 AwNpADBmAjEAt/4k0Cd3r2GHIG14W5s66euLd0AuqoyHmNo5A8dOtp7jYn1S 4220 rcmmq2txd9ACJCkhAjEA4tvXn20y23bQ5N7XnGP6w+1e+12iep2ApnQwkeeE 4221 60hTS4Mb7dZchTPtH2KWEXN6MYIBpzCCAaMCAQEwUzBOMRIwEAYKCZImiZPy 4222 LGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMM 4223 FFVuc3RydW5nIEZvdW50YWluIENBAgEDMA0GCWCGSAFlAwQCAQUAoIHkMBgG 4224 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAy 4225 NjAxMzYxOFowLwYJKoZIhvcNAQkEMSIEIEQBM73PZzPo7tE9Mj8gQvaaYeMQ 4226 OsxlACaW/HenAqNwMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG 4227 CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN 4228 AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo 4229 MAoGCCqGSM49BAMCBEcwRQIgDdp5uPUlMKp7GFQAD7ypAgqFv8q+KkJt6c3O 4230 7iVpVI8CIQCD1u8BkxipvigwvIDmWfjlYdJxcvozNjffq5j3UHg7Rg== 4232 file: examples/parboiled_vr_00-D0-E5-F2-00-02.pkcs 4234 The ASN1 decoding of the artifact: 4236 0:d=0 hl=4 l=3546 cons: SEQUENCE 4237 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 4238 Data 4239 15:d=1 hl=4 l=3531 cons: cont [ 0 ] 4240 19:d=2 hl=4 l=3527 cons: SEQUENCE 4241 23:d=3 hl=2 l= 1 prim: INTEGER :01 4242 26:d=3 hl=2 l= 15 cons: SET 4243 28:d=4 hl=2 l= 13 cons: SEQUENCE 4244 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 4245 41:d=5 hl=2 l= 0 prim: NULL 4246 43:d=3 hl=4 l=2638 cons: SEQUENCE 4247 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 4248 58:d=4 hl=4 l=2623 cons: cont [ 0 ] 4249 62:d=5 hl=4 l=2619 prim: OCTET STRING :{"ietf-vouch 4250 er-request:voucher":{"assertion":"proximity","created-on":"2 4251 017-09-15T00:00:00.000Z","serial-number":"JADA123456789","no 4252 nce":"abcd1234","prior-signed-voucher-request":"MIIHHQYJKoZI 4253 hvcNAQcCoIIHDjCCBwoCAQExDzANBglghkgBZQMEAgEFADCCAw4GCSqGSIb3 4254 DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7 4255 ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24iOiIyMDE3LTA5 4256 LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9u 4257 Y2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGltaXR5LXJlZ2lz 4258 dHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFLQmdncWhrak9Q 4259 UVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtp 4260 YUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJBTU1GRlZ1YzNS 4261 eWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRBeE1USTBOVm9Y 4262 RFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21UOGl4a0FSa1dB 4263 bU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNiV0Z1TVJJd0VB 4264 WURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtq 4265 T1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3RaOTR3YUFJVjBp 4266 L29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgvd2ZBcFI2c3Zs 4267 dW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdTTTQ5QkFNREEy 4268 a0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FDNnFqSWVZMmpr 4269 RHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjllZmJUTGJkdERr 4270 M3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0MWx5Rk0rMGZZ 4271 cFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqGSM49BAMCME0x 4272 EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1h 4273 bjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0xNzEwMTIxMzUy 4274 NTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixkARkWAmNhMRkw 4275 FwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEwMC1EMC1FNS1G 4276 Mi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmnmLR1TVpSdHa7 4277 zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE98ZnyFT+chS9 4278 6rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoTthVfOQvtdkMq 4279 MAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGgEwwRMDAtRDAt 4280 RTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8vaGlnaHdheS5z 4281 YW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355qdbVT97mqgxI 4282 a9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIxAKvW7G91h4qr 4283 uZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkAFvuwDDGCAaYw 4284 ggGiAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 4285 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBAgEM 4286 MA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw 4287 HAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjEzNTgyM1owLwYJKoZIhvcNAQkEMSIE 4288 IP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkGCSqGSIb3DQEJ 4289 DzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw 4290 CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG 4291 BSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEcwRQIgEMg1dJL7 4292 FcdtrVDx8qCazoe9+22Nz4ZwRB9gATGL7MMCIQDjssUlZzJqp2/kCd4WhxUh 4293 saCpTFwPrnNew5wCkYUF8Q=="}} 4294 2685:d=3 hl=4 l= 434 cons: cont [ 0 ] 4295 2689:d=4 hl=4 l= 430 cons: SEQUENCE 4296 2693:d=5 hl=4 l= 307 cons: SEQUENCE 4297 2697:d=6 hl=2 l= 3 cons: cont [ 0 ] 4298 2699:d=7 hl=2 l= 1 prim: INTEGER :02 4299 2702:d=6 hl=2 l= 1 prim: INTEGER :03 4300 2705:d=6 hl=2 l= 10 cons: SEQUENCE 4301 2707:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4302 HA384 4303 2717:d=6 hl=2 l= 78 cons: SEQUENCE 4304 2719:d=7 hl=2 l= 18 cons: SET 4305 2721:d=8 hl=2 l= 16 cons: SEQUENCE 4306 2723:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4307 ent 4308 2735:d=9 hl=2 l= 2 prim: IA5STRING :ca 4309 2739:d=7 hl=2 l= 25 cons: SET 4310 2741:d=8 hl=2 l= 23 cons: SEQUENCE 4311 2743:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4312 ent 4313 2755:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4314 2766:d=7 hl=2 l= 29 cons: SET 4315 2768:d=8 hl=2 l= 27 cons: SEQUENCE 4316 2770:d=9 hl=2 l= 3 prim: OBJECT :commonName 4317 2775:d=9 hl=2 l= 20 prim: UTF8STRING :Unstrung Fou 4318 ntain CA 4319 2797:d=6 hl=2 l= 30 cons: SEQUENCE 4320 2799:d=7 hl=2 l= 13 prim: UTCTIME :170905011245 4321 Z 4322 2814:d=7 hl=2 l= 13 prim: UTCTIME :190905011245 4323 Z 4324 2829:d=6 hl=2 l= 67 cons: SEQUENCE 4325 2831:d=7 hl=2 l= 18 cons: SET 4326 2833:d=8 hl=2 l= 16 cons: SEQUENCE 4327 2835:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4328 ent 4329 2847:d=9 hl=2 l= 2 prim: IA5STRING :ca 4330 2851:d=7 hl=2 l= 25 cons: SET 4331 2853:d=8 hl=2 l= 23 cons: SEQUENCE 4332 2855:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4333 ent 4334 2867:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4335 2878:d=7 hl=2 l= 18 cons: SET 4336 2880:d=8 hl=2 l= 16 cons: SEQUENCE 4337 2882:d=9 hl=2 l= 3 prim: OBJECT :commonName 4338 2887:d=9 hl=2 l= 9 prim: UTF8STRING :localhost 4339 2898:d=6 hl=2 l= 89 cons: SEQUENCE 4340 2900:d=7 hl=2 l= 19 cons: SEQUENCE 4341 2902:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 4342 ey 4343 2911:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 4344 2921:d=7 hl=2 l= 66 prim: BIT STRING 4345 2989:d=6 hl=2 l= 13 cons: cont [ 3 ] 4346 2991:d=7 hl=2 l= 11 cons: SEQUENCE 4347 2993:d=8 hl=2 l= 9 cons: SEQUENCE 4348 2995:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 4349 Constraints 4350 3000:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 4351 00 4352 3004:d=5 hl=2 l= 10 cons: SEQUENCE 4353 3006:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4354 HA384 4355 3016:d=5 hl=2 l= 105 prim: BIT STRING 4356 3123:d=3 hl=4 l= 423 cons: SET 4357 3127:d=4 hl=4 l= 419 cons: SEQUENCE 4358 3131:d=5 hl=2 l= 1 prim: INTEGER :01 4359 3134:d=5 hl=2 l= 83 cons: SEQUENCE 4360 3136:d=6 hl=2 l= 78 cons: SEQUENCE 4361 3138:d=7 hl=2 l= 18 cons: SET 4362 3140:d=8 hl=2 l= 16 cons: SEQUENCE 4363 3142:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4364 ent 4365 3154:d=9 hl=2 l= 2 prim: IA5STRING :ca 4366 3158:d=7 hl=2 l= 25 cons: SET 4367 3160:d=8 hl=2 l= 23 cons: SEQUENCE 4368 3162:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4369 ent 4370 3174:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4371 3185:d=7 hl=2 l= 29 cons: SET 4372 3187:d=8 hl=2 l= 27 cons: SEQUENCE 4373 3189:d=9 hl=2 l= 3 prim: OBJECT :commonName 4374 3194:d=9 hl=2 l= 20 prim: UTF8STRING :Unstrung Fou 4375 ntain CA 4376 3216:d=6 hl=2 l= 1 prim: INTEGER :03 4377 3219:d=5 hl=2 l= 13 cons: SEQUENCE 4378 3221:d=6 hl=2 l= 9 prim: OBJECT :sha256 4379 3232:d=6 hl=2 l= 0 prim: NULL 4380 3234:d=5 hl=3 l= 228 cons: cont [ 0 ] 4381 3237:d=6 hl=2 l= 24 cons: SEQUENCE 4382 3239:d=7 hl=2 l= 9 prim: OBJECT :contentType 4383 3250:d=7 hl=2 l= 11 cons: SET 4384 3252:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4385 3263:d=6 hl=2 l= 28 cons: SEQUENCE 4386 3265:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4387 3276:d=7 hl=2 l= 15 cons: SET 4388 3278:d=8 hl=2 l= 13 prim: UTCTIME :171026013618 4389 Z 4390 3293:d=6 hl=2 l= 47 cons: SEQUENCE 4391 3295:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 4392 t 4393 3306:d=7 hl=2 l= 34 cons: SET 4394 3308:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:44 4395 0133BDCF6733E8EED13D323F2042F69A61E3103ACC65002696FC77A702A3 4396 70 4397 3342:d=6 hl=2 l= 121 cons: SEQUENCE 4398 3344:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 4399 ilities 4400 3355:d=7 hl=2 l= 108 cons: SET 4401 3357:d=8 hl=2 l= 106 cons: SEQUENCE 4402 3359:d=9 hl=2 l= 11 cons: SEQUENCE 4403 3361:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 4404 3372:d=9 hl=2 l= 11 cons: SEQUENCE 4405 3374:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 4406 3385:d=9 hl=2 l= 11 cons: SEQUENCE 4407 3387:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 4408 3398:d=9 hl=2 l= 10 cons: SEQUENCE 4409 3400:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 4410 3410:d=9 hl=2 l= 14 cons: SEQUENCE 4411 3412:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4412 3422:d=10 hl=2 l= 2 prim: INTEGER :80 4413 3426:d=9 hl=2 l= 13 cons: SEQUENCE 4414 3428:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4415 3438:d=10 hl=2 l= 1 prim: INTEGER :40 4416 3441:d=9 hl=2 l= 7 cons: SEQUENCE 4417 3443:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 4418 3450:d=9 hl=2 l= 13 cons: SEQUENCE 4419 3452:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4420 3462:d=10 hl=2 l= 1 prim: INTEGER :28 4421 3465:d=5 hl=2 l= 10 cons: SEQUENCE 4422 3467:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4423 HA256 4424 3477:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30 4425 4502200DDA79B8F52530AA7B1854000FBCA9020A85BFCABE2A426DE9CDCE 4426 EE2569548F02210083D6EF019318A9BE2830BC80E659F8E561D27172FA33 4427 3637DFAB98F750783B46 4429 D.2.3. MASA to Registrar 4431 The MASA will return a voucher to the registrar, to be relayed to the 4432 pledge. 4434 MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC 4435 AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6 4436 eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x 4437 MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt 4438 RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci 4439 LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6 4440 QUtCZ2dxaGtqT1BRUURBekJPTVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJF 4441 eEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eEhUQWJCZ05W 4442 QkFNTUZGVnVjM1J5ZFc1bklFWnZkVzUwWVdsdUlFTkJNQjRYRFRFM01Ea3dO 4443 VEF4TVRJME5Wb1hEVEU1TURrd05UQXhNVEkwTlZvd1F6RVNNQkFHQ2dtU0pv 4444 bVQ4aXhrQVJrV0FtTmhNUmt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdW 4445 c2JXRnVNUkl3RUFZRFZRUUREQWxzYjJOaGJHaHZjM1F3V1RBVEJnY3Foa2pP 4446 UFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVExWkE3TncweFNNL1EydTE5NEZ6UU1r 4447 dFo5NHdhQUlWMGkvb1ZUUGdPSjh6VzZNd0Y1eitEcGI4L3B1aE9iSk1aMFU2 4448 SC93ZkFwUjZzdmx1bWQ0cnl5b3cwd0N6QUpCZ05WSFJNRUFqQUFNQW9HQ0Nx 4449 R1NNNDlCQU1EQTJrQU1HWUNNUUMzL2lUUUozZXZZWWNnYlhoYm16cnA2NHQz 4450 UUM2cWpJZVkyamtEeDA2Mm51TmlmVkt0eWFhcmEzRjMwQUlrS1NFQ01RRGky 4451 OWVmYlRMYmR0RGszdGVjWS9yRDdWNzdYYUo2bllDbWREQ1I1NFRyU0ZOTGd4 4452 dnQxbHlGTSswZllwWVJjM289In19oIIB0zCCAc8wggFWoAMCAQICAQEwCgYI 4453 KoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 4454 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBMB4X 4455 DTE3MDMyNjE2MTk0MFoXDTE5MDMyNjE2MTk0MFowRzESMBAGCgmSJomT8ixk 4456 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRYwFAYDVQQDDA1V 4457 bnN0cnVuZyBNQVNBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2QB90W9hbyCT 4458 p7bPr17llt+aH8jWwh84wMzotpFmRRNQcrqyiJjXDTBRoqxp0VyFxqlgn8OS 4459 AoCfArjN71ebcvW3+ylJTpHo8077/uT1fvnpZD/R0PN76kwMLNlsFk8SoxAw 4460 DjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAMCA2cAMGQCMBm9KMjNHaD+rd/y 4461 0jy+Tg7mrRMDGIe1hjviGExwvCuxMhwTpgmEXik9vhoVfwi1swIwTculDCU7 4462 dbbMSbCanTD1CBY/uMGYNQDiG/yaAOjO6996cC0E6x0cRM1TBn1jpGFMMYIB 4463 xjCCAcICAQEwUjBNMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/Is 4464 ZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EC 4465 AQEwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH 4466 ATAcBgkqhkiG9w0BCQUxDxcNMTcxMDEyMTc1NDMxWjAvBgkqhkiG9w0BCQQx 4467 IgQgQXnG628cIW8MoYfB1ljDDlLlJQlxED2tnjcvkLEfix0weQYJKoZIhvcN 4468 AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB 4469 AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw 4470 BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIzj0EAwIEZzBlAjEAhzid 4471 /AkNjttpSP1rflNppdHsi324Z2+TXJxueewnJ8z/2NXb+Tf3DsThv7du00Oz 4472 AjBjyOnmkkSKHsPR2JluA5c6wovuPEnNKP32daGGeFKGEHMkTInbrqipC881 4473 /5K9Q+k= 4475 file: examples/voucher_00-D0-E5-F2-00-02.pkcs 4477 The ASN1 decoding of the artifact: 4479 0:d=0 hl=4 l=1756 cons: SEQUENCE 4480 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 4481 Data 4482 15:d=1 hl=4 l=1741 cons: cont [ 0 ] 4483 19:d=2 hl=4 l=1737 cons: SEQUENCE 4484 23:d=3 hl=2 l= 1 prim: INTEGER :01 4485 26:d=3 hl=2 l= 15 cons: SET 4486 28:d=4 hl=2 l= 13 cons: SEQUENCE 4487 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 4488 41:d=5 hl=2 l= 0 prim: NULL 4489 43:d=3 hl=4 l= 784 cons: SEQUENCE 4490 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 4491 58:d=4 hl=4 l= 769 cons: cont [ 0 ] 4492 62:d=5 hl=4 l= 765 prim: OCTET STRING :{"ietf-vouch 4493 er:voucher":{"assertion":"logged","created-on":"2017-10-12T1 4494 3:54:31.439-04:00","serial-number":"00-D0-E5-F2-00-02","nonc 4495 e":"Dss99sBr3pNMOACe-LYY7w","pinned-domain-cert":"MIIBrjCCAT 4496 OgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYCY2ExGT 4497 AXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5nIE 4498 ZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQz 4499 ESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbW 4500 FuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBw 4501 NCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8 4502 /puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM 4503 49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nu 4504 NifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdD 4505 CR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 4506 831:d=3 hl=4 l= 467 cons: cont [ 0 ] 4507 835:d=4 hl=4 l= 463 cons: SEQUENCE 4508 839:d=5 hl=4 l= 342 cons: SEQUENCE 4509 843:d=6 hl=2 l= 3 cons: cont [ 0 ] 4510 845:d=7 hl=2 l= 1 prim: INTEGER :02 4511 848:d=6 hl=2 l= 1 prim: INTEGER :01 4512 851:d=6 hl=2 l= 10 cons: SEQUENCE 4513 853:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4514 HA256 4515 863:d=6 hl=2 l= 77 cons: SEQUENCE 4516 865:d=7 hl=2 l= 18 cons: SET 4517 867:d=8 hl=2 l= 16 cons: SEQUENCE 4518 869:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4519 ent 4520 881:d=9 hl=2 l= 2 prim: IA5STRING :ca 4521 885:d=7 hl=2 l= 25 cons: SET 4522 887:d=8 hl=2 l= 23 cons: SEQUENCE 4523 889:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4524 ent 4525 901:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4526 912:d=7 hl=2 l= 28 cons: SET 4527 914:d=8 hl=2 l= 26 cons: SEQUENCE 4528 916:d=9 hl=2 l= 3 prim: OBJECT :commonName 4529 921:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4531 hway CA 4532 942:d=6 hl=2 l= 30 cons: SEQUENCE 4533 944:d=7 hl=2 l= 13 prim: UTCTIME :170326161940 4534 Z 4535 959:d=7 hl=2 l= 13 prim: UTCTIME :190326161940 4536 Z 4537 974:d=6 hl=2 l= 71 cons: SEQUENCE 4538 976:d=7 hl=2 l= 18 cons: SET 4539 978:d=8 hl=2 l= 16 cons: SEQUENCE 4540 980:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4541 ent 4542 992:d=9 hl=2 l= 2 prim: IA5STRING :ca 4543 996:d=7 hl=2 l= 25 cons: SET 4544 998:d=8 hl=2 l= 23 cons: SEQUENCE 4545 1000:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4546 ent 4547 1012:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4548 1023:d=7 hl=2 l= 22 cons: SET 4549 1025:d=8 hl=2 l= 20 cons: SEQUENCE 4550 1027:d=9 hl=2 l= 3 prim: OBJECT :commonName 4551 1032:d=9 hl=2 l= 13 prim: UTF8STRING :Unstrung MAS 4552 A 4553 1047:d=6 hl=2 l= 118 cons: SEQUENCE 4554 1049:d=7 hl=2 l= 16 cons: SEQUENCE 4555 1051:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 4556 ey 4557 1060:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 4558 1067:d=7 hl=2 l= 98 prim: BIT STRING 4559 1167:d=6 hl=2 l= 16 cons: cont [ 3 ] 4560 1169:d=7 hl=2 l= 14 cons: SEQUENCE 4561 1171:d=8 hl=2 l= 12 cons: SEQUENCE 4562 1173:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 4563 Constraints 4564 1178:d=9 hl=2 l= 1 prim: BOOLEAN :255 4565 1181:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 4566 00 4567 1185:d=5 hl=2 l= 10 cons: SEQUENCE 4568 1187:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4569 HA256 4570 1197:d=5 hl=2 l= 103 prim: BIT STRING 4571 1302:d=3 hl=4 l= 454 cons: SET 4572 1306:d=4 hl=4 l= 450 cons: SEQUENCE 4573 1310:d=5 hl=2 l= 1 prim: INTEGER :01 4574 1313:d=5 hl=2 l= 82 cons: SEQUENCE 4575 1315:d=6 hl=2 l= 77 cons: SEQUENCE 4576 1317:d=7 hl=2 l= 18 cons: SET 4577 1319:d=8 hl=2 l= 16 cons: SEQUENCE 4578 1321:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4580 ent 4581 1333:d=9 hl=2 l= 2 prim: IA5STRING :ca 4582 1337:d=7 hl=2 l= 25 cons: SET 4583 1339:d=8 hl=2 l= 23 cons: SEQUENCE 4584 1341:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4585 ent 4586 1353:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4587 1364:d=7 hl=2 l= 28 cons: SET 4588 1366:d=8 hl=2 l= 26 cons: SEQUENCE 4589 1368:d=9 hl=2 l= 3 prim: OBJECT :commonName 4590 1373:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4591 hway CA 4592 1394:d=6 hl=2 l= 1 prim: INTEGER :01 4593 1397:d=5 hl=2 l= 13 cons: SEQUENCE 4594 1399:d=6 hl=2 l= 9 prim: OBJECT :sha256 4595 1410:d=6 hl=2 l= 0 prim: NULL 4596 1412:d=5 hl=3 l= 228 cons: cont [ 0 ] 4597 1415:d=6 hl=2 l= 24 cons: SEQUENCE 4598 1417:d=7 hl=2 l= 9 prim: OBJECT :contentType 4599 1428:d=7 hl=2 l= 11 cons: SET 4600 1430:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4601 1441:d=6 hl=2 l= 28 cons: SEQUENCE 4602 1443:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4603 1454:d=7 hl=2 l= 15 cons: SET 4604 1456:d=8 hl=2 l= 13 prim: UTCTIME :171012175431 4605 Z 4606 1471:d=6 hl=2 l= 47 cons: SEQUENCE 4607 1473:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 4608 t 4609 1484:d=7 hl=2 l= 34 cons: SET 4610 1486:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:41 4611 79C6EB6F1C216F0CA187C1D658C30E52E5250971103DAD9E372F90B11F8B 4612 1D 4613 1520:d=6 hl=2 l= 121 cons: SEQUENCE 4614 1522:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 4615 ilities 4616 1533:d=7 hl=2 l= 108 cons: SET 4617 1535:d=8 hl=2 l= 106 cons: SEQUENCE 4618 1537:d=9 hl=2 l= 11 cons: SEQUENCE 4619 1539:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 4620 1550:d=9 hl=2 l= 11 cons: SEQUENCE 4621 1552:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 4622 1563:d=9 hl=2 l= 11 cons: SEQUENCE 4623 1565:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 4624 1576:d=9 hl=2 l= 10 cons: SEQUENCE 4625 1578:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 4626 1588:d=9 hl=2 l= 14 cons: SEQUENCE 4627 1590:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4628 1600:d=10 hl=2 l= 2 prim: INTEGER :80 4629 1604:d=9 hl=2 l= 13 cons: SEQUENCE 4630 1606:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4631 1616:d=10 hl=2 l= 1 prim: INTEGER :40 4632 1619:d=9 hl=2 l= 7 cons: SEQUENCE 4633 1621:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 4634 1628:d=9 hl=2 l= 13 cons: SEQUENCE 4635 1630:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4636 1640:d=10 hl=2 l= 1 prim: INTEGER :28 4637 1643:d=5 hl=2 l= 10 cons: SEQUENCE 4638 1645:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4639 HA256 4640 1655:d=5 hl=2 l= 103 prim: OCTET STRING [HEX DUMP]:30 4641 6502310087389DFC090D8EDB6948FD6B7E5369A5D1EC8B7DB8676F935C9C 4642 6E79EC2727CCFFD8D5DBF937F70EC4E1BFB76ED343B3023063C8E9E69244 4643 8A1EC3D1D8996E03973AC28BEE3C49CD28FDF675A1867852861073244C89 4644 DBAEA8A90BCF35FF92BD43E9 4646 Authors' Addresses 4648 Max Pritikin 4649 Cisco 4651 Email: pritikin@cisco.com 4653 Michael C. Richardson 4654 Sandelman Software Works 4656 Email: mcr+ietf@sandelman.ca 4657 URI: http://www.sandelman.ca/ 4659 Michael H. Behringer 4661 Email: Michael.H.Behringer@gmail.com 4663 Steinthor Bjarnason 4664 Arbor Networks 4666 Email: sbjarnason@arbor.net 4668 Kent Watsen 4669 Juniper Networks 4671 Email: kwatsen@juniper.net