idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2019) is 1811 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 810, but not defined == Missing Reference: 'GRASP' is mentioned on line 1473, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1956, 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 2560, but not defined == Missing Reference: 'RFC2131' is mentioned on line 3550, but not defined == Missing Reference: 'HEX DUMP' is mentioned on line 4609, but not defined == Unused Reference: 'RFC5386' is defined on line 3329, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 3334, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 3338, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity' is defined on line 3414, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 3426, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 3457, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 3461, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 3471, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 3482, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 3506, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-19 -- 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-10 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-03 == 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: 7 errors (**), 0 flaws (~~), 22 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: November 12, 2019 Sandelman 6 M. Behringer 8 S. Bjarnason 9 Arbor Networks 10 K. Watsen 11 Juniper Networks 12 May 11, 2019 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-20 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 November 12, 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 . . . . . . . . . . . . . . . . . . . . . . . 26 101 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 29 102 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 30 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) . . . . . . . . 34 107 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 108 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 36 109 5.3. Registrar Authorization of 110 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 37 111 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 112 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39 113 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 40 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) . 41 118 5.5.5. MASA verification of pledge prior-signed-voucher- 119 request . . . . . . . . . . . . . . . . . . . . . . . 41 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 . . . . . . . . . . . 42 123 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45 124 5.6.2. Pledge authentication of provisional TLS connection . 45 125 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 46 126 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47 127 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48 128 5.8.2. Registrar audit log verification . . . . . . . . . . 49 129 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50 130 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51 131 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 132 5.9.3. EST Client Certificate Request . . . . . . . . . . . 52 133 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 134 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53 135 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 136 6. Reduced security operational modes . . . . . . . . . . . . . 54 137 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54 138 6.2. Pledge security reductions . . . . . . . . . . . . . . . 55 139 6.3. Registrar security reductions . . . . . . . . . . . . . . 55 140 6.4. MASA security reductions . . . . . . . . . . . . . . . . 56 141 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 142 7.1. Well-known EST registration . . . . . . . . . . . . . . . 57 143 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 57 144 7.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58 145 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58 146 7.5. MUD File Extension for the MASA . . . . . . . . . . . . . 58 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 . . . . . . . 60 152 9.3. Manufacturers and Used or Stolen Equipment . . . . . . . 62 153 9.4. Manufacturers and Grey market equipment . . . . . . . . . 63 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 . . . . . . . . . . . . . 66 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 . . . . . . . . . . . . . . . . . . 70 163 12.2. Informative References . . . . . . . . . . . . . . . . . 72 164 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76 165 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76 166 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76 167 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 76 168 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77 169 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 79 170 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 79 171 D.1.1. MASA key pair for voucher signatures . . . . . . . . 79 172 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 79 173 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 80 174 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 82 175 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 83 176 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 83 177 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 89 178 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 95 179 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 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. 796 As explained in Section 5.5 the Registrar MUST extract the serial- 797 number again itself from the pledge's TLS certificate. It can 798 consult the serial-number in the pledge-request if there are any 799 possible confusion about the source of the serial-number (hwSerialNum 800 vs serialNumber). 802 2.3.2. MASA URI extension 804 This docucment defines a new PKIX non-critical certificate extension 805 to carry the MASA URI. This extension is intended to be used in the 806 IDevID certificate. The URI is represented as described in 807 Section 7.4 of [RFC5280]. 809 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 810 URIs as specified in Section 3.1 of [RFC3987] before they are placed 811 in the certificate extension. The IRI provides the authority 812 information. The BRSKI "/.well-known" tree ([RFC5785]) is described 813 in Section 5. 815 As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in 816 this extension, including the scheme, iauthority, and ipath. As a 817 consideration to constrained systems, this MAY be reduced to only the 818 iauthority, in which case a scheme of "https://" and ipath of 819 "/.well-known/est" is to be assumed, as explained in section 820 Section 5. 822 The registrary can assume that only the iauthority is present in the 823 extension, if there are no slash ("/") characters in the extension. 825 Section 7.4 of [RFC5280] calls out various schemes that MUST be 826 supported, including ldap, http and ftp. However, the registrar MUST 827 use https for the BRSKI-MASA connection. 829 The new extension is identified as follows: 831 833 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 834 internet(1) security(5) mechanisms(5) pkix(7) 835 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 837 DEFINITIONS IMPLICIT TAGS ::= BEGIN 839 -- EXPORTS ALL -- 841 IMPORTS 842 EXTENSION 843 FROM PKIX-CommonTypes-2009 844 { iso(1) identified-organization(3) dod(6) internet(1) 845 security(5) mechanisms(5) pkix(7) id-mod(0) 846 id-mod-pkixCommon-02(57) } 848 id-pe 849 FROM PKIX1Explicit-2009 850 { iso(1) identified-organization(3) dod(6) internet(1) 851 security(5) mechanisms(5) pkix(7) id-mod(0) 852 id-mod-pkix1-explicit-02(51) } ; 853 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 854 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 855 IDENTIFIED BY id-pe-masa-url } 857 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 859 MASAURLSyntax ::= IA5String 861 END 863 865 The choice of id-pe is based on guidance found in Section 4.2.2 of 866 [RFC5280], "These extensions may be used to direct applications to 867 on-line information about the issuer or the subject". The MASA URL 868 is precisely that: online information about the particular subject. 870 2.4. Protocol Flow 872 A representative flow is shown in Figure 3: 874 +--------+ +---------+ +------------+ +------------+ 875 | Pledge | | Circuit | | Domain | | Vendor | 876 | | | Join | | Registrar | | Service | 877 | | | Proxy | | (JRC) | | (MASA) | 878 +--------+ +---------+ +------------+ +------------+ 879 | | | Internet | 880 [discover] | | | 881 |<-RFC4862 IPv6 addr | | | 882 |<-RFC3927 IPv4 addr | Appendix A | Legend | 883 |-------------------->| | C - circuit | 884 | optional: mDNS query| Appendix B | join proxy | 885 | RFC6763/RFC6762 | | P - provisional | 886 |<--------------------| | TLS connection | 887 | GRASP M_FLOOD | | | 888 | periodic broadcast| | | 889 [identity] | | | 890 |<------------------->C<----------------->| | 891 | TLS via the Join Proxy | | 892 |<--Registrar TLS server authentication---| | 893 [PROVISIONAL accept of server cert] | | 894 P---X.509 client authentication---------->| | 895 [request join] | | 896 P---Voucher Request(w/nonce for voucher)->| | 897 P /------------------- | | 898 P | [accept device?] | 899 P | [contact Vendor] | 900 P | |--Pledge ID-------->| 901 P | |--Domain ID-------->| 902 P | |--optional:nonce--->| 903 P optional: | [extract DomainID] 904 P can occur in advance | [update audit log] 905 P if nonceleess | | 906 P | |<- voucher ---------| 907 P \------------------- | w/nonce if provided| 908 P<------voucher---------------------------| | 909 [imprint] | | 910 |-------voucher status telemetry--------->| | 911 | |<-device audit log--| 912 | [verify audit log and voucher] | 913 |<--------------------------------------->| | 914 [enroll] | | 915 | Continue with RFC7030 enrollment | | 916 | using now bidirectionally authenticated | | 917 | TLS session. | | 918 [enrolled] | | 920 Figure 3 922 2.5. Architectural Components 924 2.5.1. Pledge 926 The pledge is the device that is attempting to join. Until the 927 pledge completes the enrollment process, it has link-local network 928 connectivity only to the proxy. 930 2.5.2. Join Proxy 932 The join proxy provides HTTPS connectivity between the pledge and the 933 registrar. A circuit proxy mechanism is described in Section 4. 934 Additional mechanisms, including a CoAP mechanism and a stateless 935 IPIP mechanism are the subject of future work. 937 2.5.3. Domain Registrar 939 The domain's registrar operates as the BRSKI-MASA client when 940 requesting vouchers from the MASA (see Section 5.4). The registrar 941 operates as the BRSKI-EST server when pledges request vouchers (see 942 Section 5.1). The registrar operates as the BRSKI-EST server 943 "Registration Authority" if the pledge requests an end entity 944 certificate over the BRSKI-EST connection (see Section 5.9). 946 The registrar uses an Implicit Trust Anchor database for 947 authenticating the BRSKI-MASA TLS connection MASA certificate. The 948 registrar uses a different Implicit Trust Anchor database for 949 authenticating the BRSKI-EST TLS connection pledge client 950 certificate. Configuration or distribution of these trust anchor 951 databases is out-of-scope of this specification. 953 2.5.4. Manufacturer Service 955 The Manufacturer Service provides two logically seperate functions: 956 the Manufacturer Authorized Signing Authority (MASA) described in 957 Section 5.5 and Section 5.6, and an ownership tracking/auditing 958 function described in Section 5.7 and Section 5.8. 960 2.5.5. Public Key Infrastructure (PKI) 962 The Public Key Infrastructure (PKI) administers certificates for the 963 domain of concerns, providing the trust anchor(s) for it and allowing 964 enrollment of pledges with domain certificates. 966 The voucher provides a method for the distribution of a single PKI 967 trust anchor (as the "pinned-domain-cert"). A distribution of the 968 full set of current trust anchors is possible using the optional EST 969 integration. 971 The domain's registrar acts as an [RFC5272] Registration Authority, 972 requesting certificates for pledges from the Key Infrastructure. 974 The expectations of the PKI are unchanged from EST [[RFC7030]]. This 975 document does not place any additional architectural requirements on 976 the Public Key Infrastructure. 978 2.6. Certificate Time Validation 980 2.6.1. Lack of realtime clock 982 Many devices when bootstrapping do not have knowledge of the current 983 time. Mechanisms such as Network Time Protocols cannot be secured 984 until bootstrapping is complete. Therefore bootstrapping is defined 985 in a method that does not require knowledge of the current time. A 986 pledge MAY ignore all time stamps in the voucher and in the 987 certificate validity periods if it does not know the current time. 989 The pledge is exposed to dates in the following five places: 990 registrar certificate notBefore, registrar certificiate notAfter, 991 voucher created-on, and voucher expires-on. Additionally, CMS 992 signatures contain a signingTime. 994 If the voucher contains a nonce then the pledge MUST confirm the 995 nonce matches the original pledge voucher-request. This ensures the 996 voucher is fresh. See Section 5.2. 998 2.6.2. Infinite Lifetime of IDevID 1000 [RFC5280] explains that long lived pledge certificates "SHOULD be 1001 assigned the GeneralizedTime value of 99991231235959Z". Registrars 1002 MUST support such lifetimes and SHOULD support ignoring pledge 1003 lifetimes if they did not follow the RFC5280 recommendations. 1005 For example, IDevID may have incorrect lifetime of N <= 3 years, 1006 rendering replacement pledges from storage useless after N years 1007 unless registrars support ignoring such a lifetime. 1009 2.7. Cloud Registrar 1011 There exist operationally open network wherein devices gain 1012 unauthenticated access to the internet at large. In these use cases 1013 the management domain for the device needs to be discovered within 1014 the larger internet. These are less likely within the anima scope 1015 but may be more important in the future. 1017 There are additionally some greenfield situations involving an 1018 entirely new installation where a device may have some kind of 1019 management uplink that it can use (such as via 3G network for 1020 instance). In such a future situation, the device might use this 1021 management interface to learn that it should configure itself to 1022 become the local registrar. 1024 In order to support these scenarios, the pledge MAY contact a well 1025 known URI of a cloud registrar if a local registrar cannot be 1026 discovered or if the pledge's target use cases do not include a local 1027 registrar. 1029 If the pledge uses a well known URI for contacting a cloud registrar 1030 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 1031 authenticate service as described in [RFC6125]. This is consistent 1032 with the human user configuration of an EST server URI in [RFC7030] 1033 which also depends on RFC6125. 1035 2.8. Determining the MASA to contact 1037 The registrar needs to be able to contact a MASA that is trusted by 1038 the pledge in order to obtain vouchers. There are three mechanisms 1039 described: 1041 The device's Initial Device Identifier (IDevID) will normally contain 1042 the MASA URL as detailed in Section 2.3. This is the RECOMMENDED 1043 mechanism. 1045 If the registrar is integrated with [I-D.ietf-opsawg-mud] and the 1046 pledge IDevID contains the id-pe-mud-url then the registrar MAY 1047 attempt to obtain the MASA URL from the MUD file. The MUD file 1048 extension for the MASA URL is defined in Appendix C. 1050 It can be operationally difficult to ensure the necessary X.509 1051 extensions are in the pledge's IDevID due to the difficulty of 1052 aligning current pledge manufacturing with software releases and 1053 development. As a final fallback the registrar MAY be manually 1054 configured or distributed with a MASA URL for each manufacturer. 1055 Note that the registrar can only select the configured MASA URL based 1056 on the trust anchor -- so manufacturers can only leverage this 1057 approach if they ensure a single MASA URL works for all pledge's 1058 associated with each trust anchor. 1060 3. Voucher-Request artifact 1062 Voucher-requests are how vouchers are requested. The semantics of 1063 the vouchers are described below, in the YANG model. 1065 A pledge forms the "pledge voucher-request" and submits it to the 1066 registrar. 1068 The registrar in turn forms the "registrar voucher-request", and 1069 submits it to the MASA. 1071 The "proximity-registrar-cert" leaf is used in the pledge voucher- 1072 requests. This provides a method for the pledge to assert the 1073 registrar's proximity. 1075 The "prior-signed-voucher-request" leaf is used in registrar voucher- 1076 requests. If present, it is the signed pledge voucher-request. This 1077 provides a method for the registrar to forward the pledge's signed 1078 request to the MASA. This completes transmission of the signed 1079 "proximity-registrar-cert" leaf. 1081 Unless otherwise signaled (outside the voucher-request artifact), the 1082 signing structure is as defined for vouchers, see [RFC8366]. 1084 3.1. Nonceless Voucher Requests 1086 A registrar MAY also retrieve nonceless vouchers by sending nonceless 1087 voucher-requests to the MASA in order to obtain vouchers for use when 1088 the registrar does not have connectivity to the MASA. No "prior- 1089 signed-voucher-request" leaf would be included. The registrar will 1090 also need to know the serial number of the pledge. This document 1091 does not provide a mechanism for the registrar to learn that in an 1092 automated fashion. Typically this will be done via scanning of bar- 1093 code or QR-code on packaging, or via some sales channel integration. 1095 3.2. Tree Diagram 1097 The following tree diagram illustrates a high-level view of a 1098 voucher-request document. The voucher-request builds upon the 1099 voucher artifact described in [RFC8366]. The tree diagram is 1100 described in [RFC8340]. Each node in the diagram is fully described 1101 by the YANG module in Section 3.4. Please review the YANG module for 1102 a detailed description of the voucher-request format. 1104 module: ietf-voucher-request 1106 grouping voucher-request-grouping 1107 +---- voucher 1108 +---- created-on? yang:date-and-time 1109 +---- expires-on? yang:date-and-time 1110 +---- assertion? enumeration 1111 +---- serial-number string 1112 +---- idevid-issuer? binary 1113 +---- pinned-domain-cert? binary 1114 +---- domain-cert-revocation-checks? boolean 1115 +---- nonce? binary 1116 +---- last-renewal-date? yang:date-and-time 1117 +---- prior-signed-voucher-request? binary 1118 +---- proximity-registrar-cert? binary 1120 3.3. Examples 1122 This section provides voucher-request examples for illustration 1123 purposes. For detailed examples, see Appendix D.2. These examples 1124 conform to the encoding rules defined in [RFC7951]. 1126 Example (1) The following example illustrates a pledge voucher- 1127 request. The assertion leaf is indicated as 'proximity' 1128 and the registrar's TLS server certificate is included 1129 in the 'proximity-registrar-cert' leaf. See 1130 Section 5.2. 1132 { 1133 "ietf-voucher-request:voucher": { 1134 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1135 "created-on": "2017-01-01T00:00:00.000Z", 1136 "proximity-registrar-cert": "base64encodedvalue==" 1137 } 1138 } 1140 Example (2) The following example illustrates a registrar voucher- 1141 request. The 'prior-signed-voucher-request' leaf is 1142 populated with the pledge's voucher-request (such as the 1143 prior example). The pledge's voucher-request is a 1144 binary object. In the JSON encoding used here it must 1145 be base64 encoded. The nonce, created-on and assertion 1146 is carried forward. The serial-number is extracted from 1147 the pledge's Client Certificate from the TLS connection. 1148 See Section 5.5. 1150 { 1151 "ietf-voucher-request:voucher": { 1152 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1153 "created-on": "2017-01-01T00:00:02.000Z", 1154 "idevid-issuer": "base64encodedvalue==" 1155 "serial-number": "JADA123456789" 1156 "prior-signed-voucher-request": "base64encodedvalue==" 1157 } 1158 } 1160 Example (3) The following example illustrates a registrar voucher- 1161 request. The 'prior-signed-voucher-request' leaf is not 1162 populated with the pledge's voucher-request nor is the 1163 nonce leaf. This form might be used by a registrar 1164 requesting a voucher when the pledge can not communicate 1165 with the registrar (such as when it is powered down, or 1166 still in packaging), and therefore could not submit a 1167 nonce. This scenario is most useful when the registrar 1168 is aware that it will not be able to reach the MASA 1169 during deployment. See Section 5.5. 1171 { 1172 "ietf-voucher-request:voucher": { 1173 "created-on": "2017-01-01T00:00:02.000Z", 1174 "idevid-issuer": "base64encodedvalue==" 1175 "serial-number": "JADA123456789" 1176 } 1177 } 1179 3.4. YANG Module 1181 Following is a YANG [RFC7950] module formally extending the [RFC8366] 1182 voucher into a voucher-request. 1184 file "ietf-voucher-request@2018-02-14.yang" 1185 module ietf-voucher-request { 1186 yang-version 1.1; 1188 namespace 1189 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 1190 prefix "vch"; 1192 import ietf-restconf { 1193 prefix rc; 1194 description "This import statement is only present to access 1195 the yang-data extension defined in RFC 8040."; 1196 reference "RFC 8040: RESTCONF Protocol"; 1197 } 1198 import ietf-voucher { 1199 prefix v; 1200 description "This module defines the format for a voucher, 1201 which is produced by a pledge's manufacturer or 1202 delegate (MASA) to securely assign a pledge to 1203 an 'owner', so that the pledge may establish a secure 1204 conn ection to the owner's network infrastructure"; 1206 reference "RFC YYYY: Voucher Profile for Bootstrapping Protocols"; 1207 } 1209 organization 1210 "IETF ANIMA Working Group"; 1212 contact 1213 "WG Web: 1214 WG List: 1215 Author: Kent Watsen 1216 1217 Author: Max Pritikin 1218 1219 Author: Michael Richardson 1220 1221 Author: Toerless Eckert 1222 "; 1224 description 1225 "This module defines the format for a voucher request. 1226 It is a superset of the voucher itself. 1227 It provides content to the MASA for consideration 1228 during a voucher request. 1230 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 1231 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 1232 the module text are to be interpreted as described in RFC 2119. 1234 Copyright (c) 2017 IETF Trust and the persons identified as 1235 authors of the code. All rights reserved. 1237 Redistribution and use in source and binary forms, with or without 1238 modification, is permitted pursuant to, and subject to the license 1239 terms contained in, the Simplified BSD License set forth in Section 1240 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1241 (http://trustee.ietf.org/license-info). 1243 This version of this YANG module is part of RFC XXXX; see the RFC 1244 itself for full legal notices."; 1246 revision "2018-02-14" { 1247 description 1248 "Initial version"; 1249 reference 1250 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 1251 } 1253 // Top-level statement 1254 rc:yang-data voucher-request-artifact { 1255 uses voucher-request-grouping; 1256 } 1258 // Grouping defined for future usage 1259 grouping voucher-request-grouping { 1260 description 1261 "Grouping to allow reuse/extensions in future work."; 1263 uses v:voucher-artifact-grouping { 1264 refine "voucher/created-on" { 1265 mandatory false; 1266 } 1268 refine "voucher/pinned-domain-cert" { 1269 mandatory false; 1270 } 1272 refine "voucher/domain-cert-revocation-checks" { 1273 description "The domain-cert-revocation-checks field 1274 is not valid in a voucher request, and 1275 any occurance MUST be ignored"; 1276 } 1278 refine "voucher/assertion" { 1279 mandatory false; 1280 description "Any assertion included in voucher 1281 requests SHOULD be ignored by the MASA."; 1282 } 1284 augment "voucher" { 1285 description 1286 "Adds leaf nodes appropriate for requesting vouchers."; 1288 leaf prior-signed-voucher-request { 1289 type binary; 1290 description 1291 "If it is necessary to change a voucher, or re-sign and 1292 forward a voucher that was previously provided along a 1293 protocol path, then the previously signed voucher SHOULD be 1294 included in this field. 1296 For example, a pledge might sign a voucher request 1297 with a proximity-registrar-cert, and the registrar 1298 then includes it in the prior-signed-voucher-request field. 1299 This is a simple mechanism for a chain of trusted 1300 parties to change a voucher request, while 1301 maintaining the prior signature information. 1303 The Registrar and MASA MAY examine the prior signed 1304 voucher information for the 1305 purposes of policy decisions. For example this information 1306 could be useful to a MASA to determine that both pledge and 1307 registrar agree on proximity assertions. The MASA SHOULD 1308 remove all prior-signed-voucher-request information when 1309 signing a voucher for imprinting so as to minimize the 1310 final voucher size."; 1311 } 1313 leaf proximity-registrar-cert { 1314 type binary; 1315 description 1316 "An X.509 v3 certificate structure as specified by RFC 5280, 1317 Section 4 encoded using the ASN.1 distinguished encoding 1318 rules (DER), as specified in ITU-T X.690. 1320 The first certificate in the Registrar TLS server 1321 certificate_list sequence (see [RFC5246]) presented by 1322 the Registrar to the Pledge. This MUST be populated in a 1323 Pledge's voucher request if a proximity assertion is 1324 requested."; 1325 } 1326 } 1327 } 1328 } 1330 } 1332 1334 4. Proxying details (Pledge - Proxy - Registrar) 1336 The role of the proxy is to facilitate communications. The proxy 1337 forwards packets between the pledge and a registrar that has been 1338 provisioned to the proxy via GRASP discovery. 1340 This section defines a stateful proxy mechanism which is refered to 1341 as a "circuit" proxy. 1343 The proxy does not terminate the TLS handshake: it passes streams of 1344 bytes onward without examination. A proxy MUST NOT assume any 1345 specific TLS version. 1347 A Registrar can directly provide the proxy announcements described 1348 below, in which case the announced port can point directly to the 1349 Registrar itself. In this scenario the pledge is unaware that there 1350 is no proxing occuring. This is useful for Registrars servicing 1351 pledges on directly connected networks. 1353 As a result of the proxy Discovery process in Section 4.1.1, the port 1354 number exposed by the proxy does not need to be well known, or 1355 require an IANA allocation. 1357 During the discovery of the Registrar by the Join Proxy, the Join 1358 Proxy will also learn which kinds of proxy mechanisms are available. 1359 This will allow the Join Proxy to use the lowest impact mechanism 1360 which the Join Proxy and Registrar have in common. 1362 In order to permit the proxy functionality to be implemented on the 1363 maximum variety of devices the chosen mechanism SHOULD use the 1364 minimum amount of state on the proxy device. While many devices in 1365 the ANIMA target space will be rather large routers, the proxy 1366 function is likely to be implemented in the control plane CPU of such 1367 a device, with available capabilities for the proxy function similar 1368 to many class 2 IoT devices. 1370 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1371 more extensive analysis and background of the alternative proxy 1372 methods. 1374 4.1. Pledge discovery of Proxy 1376 The result of discovery is a logical communication with a registrar, 1377 through a proxy. The proxy is transparent to the pledge. The 1378 communication between the pledge is over IPv6 Link-Local addresses. 1380 To discover the proxy the pledge performs the following actions: 1382 1. MUST: Obtains a local address using IPv6 methods as described in 1383 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1384 [RFC4941] temporary addresses is encouraged. To limit pervasive 1385 monitoring ( [RFC7258]), a new temporary address MAY use a short 1386 lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). 1387 Pledges will generally prefer use of IPv6 Link-Local addresses, 1388 and discovery of proxy will be by Link-Local mechanisms. IPv4 1389 methods are described in Appendix A 1391 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1392 announcements of the objective: "AN_Proxy". See section 1393 Section 4.1.1 for the details of the objective. The pledge MAY 1394 listen concurrently for other sources of information, see 1395 Appendix B. 1397 Once a proxy is discovered the pledge communicates with a registrar 1398 through the proxy using the bootstrapping protocol defined in 1399 Section 5. 1401 While the GRASP M_FLOOD mechanism is passive for the pledge, the 1402 optional other methods (mDNS, and IPv4 methods) are active. The 1403 pledge SHOULD run those methods in parallel with listening to for the 1404 M_FLOOD. The active methods SHOULD exponentially back-off to a 1405 maximum of one hour to avoid overloading the network with discovery 1406 attempts. Detection of change of physical link status (ethernet 1407 carrier for instance) SHOULD reset the exponential back off. 1409 The pledge could discover more than one proxy on a given physical 1410 interface. The pledge can have a multitude of physical interfaces as 1411 well: a layer-2/3 ethernet switch may have hundreds of physical 1412 ports. 1414 Each possible proxy offer SHOULD be attempted up to the point where a 1415 voucher is received: while there are many ways in which the attempt 1416 may fail, it does not succeed until the voucher has been validated. 1418 The connection attempts via a single proxy SHOULD exponentially back- 1419 off to a maximum of one hour to avoid overloading the network 1420 infrastructure. The back-off timer for each MUST be independent of 1421 other connection attempts. 1423 Connection attempts SHOULD be run in parallel to avoid head of queue 1424 problems wherein an attacker running a fake proxy or registrar could 1425 perform protocol actions intentionally slowly. The pledge SHOULD 1426 continue to listen to for additional GRASP M_FLOOD messages during 1427 the connection attempts. 1429 Once a connection to a registrar is established (e.g. establishment 1430 of a TLS session key) there are expectations of more timely 1431 responses, see Section 5.2. 1433 Once all discovered services are attempted (assuming that none 1434 succeeded) the device MUST return to listening for GRASP M_FLOOD. It 1435 SHOULD periodically retry the manufacturer specific mechanisms. The 1436 pledge MAY prioritize selection order as appropriate for the 1437 anticipated environment. 1439 4.1.1. Proxy GRASP announcements 1441 A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. 1442 This announcement can be within the same message as the ACP 1443 announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. 1444 The M_FLOOD is formatted as follows: 1446 [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, 1447 ["AN_Proxy", 4, 1, ""], 1448 [O_IPv6_LOCATOR, 1449 h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] 1451 Figure 6b: Proxy Discovery 1453 The formal CDDL [I-D.ietf-cbor-cddl] definition is: 1455 flood-message = [M_FLOOD, session-id, initiator, ttl, 1456 +[objective, (locator-option / [])]] 1458 objective = ["AN_Proxy", objective-flags, loop-count, 1459 objective-value] 1461 ttl = 180000 ; 180,000 ms (3 minutes) 1462 initiator = ACP address to contact Registrar 1463 objective-flags = sync-only ; as in GRASP spec 1464 sync-only = 4 ; M_FLOOD only requires synchronization 1465 loop-count = 1 ; one hop only 1466 objective-value = any ; none 1468 locator-option = [ O_IPv6_LOCATOR, ipv6-address, 1469 transport-proto, port-number ] 1470 ipv6-address = the v6 LL of the Proxy 1471 $transport-proto /= IPPROTO_TCP ; note this can be any value from the 1472 ; IANA protocol registry, as per 1473 ; [GRASP] section 2.9.5.1, note 3. 1474 port-number = selected by Proxy 1476 Figure 6c: AN_Proxy CDDL 1478 On a small network the Registrar MAY include the GRASP M_FLOOD 1479 announcements to locally connected networks. 1481 The $transport-proto above indicates the method that the pledge- 1482 proxy-registrar will use. The TCP method described here is 1483 mandatory, and other proxy methods, such as CoAP methods not defined 1484 in this document are optional. Other methods MUST NOT be enabled 1485 unless the Join Registrar ASA indicates support for them in it's own 1486 announcement. 1488 4.2. CoAP connection to Registrar 1490 The use of CoAP to connect from pledge to registrar is out of scope 1491 for this document, and is described in future work. See 1492 [I-D.ietf-anima-constrained-voucher]. 1494 4.3. Proxy discovery and communication of Registrar 1496 The registrar SHOULD announce itself so that proxies can find it and 1497 determine what kind of connections can be terminated. 1499 The registrar announces itself using ACP instance of GRASP using 1500 M_FLOOD messages. ANI proxies MUST support GRASP discovery of 1501 registrars. 1503 The M_FLOOD is formatted as follows: 1505 [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, 1506 ["AN_join_registrar", 4, 255, "EST-TLS"], 1507 [O_IPv6_LOCATOR, 1508 h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 80]] 1510 Figure 7a: Registrar Discovery 1512 The formal CDDL definition is: 1514 flood-message = [M_FLOOD, session-id, initiator, ttl, 1515 +[objective, (locator-option / [])]] 1517 objective = ["AN_join_registrar", objective-flags, loop-count, 1518 objective-value] 1520 initiator = ACP address to contact Registrar 1521 objective-flags = sync-only ; as in GRASP spec 1522 sync-only = 4 ; M_FLOOD only requires synchronization 1523 loop-count = 255 ; mandatory maximum 1524 objective-value = text ; name of the (list of) of supported 1525 ; protocols: "EST-TLS" for RFC7030. 1527 Figure 7: AN_join_registrar CDDL 1529 The M_FLOOD message MUST be sent periodically. The period is subject 1530 to network administrator policy (EST server configuration). It must 1531 be sufficiently low that the aggregate amount of periodic M_FLOODs 1532 from all EST servers causes negligible traffic across the ACP. 1534 Here are some examples of locators for illustrative purposes. Only 1535 the first one ($transport-protocol = 6, TCP) is defined in this 1536 document and is mandatory to implement. 1538 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1539 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1540 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1542 A protocol of 6 indicates that TCP proxying on the indicated port is 1543 desired. 1545 Registrars MUST announce the set of protocols that they support. 1546 They MUST support TCP traffic. 1548 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1550 Registrars MUST support ANI TLS circuit proxy and therefore BRSKI 1551 across HTTPS/TLS native across the ACP. 1553 In the ANI, the Autonomic Control Plane (ACP) secured instance of 1554 GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI 1555 registrar ACP addresses and ports by ANI proxies. The TCP leg of the 1556 proxy connection between ANI proxy and ANI registrar therefore also 1557 runs across the ACP. 1559 5. Protocol Details (Pledge - Registrar - MASA) 1561 The pledge MUST initiate BRSKI after boot if it is unconfigured. The 1562 pledge MUST NOT automatically initiate BRSKI if it has been 1563 configured or is in the process of being configured. 1565 BRSKI is described as extensions to EST [RFC7030]. The goal of these 1566 extensions is to reduce the number of TLS connections and crypto 1567 operations required on the pledge. The registrar implements the 1568 BRSKI REST interface within the same "/.well-known" URI tree as the 1569 existing EST URIs as described in EST [RFC7030] section 3.2.2. The 1570 communication channel between the pledge and the registrar is 1571 referred to as "BRSKI-EST" (see Figure 1). 1573 The communication channel between the registrar and MASA is similarly 1574 described as extensions to EST within the same "/.well-known" tree. 1575 For clarity this channel is referred to as "BRSKI-MASA". (See 1576 Figure 1). 1578 MASA URI is "https://" iauthority "/.well-known/est". 1580 BRSKI uses existing CMS message formats for existing EST operations. 1581 BRSKI uses JSON [RFC7159] for all new operations defined here, and 1582 voucher formats. 1584 While EST section 3.2 does not insist upon use of HTTP 1.1 persistent 1585 connections, BRSKI-EST connections SHOULD use persistent connections. 1586 The intention of this guidance is to ensure the provisional TLS state 1587 occurs only once, and that the subsequent resolution of the provision 1588 state is not subject to a MITM attack during a critical phase. 1590 Summarized automation extensions for the BRSKI-EST flow are: 1592 o The pledge either attempts concurrent connections via each 1593 discovered proxy, or it times out quickly and tries connections in 1594 series, as explained at the end of Section 5.1. 1596 o The pledge provisionally accepts the registrar certificate during 1597 the TLS handshake as detailed in Section 5.1. 1599 o The pledge requests and validates a voucher using the new REST 1600 calls described below. 1602 o The pledge completes authentication of the server certificate as 1603 detailed in Section 5.6.1. This moves the BRSKI-EST TLS 1604 connection out of the provisional state. 1606 o Mandatory boostrap steps conclude with voucher status telemetry 1607 (see Section 5.7). 1609 The BRSKI-EST TLS connection can now be used for EST enrollment. 1611 The extensions for a registrar (equivalent to EST server) are: 1613 o Client authentication is automated using Initial Device Identity 1614 (IDevID) as per the EST certificate based client authentication. 1615 The subject field's DN encoding MUST include the "serialNumber" 1616 attribute with the device's unique serial number. 1618 o In the language of [RFC6125] this provides for a SERIALNUM-ID 1619 category of identifier that can be included in a certificate and 1620 therefore that can also be used for matching purposes. The 1621 SERIALNUM-ID whitelist is collated according to manufacturer trust 1622 anchor since serial numbers are not globally unique. 1624 o The registrar requests and validates the voucher from the MASA. 1626 o The registrar forwards the voucher to the pledge when requested. 1628 o The registrar performs log verifications in addition to local 1629 authorization checks before accepting optional pledge device 1630 enrollment requests. 1632 5.1. BRSKI-EST TLS establishment details 1634 The pledge establishes the TLS connection with the registrar through 1635 the circuit proxy (see Section 4) but the TLS handshake is with the 1636 registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST 1637 registrar is the TLS server. All security associations established 1638 are between the pledge and the registrar regardless of proxy 1639 operations. 1641 Establishment of the BRSKI-EST TLS connection is as specified in EST 1642 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1643 [RFC7030] wherein the client is authenticated with the IDevID 1644 certificate, and the EST server (the registrar) is provisionally 1645 authenticated with an unverified server certificate. 1647 The pledge maintains a security paranoia concerning the provisional 1648 state, and all data received, until a voucher is received and 1649 verified as specified in Section 5.6.1 1651 A Pledge that can connect to multiple registries concurrently, SHOULD 1652 do so. Some devices may be unable to do so for lack of threading, or 1653 resource issues. Concurrent connections defeat atttempts by a 1654 malicious proxy from causing a TCP Slowloris-like attack (see 1655 [slowloris]). 1657 A pledge that can not maintain as many connections as there are 1658 eligible proxies. If no connection is making process after 5 seconds 1659 then the pledge SHOULD drop the oldest connection and go on to a 1660 different proxy: the proxy that has been communicated with least 1661 recently. If there were no other proxies discovered, the pledge MAY 1662 continue to wait, as long as it is concurrently listening for new 1663 proxy announcements. 1665 5.2. Pledge Requests Voucher from the Registrar 1667 When the pledge bootstraps it makes a request for a voucher from a 1668 registrar. 1670 This is done with an HTTPS POST using the operation path value of 1671 "/.well-known/est/requestvoucher". 1673 The pledge voucher-request Content-Type is: 1675 application/voucher-cms+json The request is a "YANG-defined JSON 1676 document that has been signed using a CMS structure" as described 1677 in Section 3 using the JSON encoding described in [RFC7951]. This 1678 voucher media type is defined in [RFC8366] and is also used for 1679 the pledge voucher-request. The pledge SHOULD sign the request 1680 using the Section 2.3 credential. 1682 Registrar impementations SHOULD anticipate future media types but of 1683 course will simply fail the request if those types are not yet known. 1685 The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header 1686 indicating the acceptable media type for the voucher response. The 1687 "application/voucher-cms+json" media type is defined in [RFC8366] but 1688 constrained voucher formats are expected in the future. Registrar's 1689 and MASA's are expected to be flexible in what they accept. 1691 The pledge populates the voucher-request fields as follows: 1693 created-on: Pledges that have a realtime clock are RECOMMENDED to 1694 populate this field. This provides additional information to the 1695 MASA. 1697 nonce: The pledge voucher-request MUST contain a cryptographically 1698 strong random or pseudo-random number nonce. (see [RFC4086]) Doing 1699 so ensures Section 2.6.1 functionality. The nonce MUST NOT be 1700 reused for multiple bootstrapping attempts. (The registrar 1701 voucher-request MAY omit the nonce as per Section 3.1) 1703 proximity-registrar-cert: In a pledge voucher-request this is the 1704 first certificate in the TLS server 'certificate_list' sequence 1705 (see [RFC5246]) presented by the registrar to the pledge. This 1706 MUST be populated in a pledge voucher-request if the "proximity" 1707 assertion is populated. 1709 All other fields MAY be omitted in the pledge voucher-request. 1711 An example JSON payload of a pledge voucher-request is in Section 3.3 1712 Example 1. 1714 The registrar validates the client identity as described in EST 1715 [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' 1716 assertion and associated 'proximity-registrar-cert' are correct. 1718 5.3. Registrar Authorization of Pledge 1720 In a fully automated network all devices must be securely identified 1721 and authorized to join the domain. 1723 A Registrar accepts or declines a request to join the domain, based 1724 on the authenticated identity presented. Automated acceptance 1725 criteria include: 1727 o allow any device of a specific type (as determined by the X.509 1728 IDevID), 1730 o allow any device from a specific vendor (as determined by the 1731 X.509 IDevID), 1733 o allow a specific device from a vendor (as determined by the X.509 1734 IDevID) against a domain white list. (The mechanism for checking 1735 a shared white list potentially used by multiple Registrars is out 1736 of scope). 1738 If these validations fail the registrar SHOULD respond with an 1739 appropriate HTTP error code. 1741 If authorization is successful the registrar obtains a voucher from 1742 the MASA service (see Section 5.5) and returns that MASA signed 1743 voucher to the pledge as described in Section 5.6. 1745 5.4. BRSKI-MASA TLS establishment details 1747 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1748 appropriate for HTTPS REST interfaces. The registrar initiates the 1749 connection and uses the MASA URL obtained as described in Section 2.8 1750 for [RFC6125] authentication of the MASA. 1752 The primary method of registrar "authentication" by the MASA is 1753 detailed in Section 5.5. As detailed in Section 10 the MASA might 1754 find it necessary to request additional registrar authentication. 1756 The MASA and the registrars SHOULD be prepared to support TLS client 1757 certificate authentication and/or HTTP Basic or Digest authentication 1758 as described in [RFC7030] for EST clients. This connection MAY also 1759 have no client authentication at all (Section 6.4) 1761 The authentication of the BRSKI-MASA connection does not affect the 1762 voucher-request process, as voucher-requests are already signed by 1763 the registrar. Instead, this authentication provides access control 1764 to the audit log. 1766 Implementors are advised that contacting the MASA is to establish a 1767 secured REST connection with a web service and that there are a 1768 number of authentication models being explored within the industry. 1769 Registrars are RECOMMENDED to fail gracefully and generate useful 1770 administrative notifications or logs in the advent of unexpected HTTP 1771 401 (Unauthorized) responses from the MASA. 1773 5.5. Registrar Requests Voucher from MASA 1775 When a registrar receives a pledge voucher-request it in turn submits 1776 a registrar voucher-request to the MASA service via an HTTPS RESTful 1777 interface ([RFC7231]). 1779 This is done with an HTTP POST using the operation path value of 1780 "/.well-known/est/requestvoucher". 1782 The voucher media type "application/voucher-cms+json" is defined in 1783 [RFC8366] and is also used for the registrar voucher-request. It is 1784 a JSON document that has been signed using a CMS structure. The 1785 registrar MUST sign the registrar voucher-request. The entire 1786 registrar certificate chain, up to and including the Domain CA, MUST 1787 be included in the CMS structure. 1789 MASA impementations SHOULD anticipate future media types but of 1790 course will simply fail the request if those types are not yet known. 1792 The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" 1793 header indicating the response media types that are acceptable. This 1794 list SHOULD be the entire list presented to the Registrar in the 1795 Pledge's original request (see Section 5.2) but MAY be a subset. 1796 MASA's are expected to be flexible in what they accept. 1798 The registrar populates the voucher-request fields as follows: 1800 created-on: Registrars are RECOMMENDED to populate this field. This 1801 provides additional information to the MASA. 1803 nonce: This is the value from the pledge voucher-request. The 1804 registrar voucher-request MAY omit the nonce as per Section 3.1) 1806 serial-number: The serial number of the pledge the registrar would 1807 like a voucher for. The registrar determines this value by 1808 parsing the authenticated pledge IDevID certificate. See 1809 Section 2.3. The registrar MUST verify that the serial number 1810 field it parsed matches the serial number field the pledge 1811 provided in its voucher-request. This provides a sanity check 1812 useful for detecting error conditions and logging. The registrar 1813 MUST NOT simply copy the serial number field from a pledge voucher 1814 request as that field is claimed but not certified. 1816 idevid-issuer: The idevid-issuer value from the pledge certificate 1817 is included to ensure a statistically unique identity. 1819 prior-signed-voucher-request: The signed pledge voucher-request 1820 SHOULD be included in the registrar voucher-request. (NOTE: what 1821 is included is the complete pledge voucher-request, inclusive of 1822 the 'assertion', 'proximity-registrar-cert', etc wrapped by the 1823 pledge's original signature). If a signed voucher-request was not 1824 recieved from the pledge then this leaf is omitted from the 1825 registrar voucher request. 1827 A nonceless registrar voucher-request MAY be submitted to the MASA. 1828 Doing so allows the registrar to request a voucher when the pledge is 1829 offline, or when the registrar anticipates not being able to connect 1830 to the MASA while the pledge is being deployed. Some use cases 1831 require the registrar to learn the appropriate IDevID SerialNumber 1832 field and appropriate 'Accept header' field values from the physical 1833 device labeling or from the sales channel (out-of-scope for this 1834 document). 1836 All other fields MAY be omitted in the registrar voucher-request. 1838 Example JSON payloads of registrar voucher-requests are in 1839 Section 3.3 Examples 2 through 4. 1841 The MASA verifies that the registrar voucher-request is internally 1842 consistent but does not necessarily authenticate the registrar 1843 certificate since the registrar is not known to the MASA in advance. 1844 The MASA performs the actions and validation checks described in the 1845 following sub-sections before issuing a voucher. 1847 5.5.1. MASA renewal of expired vouchers 1849 As described in [RFC8366] vouchers are normally short lived to avoid 1850 revocation issues. If the request is for a previous (expired) 1851 voucher using the same registrar then the request for a renewed 1852 voucher SHOULD be automatically authorized. The MASA has sufficient 1853 information to determine this by examining the request, the registrar 1854 authentication, and the existing audit log. The issuance of a 1855 renewed voucher is logged as detailed in Section 5.6. 1857 To inform the MASA that existing vouchers are not to be renewed one 1858 can update or revoke the registrar credentials used to authorize the 1859 request (see Section 5.5.3 and Section 5.5.4). More flexible methods 1860 will likely involve sales channel integration and authorizations 1861 (details are out-of-scope of this document). 1863 5.5.2. MASA verification of voucher-request signature consistency 1865 The MASA MUST verify that the registrar voucher-request is signed by 1866 a registrar. This is confirmed by verifying that the id-kp-cmcRA 1867 extended key usage extension field (as detailed in EST RFC7030 1868 section 3.6.1) exists in the certificate of the entity that signed 1869 the registrar voucher-request. This verification is only a 1870 consistency check that the unauthenticated domain CA intended the 1871 voucher-request signer to be a registrar. Performing this check 1872 provides value to the domain PKI by assuring the domain administrator 1873 that the MASA service will only respect claims from authorized 1874 Registration Authorities of the domain. 1876 The MASA verifies that the domain CA certificate is included in the 1877 CMS structure as detailed in Section 5.5. 1879 5.5.3. MASA authentication of registrar (certificate) 1881 If a nonceless voucher-request is submitted the MASA MUST 1882 authenticate the registrar as described in either EST [RFC7030] 1883 section 3.2, section 3.3, or by validating the registrar's 1884 certificate used to sign the registrar voucher-request. Any of these 1885 methods reduce the risk of DDoS attacks and provide an authenticated 1886 identity as an input to sales channel integration and authorizations 1887 (details are out-of-scope of this document). 1889 In the nonced case, validation of the registrar MAY be omitted if the 1890 device policy is to accept audit-only vouchers. 1892 5.5.4. MASA revocation checking of registrar (certificate) 1894 As noted in Section 5.5.3 the MASA performs registrar authentication 1895 in a subset of situations (e.g. nonceless voucher requests). Normal 1896 PKIX revocation checking is assumed during either EST client 1897 authentication or voucher-request signature validation. Similarly, 1898 as noted in Section 5.5.2, the MASA performs normal PKIX revocation 1899 checking during signature consistency checks (a signature by a 1900 registrar certificate that has been revoked is an inconsistency). 1902 5.5.5. MASA verification of pledge prior-signed-voucher-request 1904 The MASA MAY verify that the registrar voucher-request includes the 1905 'prior-signed-voucher-request' field. If so the prior-signed- 1906 voucher-request MUST include a 'proximity-registrar-cert' that is 1907 consistent with the certificate used to sign the registrar voucher- 1908 request. Additionally the voucher-request serial-number leaf MUST 1909 match the pledge serial-number that the MASA extracts from the 1910 signing certificate of the prior-signed-voucher-request. The MASA is 1911 aware of which pledges support signing of their voucher requests and 1912 can use this information to confirm proximity of the pledge with the 1913 registrar, thus ensuring that the BRSKI-EST TLS connection has no 1914 man-in-the-middle. 1916 If these checks succeed the MASA updates the voucher and audit log 1917 assertion leafs with the "proximity" assertion. 1919 5.5.6. MASA pinning of registrar 1921 The registrar's certificate chain is extracted from the signature 1922 method. The chain includes the domain CA certificate as specified in 1923 Section 5.5. This certificate is used to populate the "pinned- 1924 domain-cert" of the voucher being issued. The domainID (e.g., hash 1925 of the root public key) is determined from the pinned-domain-cert and 1926 is used to update the audit log. 1928 5.5.7. MASA nonce handling 1930 The MASA does not verify the nonce itself. If the registrar voucher- 1931 request contains a nonce, and the prior-signed-voucher-request is 1932 exist, then the MASA MUST verify that the nonce is consistent. 1933 (Recall from above that the voucher-request might not contain a 1934 nonce, see Section 5.5 and Section 5.5.3). 1936 The MASA MUST use the nonce from the registrar voucher-request for 1937 the resulting voucher and audit log. The prior-signed-voucher- 1938 request nonce is ignored during this operation. 1940 5.6. MASA and Registrar Voucher Response 1942 The MASA voucher response to the registrar is forwarded without 1943 changes to the pledge; therefore this section applies to both the 1944 MASA and the registrar. The HTTP signaling described applies to both 1945 the MASA and registrar responses. A registrar either caches prior 1946 MASA responses or dynamically requests a new voucher based on local 1947 policy (it does not generate or sign a voucher). Registrar 1948 evaluation of the voucher itself is purely for transparency and audit 1949 purposes to further inform log verification (see Section 5.8.2) and 1950 therefore a registrar could accept future voucher formats that are 1951 opaque to the registrar. 1953 If the voucher-request is successful, the server (MASA responding to 1954 registrar or registrar responding to pledge) response MUST contain an 1955 HTTP 200 response code. The server MUST answer with a suitable 4xx 1956 or 5xx HTTP [RFC2616] error code when a problem occurs. In this 1957 case, the response data from the MASA MUST be a plaintext human- 1958 readable (ASCII, English) error message containing explanatory 1959 information describing why the request was rejected. 1961 The registrar MAY respond with an HTTP 202 ("the request has been 1962 accepted for processing, but the processing has not been completed") 1963 as described in EST [RFC7030] section 4.2.3 wherein the client "MUST 1964 wait at least the specified 'Retry-After' time before repeating the 1965 same request". (see [RFC7231] section 6.6.4) The pledge is 1966 RECOMMENDED to provide local feedback (blinked LED etc) during this 1967 wait cycle if mechanisms for this are available. To prevent an 1968 attacker registrar from significantly delaying bootstrapping the 1969 pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the 1970 pledge would keep track of the appropriate Retry-After header values 1971 for any number of outstanding registrars but this would involve a 1972 state table on the pledge. Instead the pledge MAY ignore the exact 1973 Retry-After value in favor of a single hard coded value (a registrar 1974 that is unable to complete the transaction after the first 60 seconds 1975 has another chance a minute later). A pledge SHOULD only maintain a 1976 202 retry-state for up to 4 days, which is longer than a long 1977 weekend, after which time the enrollment attempt fails and the pledge 1978 returns to discovery state. 1980 In order to avoid infinite redirect loops, which a malicious 1981 registrar might do in order to keep the pledge from discovering the 1982 correct registrar, the pledge MUST NOT follow more than one 1983 redirection (3xx code) to another web origins. EST supports 1984 redirection but requires user input; this change allows the pledge to 1985 follow a single redirection without a user interaction. 1987 A 403 (Forbidden) response is appropriate if the voucher-request is 1988 not signed correctly, stale, or if the pledge has another outstanding 1989 voucher that cannot be overridden. 1991 A 404 (Not Found) response is appropriate when the request is for a 1992 device that is not known to the MASA. 1994 A 406 (Not Acceptable) response is appropriate if a voucher of the 1995 desired type or using the desired algorithms (as indicated by the 1996 Accept: headers, and algorithms used in the signature) cannot be 1997 issued such as because the MASA knows the pledge cannot process that 1998 type. The registrar SHOULD use this response if it determines the 1999 pledge is unacceptable due to inventory control, MASA audit logs, or 2000 any other reason. 2002 A 415 (Unsupported Media Type) response is approriate for a request 2003 that has a voucher-request or accept encoding that is not understood. 2005 The voucher response format is as indicated in the submitted accept 2006 header or based on the MASA's prior understanding of proper format 2007 for this Pledge. Only the [RFC8366] "application/voucher-cms+json" 2008 media type is defined at this time. The syntactic details of 2009 vouchers are described in detail in [RFC8366]. For example, the 2010 voucher consists of: 2012 { 2013 "ietf-voucher:voucher": { 2014 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 2015 "assertion": "logging" 2016 "pinned-domain-cert": "base64encodedvalue==" 2017 "serial-number": "JADA123456789" 2018 } 2019 } 2021 The MASA populates the voucher fields as follows: 2023 nonce: The nonce from the pledge if available. See Section 5.5.7. 2025 assertion: The method used to verify assertion. See Section 5.5.5. 2027 pinned-domain-cert: The domain CA cert. See Section 5.5.6. This 2028 figure is illustrative, for an example, see Appendix D.2 2030 serial-number: The serial-number as provided in the voucher-request. 2031 Also see Section 5.5.5. 2033 domain-cert-revocation-checks: Set as appropriate for the pledge's 2034 capabilities and as documented in [RFC8366]. The MASA MAY set 2035 this field to 'false' since setting it to 'true' would require 2036 that revocation information be available to the pledge and this 2037 document does not make normative requirements for [RFC6961] or 2038 equivalent integrations. 2040 expires-on: This is set for nonceless vouchers. The MASA ensures 2041 the voucher lifetime is consistent with any revocation or pinned- 2042 domain-cert consistency checks the pledge might perform. See 2043 section Section 2.6.1. There are three times to consider: (a) a 2044 configured voucher lifetime in the MASA, (b) the expiry time for 2045 the registrar's certificate, (c) any certificate revocation 2046 information (CRL) lifetime. The expires-on field SHOULD be before 2047 the earliest of these three values. Typically (b) will be some 2048 significant time in the future, but (c) will typically be short 2049 (on the order of a week or less). The RECOMMENDED period for (a) 2050 is on the order of 20 minutes, so it will typically determine the 2051 lifespan of the resulting voucher. 20 minutes is sufficent time 2052 to reach the post-provisional state in the pledge, at which point 2053 there is an established trust relationship between pledge and 2054 registrar. The subsequent operations can take as long as required 2055 from that point onwards. The lifetime of the voucher has no 2056 impact on the lifespan of the ownership relationship. 2058 Whenever a voucher is issued the MASA MUST update the audit log 2059 appropriately. The internal state requirements to maintain the audit 2060 log are out-of-scope. See Section 5.8.1 for a discussion of 2061 reporting the log to a registrar. 2063 5.6.1. Pledge voucher verification 2065 The pledge MUST verify the voucher signature using the manufacturer 2066 installed trust anchor(s) associated with the manufacturer's MASA 2067 (this is likely included in the pledge's firmware). Management of 2068 the manufacter installed trust anchor(s) is out-of-scope of this 2069 document; this protocol does not update these trust anchor(s). 2071 The pledge MUST verify the serial-number field of the signed voucher 2072 matches the pledge's own serial-number. 2074 The pledge MUST verify that the voucher nonce field is accurate and 2075 matches the nonce the pledge submitted to this registrar, or that the 2076 voucher is nonceless (see Section 6.2). 2078 The pledge MUST be prepared to parse and fail gracefully from a 2079 voucher response that does not contain a 'pinned-domain-cert' field. 2080 The pledge MUST be prepared to ignore additional fields that it does 2081 not recognize. 2083 5.6.2. Pledge authentication of provisional TLS connection 2085 The 'pinned-domain-cert' element of the voucher contains the domain 2086 CA's public key. The pledge MUST use the 'pinned-domain-cert' trust 2087 anchor to immediately complete authentication of the provisional TLS 2088 connection. 2090 If a registrar's credentials cannot be verified using the pinned- 2091 domain-cert trust anchor from the voucher then the TLS connection is 2092 immediately discarded and the pledge abandons attempts to bootstrap 2093 with this discovered registrar. The pledge SHOULD send voucher 2094 status telemetry (described below) before closing the TLS connection. 2095 The pledge MUST attempt to enroll using any other proxies it has 2096 found. It SHOULD return to the same proxy again after attempting 2097 with other proxies. Attempts should be attempted in the exponential 2098 backoff described earlier. Attempts SHOULD be repeated as failure 2099 may be the result of a temporary inconsistently (an inconsistently 2100 rolled registrar key, or some other mis-configuration). The 2101 inconsistently could also be the result an active MITM attack on the 2102 EST connection. 2104 The registrar MUST use a certificate that chains to the pinned- 2105 domain-cert as its TLS server certificate. 2107 The pledge's PKIX path validation of a registrar certificate's 2108 validity period information is as described in Section 2.6.1. Once 2109 the PKIX path validation is successful the TLS connection is no 2110 longer provisional. 2112 The pinned-domain-cert MAY be installed as an trust anchor for future 2113 operations such as enrollment (e.g. [RFC7030] as recommended) or 2114 trust anchor management or raw protocols that do not need full PKI 2115 based key management. It can be used to authenticate any dynamically 2116 discovered EST server that contain the id-kp-cmcRA extended key usage 2117 extension as detailed in EST RFC7030 section 3.6.1; but to reduce 2118 system complexity the pledge SHOULD avoid additional discovery 2119 operations. Instead the pledge SHOULD communicate directly with the 2120 registrar as the EST server. The 'pinned-domain-cert' is not a 2121 complete distribution of the [RFC7030] section 4.1.3 CA Certificate 2122 Response, which is an additional justification for the recommendation 2123 to proceed with EST key management operations. Once a full CA 2124 Certificate Response is obtained it is more authoritative for the 2125 domain than the limited 'pinned-domain-cert' response. 2127 5.7. Pledge BRSKI Status Telemetry 2129 The domain is expected to provide indications to the system 2130 administrators concerning device lifecycle status. To facilitate 2131 this it needs telemetry information concerning the device's status. 2133 To indicate pledge status regarding the voucher, the pledge MUST post 2134 a status message. 2136 The posted data media type: application/json 2138 The client HTTP POSTs the following to the server at the EST well 2139 known URI "/voucher_status". The Status field indicates if the 2140 voucher was acceptable. If it was not acceptable the Reason string 2141 indicates why. In the failure case this message may be sent to an 2142 unauthenticated, potentially malicious registrar and therefore the 2143 Reason string SHOULD NOT provide information beneficial to an 2144 attacker. The operational benefit of this telemetry information is 2145 balanced against the operational costs of not recording that an 2146 voucher was ignored by a client the registrar expected to continue 2147 joining the domain. 2149 { 2150 "version":"1", 2151 "Status":FALSE /* TRUE=Success, FALSE=Fail" 2152 "Reason":"Informative human readable message" 2153 "reason-context": { additional JSON } 2154 } 2156 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2157 an HTTP 404 error. The client ignores any response. Within the 2158 server logs the server SHOULD capture this telemetry information. 2160 The reason-context attribute is an arbitrary JSON object (literal 2161 value or hash of values) which provides additional information 2162 specific to this pledge. The contents of this field are not subject 2163 to standardization. 2165 Additional standard JSON fields in this POST MAY be added, see 2166 Section 7.3. 2168 5.8. Registrar audit log request 2170 After receiving the pledge status telemetry Section 5.7, the 2171 registrar SHOULD request the MASA audit log from the MASA service. 2173 This is done with an HTTP GET using the operation path value of 2174 "/.well-known/est/requestauditlog". 2176 The registrar SHOULD HTTP POST the same registrar voucher-request as 2177 it did when requesting a voucher (using the same Content-Type). It 2178 is posted to the /requestauditlog URI instead. The "idevid-issuer" 2179 and "serial-number" informs the MASA which log is requested so the 2180 appropriate log can be prepared for the response. Using the same 2181 media type and message minimizes cryptographic and message operations 2182 although it results in additional network traffic. The relying MASA 2183 implementation MAY leverage internal state to associate this request 2184 with the original, and by now already validated, voucher-request so 2185 as to avoid an extra crypto validation. 2187 A registrar MAY request logs at future times. If the registrar 2188 generates a new request then the MASA is forced to perform the 2189 additional cryptographic operations to verify the new request. 2191 A MASA that receives a request for a device that does not exist, or 2192 for which the requesting owner was never an owner returns an HTTP 404 2193 ("Not found") code. 2195 Rather than returning the audit log as a response to the POST (with a 2196 return code 200), the MASA MAY instead return a 201 ("Created") 2197 RESTful response ([RFC7231] section 7.1) containing a URL to the 2198 prepared (and easily cachable) audit response. 2200 In order to avoid enumeration of device audit logs, MASA that return 2201 URLs SHOULD take care to make the returned URL unguessable. For 2202 instance, rather than returning URLs containing a database number 2203 such as https://example.com/auditlog/1234 or the EUI of the device 2204 such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD 2205 return a randomly generated value (a "slug" in web parlance). The 2206 value is used to find the relevant database entry. 2208 A MASA that returns a code 200 MAY also include a Location: header 2209 for future reference by the registrar. 2211 5.8.1. MASA audit log response 2213 A log data file is returned consisting of all log entries associated 2214 with the the device selected by the IDevID presented in the request. 2215 The audit log may be truncated of old or repeated values as explained 2216 below. The returned data is in JSON format ([RFC7951]), and the 2217 Content-Type SHOULD be "application/json". For example: 2219 { 2220 "version":"1", 2221 "events":[ 2222 { 2223 "date":"", 2224 "domainID":"", 2225 "nonce":"" 2226 "assertion":"" 2227 "truncated":"" 2228 }, 2229 { 2230 "date":"", 2231 "domainID":"", 2232 "nonce":"" 2233 "assertion":"" 2234 } 2235 ], 2236 "truncation": { 2237 "nonced duplicates": "", 2238 "nonceless duplicates": "", 2239 "arbitrary": "" 2240 } 2241 } 2243 Distribution of a large log is less than ideal. This structure can 2244 be optimized as follows: Nonced or Nonceless entries for the same 2245 domainID MAY be truncated from the log leaving only the single most 2246 recent nonced or nonceless entry for that domainID. In the case of 2247 truncation the 'event' truncation value SHOULD contain a count of the 2248 number of events for this domainID that were truncated. The log 2249 SHOULD NOT be further reduced but there could exist operational 2250 situation where maintaining the full log is not possible. In such 2251 situations the log MAY be arbitrarily truncated for length, with the 2252 number of removed entries indicated as 'arbitrary'. 2254 If the truncation count exceeds 1024 then the MASA MAY use this value 2255 without further incrementing it. 2257 A log where duplicate entries for the same domain have been truncated 2258 ("nonced duplicates" and/or "nonceless duplicates) could still be 2259 acceptable for informed decisions. A log that has had "arbitrary" 2260 truncations is less acceptable but manufacturer transparency is 2261 better than hidden truncations. 2263 This document specifies a simple log format as provided by the MASA 2264 service to the registrar. This format could be improved by 2265 distributed consensus technologies that integrate vouchers with 2266 technologies such as block-chain or hash trees or optimized logging 2267 approaches. Doing so is out of the scope of this document but is an 2268 anticipated improvement for future work. As such, the registrar 2269 client SHOULD anticipate new kinds of responses, and SHOULD provide 2270 operator controls to indicate how to process unknown responses. 2272 5.8.2. Registrar audit log verification 2274 Each time the Manufacturer Authorized Signing Authority (MASA) issues 2275 a voucher, it places it into the audit log for that device. The 2276 details are described in Section 5.8. The contents of the audit log 2277 can express a variety of trust levels, and this section explains what 2278 kind of trust a registrar can derive from the entries. 2280 While the audit log provides a list of vouchers that were issued by 2281 the MASA, the vouchers are issued in response to voucher-requests, 2282 and it is the contents of the voucher-requests which determines how 2283 meaningful the audit log entries are. 2285 A registrar SHOULD use the log information to make an informed 2286 decision regarding the continued bootstrapping of the pledge. The 2287 exact policy is out of scope of this document as it depends on the 2288 security requirements within the registrar domain. Equipment that is 2289 purchased pre-owned can be expected to have an extensive history. 2290 The following dicussion is provided to help explain the value of each 2291 log element: 2293 date: The date field provides the registrar an opportunity to divide 2294 the log around known events such as the purchase date. Depending 2295 on context known to the registrar or administrator evens before/ 2296 after certain dates can have different levels of importance. For 2297 example for equipment that is expected to be new, and thus have no 2298 history, it would be a surprise to find prior entries. 2300 domainID: If the log includes an unexpected domainID then the pledge 2301 could have imprinted on an unexpected domain. The registrar can 2302 be expected to use a variety of techniques to define "unexpected" 2303 ranging from white lists of prior domains to anomoly detection 2304 (e.g. "this device was previously bound to a different domain than 2305 any other device deployed"). Log entries can also be compared 2306 against local history logs in search of discrepancies (e.g. "this 2307 device was re-deployed some number of times internally but the 2308 external audit log shows additional re-deployments our internal 2309 logs are unaware of"). 2311 nonce: Nonceless entries mean the logged domainID could 2312 theoretically trigger a reset of the pledge and then take over 2313 management by using the existing nonceless voucher. 2315 assertion: The assertion leaf in the voucher and audit log indicates 2316 why the MASA issued the voucher. A "verified" entry means that 2317 the MASA issued the associated voucher as a result of positive 2318 verification of ownership but this can still be problematic for 2319 registrar's that expected only new (not pre-owned) pledges. A 2320 "logged" assertion informs the registrar that the prior vouchers 2321 were issued with minimal verification. A "proximity" assertion 2322 assures the registrar that the pledge was truly communicating with 2323 the prior domain and thus provides assurance that the prior domain 2324 really has deployed the pledge. 2326 A relatively simple policy is to white list known (internal or 2327 external) domainIDs and to require all vouchers to have a nonce and/ 2328 or require that all nonceless vouchers be from a subset (e.g. only 2329 internal) domainIDs. A simple action is to revoke any locally issued 2330 credentials for the pledge in question or to refuse to forward the 2331 voucher. A registrar MAY be configured to ignore the history of the 2332 device but it is RECOMMENDED that this only be configured if hardware 2333 assisted NEA [RFC5209] is supported. 2335 5.9. EST Integration for PKI bootstrapping 2337 The pledge SHOULD follow the BRSKI operations with EST enrollment 2338 operations including "CA Certificates Request", "CSR Attributes" and 2339 "Client Certificate Request" or "Server-Side Key Generation", etc. 2340 This is a relatively seamless integration since BRSKI REST calls 2341 provide an automated alternative to the manual bootstrapping method 2342 described in [RFC7030]. As noted above, use of HTTP 1.1 persistent 2343 connections simplifies the pledge state machine. 2345 Although EST allows clients to obtain multiple certificates by 2346 sending multiple CSR requests BRSKI mandates use of the CSR 2347 Attributes request and mandates that the registrar validate the CSR 2348 against the expected attributes. This implies that client requests 2349 will "look the same" and therefore result in a single logical 2350 certificate being issued even if the client were to make multiple 2351 requests. Registrars MAY contain more complex logic but doing so is 2352 out-of-scope of this specification. BRSKI does not signal any 2353 enhancement or restriction to this capability. 2355 5.9.1. EST Distribution of CA Certificates 2357 The pledge SHOULD request the full EST Distribution of CA 2358 Certificates message. See RFC7030, section 4.1. 2360 This ensures that the pledge has the complete set of current CA 2361 certificates beyond the pinned-domain-cert (see Section 5.6.1 for a 2362 discussion of the limitations inherent in having a single certificate 2363 instead of a full CA Certificates response.) Although these 2364 limitations are acceptable during initial bootstrapping, they are not 2365 appropriate for ongoing PKIX end entity certificate validation. 2367 5.9.2. EST CSR Attributes 2369 Automated bootstrapping occurs without local administrative 2370 configuration of the pledge. In some deployments it is plausible 2371 that the pledge generates a certificate request containing only 2372 identity information known to the pledge (essentially the X.509 2373 IDevID information) and ultimately receives a certificate containing 2374 domain specific identity information. Conceptually the CA has 2375 complete control over all fields issued in the end entity 2376 certificate. Realistically this is operationally difficult with the 2377 current status of PKI certificate authority deployments, where the 2378 CSR is submitted to the CA via a number of non-standard protocols. 2379 Even with all standardized protocols used, it could operationally be 2380 problematic to expect that service specific certificate fields can be 2381 created by a CA that is likely operated by a group that has no 2382 insight into different network services/protocols used. For example, 2383 the CA could even be outsourced. 2385 To alleviate these operational difficulties, the pledge MUST request 2386 the EST "CSR Attributes" from the EST server and the EST server needs 2387 to be able to reply with the attributes necessary for use of the 2388 certificate in its intended protocols/services. This approach allows 2389 for minimal CA integrations and instead the local infrastructure (EST 2390 server) informs the pledge of the proper fields to include in the 2391 generated CSR. This approach is beneficial to automated boostrapping 2392 in the widest number of environments. 2394 If the hardwareModuleName in the X.509 IDevID is populated then it 2395 SHOULD by default be propagated to the LDevID along with the 2396 hwSerialNum. The EST server SHOULD support local policy concerning 2397 this functionality. 2399 In networks using the BRSKI enrolled certificate to authenticate the 2400 ACP (Autonomic Control Plane), the EST attributes MUST include the 2401 "ACP information" field. See 2402 [I-D.ietf-anima-autonomic-control-plane] for more details. 2404 The registrar MUST also confirm that the resulting CSR is formatted 2405 as indicated before forwarding the request to a CA. If the registrar 2406 is communicating with the CA using a protocol such as full CMC, which 2407 provides mechanisms to override the CSR attributes, then these 2408 mechanisms MAY be used even if the client ignores CSR Attribute 2409 guidance. 2411 5.9.3. EST Client Certificate Request 2413 The pledge MUST request a new client certificate. See RFC7030, 2414 section 4.2. 2416 5.9.4. Enrollment Status Telemetry 2418 For automated bootstrapping of devices, the adminstrative elements 2419 providing bootstrapping also provide indications to the system 2420 administrators concerning device lifecycle status. This might 2421 include information concerning attempted bootstrapping messages seen 2422 by the client, MASA provides logs and status of credential 2423 enrollment. [RFC7030] assumes an end user and therefore does not 2424 include a final success indication back to the server. This is 2425 insufficient for automated use cases. 2427 To indicate successful enrollment the client SHOULD re-negotiate the 2428 EST TLS session using the newly obtained credentials. This occurs by 2429 the client initiating a new TLS ClientHello message on the existing 2430 TLS connection. The client MAY simply close the old TLS session and 2431 start a new one. The server MUST support either model. 2433 In the case of a FAIL, the Reason string indicates why the most 2434 recent enrollment failed. The SubjectKeyIdentifier field MUST be 2435 included if the enrollment attempt was for a keypair that is locally 2436 known to the client. If EST /serverkeygen was used and failed then 2437 the field is omitted from the status telemetry. 2439 In the case of a SUCCESS the Reason string is omitted. The 2440 SubjectKeyIdentifier is included so that the server can record the 2441 successful certificate distribution. 2443 Status media type: application/json 2445 The client HTTP POSTs the following to the server at the new EST well 2446 known URI /enrollstatus. 2448 { 2449 "version":"1", 2450 "Status":TRUE /* TRUE=Success, FALSE=Fail" 2451 "Reason":"Informative human readable message" 2452 "reason-context": "Additional information" 2453 } 2455 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2456 an HTTP 404 error. 2458 Within the server logs the server MUST capture if this message was 2459 received over an TLS session with a matching client certificate. 2460 This allows for clients that wish to minimize their crypto operations 2461 to simply POST this response without renegotiating the TLS session - 2462 at the cost of the server not being able to accurately verify that 2463 enrollment was truly successful. 2465 5.9.5. Multiple certificates 2467 Pledges that require multiple certificates could establish direct EST 2468 connections to the registrar. 2470 5.9.6. EST over CoAP 2472 This document describes extensions to EST for the purposes of 2473 bootstrapping of remote key infrastructures. Bootstrapping is 2474 relevant for CoAP enrollment discussions as well. The defintion of 2475 EST and BRSKI over CoAP is not discussed within this document beyond 2476 ensuring proxy support for CoAP operations. Instead it is 2477 anticipated that a definition of CoAP mappings will occur in 2478 subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP 2479 mappings for BRSKI will be discussed either there or in future work. 2481 6. Reduced security operational modes 2483 A common requirement of bootstrapping is to support less secure 2484 operational modes for support specific use cases. The following 2485 sections detail specific ways that the pledge, registrar and MASA can 2486 be configured to run in a less secure mode for the indicated reasons. 2488 This section is considered non-normative: use suggested methods MUST 2489 be detailed in specific profiles of BRSKI. This is the subject for 2490 future work. 2492 6.1. Trust Model 2494 This section explains the trust relationships detailed in 2495 Section 2.4: 2497 +--------+ +---------+ +------------+ +------------+ 2498 | Pledge | | Join | | Domain | |Manufacturer| 2499 | | | Proxy | | Registrar | | Service | 2500 | | | | | | | (Internet) | 2501 +--------+ +---------+ +------------+ +------------+ 2503 Figure 10 2505 Pledge: The pledge could be compromised and providing an attack 2506 vector for malware. The entity is trusted to only imprint using 2507 secure methods described in this document. Additional endpoint 2508 assessment techniques are RECOMMENDED but are out-of-scope of this 2509 document. 2511 Join Proxy: Provides proxy functionalities but is not involved in 2512 security considerations. 2514 Registrar: When interacting with a MASA a registrar makes all 2515 decisions. For Ownership Audit Vouchers (see [RFC8366]) the 2516 registrar is provided an opportunity to accept MASA decisions. 2518 Vendor Service, MASA: This form of manufacturer service is trusted 2519 to accurately log all claim attempts and to provide authoritative 2520 log information to registrars. The MASA does not know which 2521 devices are associated with which domains. These claims could be 2522 strengthened by using cryptographic log techniques to provide 2523 append only, cryptographic assured, publicly auditable logs. 2524 Current text provides only for a trusted manufacturer. 2526 Vendor Service, Ownership Validation: This form of manufacturer 2527 service is trusted to accurately know which device is owned by 2528 which domain. 2530 6.2. Pledge security reductions 2532 The pledge can choose to accept vouchers using less secure methods. 2533 These methods enable offline and emergency (touch based) deployment 2534 use cases: 2536 1. The pledge MUST accept nonceless vouchers. This allows for a use 2537 case where the registrar can not connect to the MASA at the 2538 deployment time. Logging and validity periods address the 2539 security considerations of supporting these use cases. 2541 2. Many devices already support "trust on first use" for physical 2542 interfaces such as console ports. This document does not change 2543 that reality. Devices supporting this protocol MUST NOT support 2544 "trust on first use" on network interfaces. This is because 2545 "trust on first use" over network interfaces would undermine the 2546 logging based security protections provided by this 2547 specification. 2549 3. The pledge MAY have an operational mode where it skips voucher 2550 validation one time. For example if a physical button is 2551 depressed during the bootstrapping operation. This can be useful 2552 if the manufacturer service is unavailable. This behavior SHOULD 2553 be available via local configuration or physical presence methods 2554 (such as use of a serial/craft console) to ensure new entities 2555 can always be deployed even when autonomic methods fail. This 2556 allows for unsecured imprint. 2558 It is RECOMMENDED that "trust on first use" or any method of skipping 2559 voucher validation (including use of craft serial console) only be 2560 available if hardware assisted Network Endpoint Assessment [RFC5209] 2561 is supported. This recommendation ensures that domain network 2562 monitoring can detect innappropriate use of offline or emergency 2563 deployment procedures when voucher-based bootstrapping is not used. 2565 6.3. Registrar security reductions 2567 A registrar can choose to accept devices using less secure methods. 2568 These methods are acceptable when low security models are needed, as 2569 the security decisions are being made by the local administrator, but 2570 they MUST NOT be the default behavior: 2572 1. A registrar MAY choose to accept all devices, or all devices of a 2573 particular type, at the administrator's discretion. This could 2574 occur when informing all registrars of unique identifiers of new 2575 entities might be operationally difficult. 2577 2. A registrar MAY choose to accept devices that claim a unique 2578 identity without the benefit of authenticating that claimed 2579 identity. This could occur when the pledge does not include an 2580 X.509 IDevID factory installed credential. New Entities without 2581 an X.509 IDevID credential MAY form the Section 5.2 request using 2582 the Section 5.5 format to ensure the pledge's serial number 2583 information is provided to the registrar (this includes the 2584 IDevID AuthorityKeyIdentifier value, which would be statically 2585 configured on the pledge.) The pledge MAY refuse to provide a 2586 TLS client certificate (as one is not available.) The pledge 2587 SHOULD support HTTP-based or certificate-less TLS authentication 2588 as described in EST RFC7030 section 3.3.2. A registrar MUST NOT 2589 accept unauthenticated New Entities unless it has been configured 2590 to do so by an administrator that has verified that only expected 2591 new entities can communicate with a registrar (presumably via a 2592 physically secured perimeter.) 2594 3. A registrar MAY submit a nonceless voucher-requests to the MASA 2595 service (by not including a nonce in the voucher-request.) The 2596 resulting vouchers can then be stored by the registrar until they 2597 are needed during bootstrapping operations. This is for use 2598 cases where the target network is protected by an air gap and 2599 therefore cannot contact the MASA service during pledge 2600 deployment. 2602 4. A registrar MAY ignore unrecognized nonceless log entries. This 2603 could occur when used equipment is purchased with a valid history 2604 being deployed in air gap networks that required permanent 2605 vouchers. 2607 5. A registrar MAY accept voucher formats of future types that can 2608 not be parsed by the Registrar. This reduces the Registrar's 2609 visibility into the exact voucher contents but does not change 2610 the protocol operations. 2612 6.4. MASA security reductions 2614 Lower security modes chosen by the MASA service affect all device 2615 deployments unless bound to the specific device identities. In which 2616 case these modes can be provided as additional features for specific 2617 customers. The MASA service can choose to run in less secure modes 2618 by: 2620 1. Not enforcing that a nonce is in the voucher. This results in 2621 distribution of a voucher that never expires and in effect makes 2622 the Domain an always trusted entity to the pledge during any 2623 subsequent bootstrapping attempts. That this occurred is 2624 captured in the log information so that the registrar can make 2625 appropriate security decisions when a pledge joins the Domain. 2626 This is useful to support use cases where registrars might not be 2627 online during actual device deployment. Because this results in 2628 a long lived voucher and does not require the proof that the 2629 device is online, this is only accepted when the registrar is 2630 authenticated by the MASA and authorized to provide this 2631 functionality. The MASA is RECOMMENDED to use this functionality 2632 only in concert with an enhanced level of ownership tracking 2633 (out-of-scope.) If the pledge device is known to have a real- 2634 time-clock that is set from the factory, use of a voucher 2635 validity period is RECOMMENDED. 2637 2. Not verifying ownership before responding with a voucher. This 2638 is expected to be a common operational model because doing so 2639 relieves the manufacturer providing MASA services from having to 2640 track ownership during shipping and supply chain and allows for a 2641 very low overhead MASA service. A registrar uses the audit log 2642 information as a defense in depth strategy to ensure that this 2643 does not occur unexpectedly (for example when purchasing new 2644 equipment the registrar would throw an error if any audit log 2645 information is reported.) The MASA SHOULD verify the 'prior- 2646 signed-voucher-request' information for pledges that support that 2647 functionality. This provides a proof-of-proximity check that 2648 reduces the need for ownership verification. 2650 7. IANA Considerations 2652 This document requires the following IANA actions: 2654 7.1. Well-known EST registration 2656 This document extends the definitions of "est" (so far defined via 2657 RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ 2658 well-known-uris.xhtml" registry as follows: 2660 o add /.well-known/est/requestvoucher (see Section 5.5 ) 2662 o add /.well-known/est/requestauditlog (see Section 5.7) 2664 7.2. PKIX Registry 2666 IANA is requested to register the following: 2668 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 2669 the pkix(7) id-mod(0) Registry. 2671 This document has received an early allocation from the id-pe 2672 registry (SMI Security for PKIX Certificate Extension) for id-pe- 2673 masa-url with the value 32, resulting in an OID of 2674 1.3.6.1.5.5.7.1.32. 2676 7.3. Pledge BRSKI Status Telemetry 2678 IANA is requested to create a new Registry entitled: "BRSKI 2679 Parameters", and within that Registry to create a table called: 2680 "Pledge BRSKI Status Telemetry Attributes". New items can be added 2681 using the Specification Required. The following items are to be in 2682 the initial registration, with this document (Section 5.7) as the 2683 reference: 2685 o version 2687 o Status 2689 o Reason 2691 o reason-context 2693 7.4. DNS Service Names 2695 IANA is requested to register the following Service Names: 2697 Service Name: _brski-proxy 2698 Transport Protocol(s): tcp 2699 Assignee: IESG . 2700 Contact: IESG 2701 Description: The Bootstrapping Remote Secure Key 2702 Infrastructures Proxy 2703 Reference: [This document] 2705 Service Name: _brski-registrar 2706 Transport Protocol(s): tcp 2707 Assignee: IESG . 2708 Contact: IESG 2709 Description: The Bootstrapping Remote Secure Key 2710 Infrastructures Registrar 2711 Reference: [This document] 2713 7.5. MUD File Extension for the MASA 2715 The IANA is requested to list the name "masa" in the MUD extensions 2716 registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in 2717 Appendix C. 2719 8. Applicability to the Autonomic Control Plane 2721 This document provides a solution to the requirements for secure 2722 bootstrap set out in Using an Autonomic Control Plane for Stable 2723 Connectivity of Network Operations, Administration, and Maintenance 2724 [RFC8368], A Reference Model for Autonomic Networking 2725 [I-D.ietf-anima-reference-model] and specifically the An Autonomic 2726 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section 2727 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 2728 Network). 2730 The protocol described in this document has appeal in a number of 2731 other non-ANIMA use cases. Such uses of the protocol will be 2732 deploying into other environments with different tradeoffs of 2733 privacy, security, reliability and autonomy from manufacturers. As 2734 such those use cases will need to provide their own applicability 2735 statements, and will need to address unique privacy and security 2736 considerations for the environments in which they are used. 2738 The autonomic control plane that this document provides bootstrap for 2739 is typically a medium to large Internet Service Provider 2740 organization, or an equivalent Enterprise that has signficant layer-3 2741 router connectivity. (A network consistenting of primarily layer-2 2742 is not excluded, but the adjacencies that the ACP will create and 2743 maintain will not reflect the topology until all devices participate 2744 in the ACP). 2746 As specified in the ANIMA charter, this work "..focuses on 2747 professionally-managed networks." Such a network has an operator and 2748 can do things like like install, configure and operate the Registrar 2749 function. The operator makes purchasing decisions and is aware of 2750 what manufacturers it expects to see on it's network. 2752 Such an operator also is capable of performing the traditional (craft 2753 serial-console) based bootstrap of devices. The zero-touch mechanism 2754 presented in this and the ACP document represents a signficiant 2755 efficiency: in particular it reduces the need to put senior experts 2756 on airplanes to configure devices in person. There is a recognition 2757 as the technology evolves that not every situation may work out, and 2758 occasionally a human still still have to visit. 2760 The BRSKI protocol is going into environments where there have 2761 already been quite a number of vendor proprietary management systems. 2762 Those are not expected to go away quickly, but rather to leverage the 2763 secure credentials that are provisioned by BRSKI. The connectivity 2764 requirements of said management systems are provided by the ACP. 2766 9. Privacy Considerations 2768 9.1. MASA audit log 2770 The MASA audit log includes a hash of the domainID for each Registrar 2771 a voucher has been issued to. This information is closely related to 2772 the actual domain identity, especially when paired with the anti-DDoS 2773 authentication information the MASA might collect. This could 2774 provide sufficient information for the MASA service to build a 2775 detailed understanding the devices that have been provisioned within 2776 a domain. 2778 There are a number of design choices that mitigate this risk. The 2779 domain can maintain some privacy since it has not necessarily been 2780 authenticated and is not authoritatively bound to the supply chain. 2782 Additionally the domainID captures only the unauthenticated subject 2783 key identifier of the domain. A privacy sensitive domain could 2784 theoretically generate a new domainID for each device being deployed. 2785 Similarly a privacy sensitive domain would likely purchase devices 2786 that support proximity assertions from a manufacturer that does not 2787 require sales channel integrations. This would result in a 2788 significant level of privacy while maintaining the security 2789 characteristics provided by Registrar based audit log inspection. 2791 9.2. What BRSKI-MASA reveals to the manufacturer 2793 The so-called "call-home" mechanism that occurs as part of the BRSKI- 2794 MASA connection standardizes what has been deemed by some as a 2795 sinister mechanism for corporate oversight of individuals. 2796 ([livingwithIoT] and [IoTstrangeThings] for a small sample). 2798 As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted 2799 at individual usage of IoT devices, but rather at the Enterprise and 2800 ISP creation of networks in a zero-touch fashion, the "call-home" 2801 represents a different kind of concern. 2803 It needs to be re-iterated that the BRSKI-MASA mechanism only occurs 2804 once during the comissioning of the device. It is well defined, and 2805 although encrypted with TLS, it could in theory be made auditable as 2806 the contents are well defined. This connection does not occur when 2807 the device powers on or is restarted for normal routines. It is 2808 conceivable that a device could be forced to go through a full 2809 factory reset during an exceptional firmware update situation, after 2810 which enrollment would have be repeated. 2812 The BRSKI call-home mechanism is mediated via the owner's Registrar, 2813 and the information that is transmitted is directly auditable by the 2814 device owner. This is in stark constrast to many "call-home" 2815 protocols where the device autonomously calls home and uses an 2816 undocumented protocol. 2818 While the contents of the signed part of the pledge voucher request 2819 can not be changed, they are not encrypted at the registrar. The 2820 ability to audit the messages by the owner of the network prevents 2821 exfiltration of data by a nefarious pledge. The contents of an 2822 unsigned voucher request are, however, completely changeable by the 2823 Registrar. Both are, to re-iterate, encrypted by TLS while in 2824 transit. 2826 The BRSKI-MASA exchange reveals the following information to the 2827 manufacturer: 2829 o the identity of the device being enrolled (down to the serial- 2830 number!). 2832 o an identity of the domain owner in the form of the domain trust 2833 anchor. However, this is not a global PKI anchored name within 2834 the WebPKI, so this identity could be pseudonymous. If there is 2835 sales channel integration, then the MASA will have authenticated 2836 the domain owner, either via pinned certificate, or perhaps 2837 another HTTP authentication method, as per Section 5.5.3. 2839 o the time the device is activated, 2841 o the IP address of the domain Owner's Registrar. For ISPs and 2842 Enterprises, the IP address provides very clear geolocation of the 2843 owner. No amount of IP address privacy extensions ([RFC4941]) can 2844 do anything about this, as a simple whois lookup likely identifies 2845 the ISP or Enterprise from the upper bits anyway. A passive 2846 attacker who observes the connection definitely may conclude that 2847 the given enterprise/ISP is a customer of the particular equipment 2848 vendor. The precise model that is being enrolled will remain 2849 private. 2851 The above situation is to be distinguished from a residential/ 2852 individual person who registers a device from a manufacturer: that an 2853 enterprise/ISP purchases routing products is hardly worth mentioning. 2854 Deviations would, however, be notable. 2856 The situation is not improved by the enterprise/ISP using 2857 anonymization services such as ToR [Dingledine2004], as a TLS 1.2 2858 connection will reveal the ClientCertificate used, clearly 2859 identifying the enterprise/ISP involved. TLS 1.3 is better in this 2860 regard, but an active attacker can still discover the parties 2861 involved by performing a Man-In-The-Middle-Attack on the first 2862 attempt (breaking/killing it with a TCP RST), and then letting 2863 subsequent connection pass through. 2865 A manufacturer could attempt to mix the BRSKI-MASA traffic in with 2866 general traffic their site by hosting the MASA behind the same (set) 2867 of load balancers that the companies normal marketing site is hosted 2868 behind. This makes lots of sense from a straight capacity planning 2869 point of view as the same set of services (and the same set of 2870 Distributed Denial of Service mitigations) may be used. 2871 Unfortunately, as the BRSKI-MASA connections include TLS 2872 ClientCertificate exchanges, this may easily be observed in TLS 1.2, 2873 and a traffic analysis may reveal it even in TLS 1.3. This does not 2874 make such a plan irrelevant. There may be other organizational 2875 reasons to keep the marketing site (which is often subject to 2876 frequent redesigs, outsourcing, etc.) seperate from the MASA, which 2877 may need to operate reliably for decades. 2879 9.3. Manufacturers and Used or Stolen Equipment 2881 As explained above, the manufacturer receives information each time 2882 that a device which is in factory-default mode does a zero-touch 2883 bootstrap, and attempts to enroll into a domain owner's registrar. 2885 The manufacturer is therefore in a position to decline to issue a 2886 voucher if it detects that the new owner is not the same as the 2887 previous owner. 2889 1. This can be seen as a feature if the equipment is believed to 2890 have been stolen. If the legitimate owner notifies the 2891 manufacturer of the theft, then when the new owner brings the 2892 device up, if they use the zero-touch mechanism, the new 2893 (illegitimate) owner reveals their location and identity. 2895 2. In the case of Used equipment, the initial owner could inform the 2896 manufacturer of the sale, or the manufacturer may just permit 2897 resales unless told otherwise. In which case, the transfer of 2898 ownership simply occurs. 2900 3. A manufacturer could however decide not to issue a new voucher in 2901 response to a transfer of ownership. This is essentially the 2902 same as the stolen case, with the manufacturer having decided 2903 that the sale was not legitimate. 2905 4. There is a fourth case, if the manufacturer is providing 2906 protection against stolen devices. The manufacturer then has a 2907 responsability to protect the legitimate owner against fraudulent 2908 claims that the the equipment was stolen. Such a claim would 2909 cause the manufacturer to refuse to issue a new voucher. Should 2910 the device go through a deep factory reset (for instance, 2911 replacement of a damaged main board component, the device would 2912 not bootstrap. 2914 5. Finally, there is a fifth case: the manufacturer has decided to 2915 end-of-line the device, or the owner has not paid a yearly 2916 support amount, and the manufacturer refuses to issue new 2917 vouchers at that point. This last case is not new to the 2918 industry: many license systems are already deployed that have 2919 significantly worse effect. 2921 This section has outlined five situations in which a manufacturer 2922 could use the voucher system to enforce what are clearly license 2923 terms. A manufacturer that attempted to enforce license terms via 2924 vouchers would find it rather ineffective as the terms would only be 2925 enforced when the device is enrolled, and this is not (to repeat), a 2926 daily or even monthly occurrance. 2928 9.4. Manufacturers and Grey market equipment 2930 Manufacturers of devices often sell different products into different 2931 regional markets. Which product is available in which market can be 2932 driven by price differentials, support issues (some markets may 2933 require manuals and tech-support to be done in the local language), 2934 government export regulation (such as whether strong crypto is 2935 permitted to be exported, or permitted to be used in a particular 2936 market). When an domain owner obtains a device from a different 2937 market (they can be new) and transfers it to a different location, 2938 this is called a Grey Market. 2940 A manufacturer could decide not to issue a voucher to an enterprise/ 2941 ISP based upon their location. There are a number of ways which this 2942 could be determined: from the geolocation of the registrar, from 2943 sales channel knowledge about the customer, and what products are 2944 (un-)available in that market. If the device has a GPS the 2945 coordinates of the device could even be placed into an extension of 2946 the voucher. 2948 The above actions are not illegal, and not new. Many manufacturers 2949 have shipped crypto-weak (exportable) versions of firmware as the 2950 default on equipment for decades. The first task of an enterprise/ 2951 ISP has always been to login to a manufacturer system, show one's 2952 "entitlement" (country informatin, proof that support payments have 2953 been made), and receive either a new updated firmware, or a license 2954 key that will activate the correct firmware. 2956 BRSKI permits the above process to automated (in an autonomic 2957 fashion), and therefore perhaps encourages this kind of 2958 differentiation by reducing the cost of doing it. 2960 An issue that manufacturers will need to deal with in the above 2961 automated process is when a device is shipped to one country with one 2962 set of rules (or laws or entitlements), but the domain registry is in 2963 another one. Which rules apply is something will have to be worked 2964 out: the manufacturer could come to believe they are dealing with 2965 Grey market equipment, when it is simply dealing with a global 2966 enterprise. 2968 9.5. Some mitigations for meddling by manufacturers 2970 The most obvious mitigation is not to buy the product. Pick 2971 manufacturers that are up-front about their policies, who do not 2972 change them gratutiously. 2974 A manufacturer could provide a mechanism to manage the trust anchors 2975 and built-in certificates (IDevID) as an extension. This is a 2976 substantial amount of work, and may be an area for future 2977 standardization work. 2979 Replacement of the voucher validation anchors (usually pointing to 2980 the original manufacturer's MASA) with those of the new owner permits 2981 the new owner to issue vouchers to subsequent owners. This would be 2982 done by having the selling (old) owner to run a MASA. 2984 In order to automatically find the new MASA, the mechanism describe 2985 in this document is to look for the MASA URL extension in the IDevID. 2986 A new owner could override this in their Registrar, or the 2987 manufacturer could provide a mechanism to update or replace the 2988 IDevID prior to sale. 2990 Once the voucher trust anchor and the IDevID is replaced, then the 2991 device will no longer trust the manufacturer in any way. When a new 2992 owner performs a bootstrap, the device will point to a MASA that has 2993 been chosen, and will validate vouchers from this new entity. 2995 The BRSKI protocol depends upon a trust anchor on the device and an 2996 identity on the device. Management of these these entities 2997 facilitiates a few new operatonal modes without making any changes to 2998 the BRSKI protocol. Those modes include: offline modes where the 2999 domain owner operates an internal MASA for all devices, resell modes 3000 where the first domain owner becomes the MASA for the next (resold- 3001 to) domain owner, and services where an aggregator acquires a large 3002 variety of devices, and then acts as a pseudonymized MASA for a 3003 variety of devices from a variety of manufacturers. 3005 Some manufacturers may wish to consider replacement of the IDevID as 3006 an indication that the device's warantee is terminated. For others, 3007 the privacy requiments of some deployments might consider this a 3008 standard operating practice. 3010 As discussed at the end of Section 5.8.1, new work could be done to 3011 use a distributed consensus technology for the audit log. This would 3012 permit the audit log to continue to be useful, even when there is a 3013 chain of MASA due to changes of ownership. 3015 10. Security Considerations 3017 This document details a protocol for bootstrapping that balances 3018 operational concerns against security concerns. As detailed in the 3019 introduction, and touched on again in Section 6, the protocol allows 3020 for reduced security modes. These attempt to deliver additional 3021 control to the local administrator and owner in cases where less 3022 security provides operational benefits. This section goes into more 3023 detail about a variety of specific considerations. 3025 To facilitate logging and administrative oversight, in addition to 3026 triggering Registration verification of MASA logs, the pledge reports 3027 on voucher parsing status to the registrar. In the case of a 3028 failure, this information is informative to a potentially malicious 3029 registrar. This is mandated anyway because of the operational 3030 benefits of an informed administrator in cases where the failure is 3031 indicative of a problem. The registrar is RECOMMENDED to verify MASA 3032 logs if voucher status telemetry is not received. 3034 To facilitate truely limited clients EST RFC7030 section 3.3.2 3035 requirements that the client MUST support a client authentication 3036 model have been reduced in Section 6 to a statement that the 3037 registrar "MAY" choose to accept devices that fail cryptographic 3038 authentication. This reflects current (poor) practices in shipping 3039 devices without a cryptographic identity that are NOT RECOMMENDED. 3041 During the provisional period of the connection the pledge MUST treat 3042 all HTTP header and content data as untrusted data. HTTP libraries 3043 are regularly exposed to non-secured HTTP traffic: mature libraries 3044 should not have any problems. 3046 Pledges might chose to engage in protocol operations with multiple 3047 discovered registrars in parallel. As noted above they will only do 3048 so with distinct nonce values, but the end result could be multiple 3049 vouchers issued from the MASA if all registrars attempt to claim the 3050 device. This is not a failure and the pledge choses whichever 3051 voucher to accept based on internal logic. The registrars verifying 3052 log information will see multiple entries and take this into account 3053 for their analytics purposes. 3055 10.1. DoS against MASA 3057 There are uses cases where the MASA could be unavailable or 3058 uncooperative to the Registrar. They include active DoS attacks, 3059 planned and unplanned network partitions, changes to MASA policy, or 3060 other instances where MASA policy rejects a claim. These introduce 3061 an operational risk to the Registrar owner in that MASA behavior 3062 might limit the ability to bootstrap a pledge device. For example 3063 this might be an issue during disaster recovery. This risk can be 3064 mitigated by Registrars that request and maintain long term copies of 3065 "nonceless" vouchers. In that way they are guaranteed to be able to 3066 bootstrap their devices. 3068 The issuance of nonceless vouchers themselves creates a security 3069 concern. If the Registrar of a previous domain can intercept 3070 protocol communications then it can use a previously issued nonceless 3071 voucher to establish management control of a pledge device even after 3072 having sold it. This risk is mitigated by recording the issuance of 3073 such vouchers in the MASA audit log that is verified by the 3074 subsequent Registrar and by Pledges only bootstrapping when in a 3075 factory default state. This reflects a balance between enabling MASA 3076 independence during future bootstrapping and the security of 3077 bootstrapping itself. Registrar control over requesting and auditing 3078 nonceless vouchers allows device owners to choose an appropriate 3079 balance. 3081 The MASA is exposed to DoS attacks wherein attackers claim an 3082 unbounded number of devices. Ensuring a registrar is representative 3083 of a valid manufacturer customer, even without validating ownership 3084 of specific pledge devices, helps to mitigate this. Pledge 3085 signatures on the pledge voucher-request, as forwarded by the 3086 registrar in the prior-signed-voucher-request field of the registrar 3087 voucher-request, significantly reduce this risk by ensuring the MASA 3088 can confirm proximity between the pledge and the registrar making the 3089 request. This mechanism is optional to allow for constrained 3090 devices. Supply chain integration ("know your customer") is an 3091 additional step that MASA providers and device vendors can explore. 3093 10.2. Freshness in Voucher-Requests 3095 A concern has been raised that the pledge voucher-request should 3096 contain some content (a nonce) provided by the registrar and/or MASA 3097 in order for those actors to verify that the pledge voucher-request 3098 is fresh. 3100 There are a number of operational problems with getting a nonce from 3101 the MASA to the pledge. It is somewhat easier to collect a random 3102 value from the registrar, but as the registrar is not yet vouched 3103 for, such a registrar nonce has little value. There are privacy and 3104 logistical challenges to addressing these operational issues, so if 3105 such a thing were to be considered, it would have to provide some 3106 clear value. This section examines the impacts of not having a fresh 3107 pledge voucher-request. 3109 Because the registrar authenticates the pledge, a full Man-in-the- 3110 Middle attack is not possible, despite the provisional TLS 3111 authentication by the pledge (see Section 5.) Instead we examine the 3112 case of a fake registrar (Rm) that communicates with the pledge in 3113 parallel or in close time proximity with the intended registrar. 3114 (This scenario is intentionally supported as described in 3115 Section 4.1.) 3117 The fake registrar (Rm) can obtain a voucher signed by the MASA 3118 either directly or through arbitrary intermediaries. Assuming that 3119 the MASA accepts the registrar voucher-request (either because Rm is 3120 collaborating with a legitimate registrar according to supply chain 3121 information, or because the MASA is in audit-log only mode), then a 3122 voucher linking the pledge to the registrar Rm is issued. 3124 Such a voucher, when passed back to the pledge, would link the pledge 3125 to registrar Rm, and would permit the pledge to end the provisional 3126 state. It now trusts Rm and, if it has any security vulnerabilities 3127 leveragable by an Rm with full administrative control, can be assumed 3128 to be a threat against the intended registrar. 3130 This flow is mitigated by the intended registrar verifying the audit 3131 logs available from the MASA as described in Section 5.8. Rm might 3132 chose to collect a voucher-request but wait until after the intended 3133 registrar completes the authorization process before submitting it. 3134 This pledge voucher-request would be 'stale' in that it has a nonce 3135 that no longer matches the internal state of the pledge. In order to 3136 successfully use any resulting voucher the Rm would need to remove 3137 the stale nonce or anticipate the pledge's future nonce state. 3138 Reducing the possibility of this is why the pledge is mandated to 3139 generate a strong random or pseudo-random number nonce. 3141 Additionally, in order to successfully use the resulting voucher the 3142 Rm would have to attack the pledge and return it to a bootstrapping 3143 enabled state. This would require wiping the pledge of current 3144 configuration and triggering a re-bootstrapping of the pledge. This 3145 is no more likely than simply taking control of the pledge directly 3146 but if this is a consideration the target network is RECOMMENDED to 3147 take the following steps: 3149 o Ongoing network monitoring for unexpected bootstrapping attempts 3150 by pledges. 3152 o Retreival and examination of MASA log information upon the 3153 occurance of any such unexpected events. Rm will be listed in the 3154 logs along with nonce information for analysis. 3156 10.3. Trusting manufacturers 3158 The BRSKI extensions to EST permit a new pledge to be completely 3159 configured with domain specific trust anchors. The link from built- 3160 in manufacturer-provided trust anchors to domain-specific trust 3161 anchors is mediated by the signed voucher artifact. 3163 If the manufacturer's IDevID signing key is not properly validated, 3164 then there is a risk that the network will accept a pledge that 3165 should not be a member of the network. As the address of the 3166 manufacturer's MASA is provided in the IDevID using the extension 3167 from Section 2.3, the malicious pledge will have no problem 3168 collaborating with it's MASA to produce a completely valid voucher. 3170 BRSKI does not, however, fundamentally change the trust model from 3171 domain owner to manufacturer. Assuming that the pledge used its 3172 IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs 3173 to trust the manufacturer. 3175 Establishing this trust between domain and manufacturer is outside 3176 the scope of BRSKI. There are a number of mechanisms that can 3177 adopted including: 3179 o Manually configuring each manufacturer's trust anchor. 3181 o A Trust-On-First-Use (TOFU) mechanism. A human would be queried 3182 upon seeing a manufacturer's trust anchor for the first time, and 3183 then the trust anchor would be installed to the trusted store. 3184 There are risks with this; even if the key to name is validated 3185 using something like the WebPKI, there remains the possibility 3186 that the name is a look alike: e.g, c1sco.com, .. 3188 o scanning the trust anchor from a QR code that came with the 3189 packaging (this is really a manual TOFU mechanism) 3191 o some sales integration process where trust anchors are provided as 3192 part of the sales process, probably included in a digital packing 3193 "slip", or a sales invoice. 3195 o consortium membership, where all manufacturers of a particular 3196 device category (e.g, a light bulb, or a cable-modem) are signed 3197 by an certificate authority specifically for this. This is done 3198 by CableLabs today. It is used for authentication and 3199 authorization as part of TR-79: [docsisroot] and [TR069]. 3201 The existing WebPKI provides a reasonable anchor between manufacturer 3202 name and public key. It authenticates the key. It does not provide 3203 a reasonable authorization for the manufacturer, so it is not 3204 directly useable on it's own. 3206 10.4. Manufacturer Maintainance of trust anchors 3208 BRSKI depends upon the manufacturer building in trust anchors to the 3209 pledge device. The voucher artifact which is signed by the MASA will 3210 be validated by the pledge using that anchor. This implies that the 3211 manufacturer needs to maintain access to a signing key that the 3212 pledge can validate. 3214 The manufacturer will need to maintain the ability to make signatures 3215 that can be validated for the lifetime that the device could be 3216 onboarded. Whether this onboarding lifetime is less than the device 3217 lifetime depends upon how the device is used. An inventory of 3218 devices kept in a warehouse as spares might not be onboarded for many 3219 decades. 3221 There are good cryptographic hygiene reasons why a manufacturer would 3222 not want to maintain access to a private key for many decades. A 3223 manufacturer in that situation can leverage a long-term certificate 3224 authority anchor, built-in to the pledge, and then a certificate 3225 chain may be incorporated using the normal CMS certificate set. This 3226 may increase the size of the voucher artifacts, but that is not a 3227 significant issues in non-constrained environements. 3229 There are a few other operational variations that manufacturers could 3230 consider. For instance, there is no reason that every device need 3231 have the same set of trust anchors pre-installed. Devices built in 3232 different factories, or on different days, or any other consideration 3233 could have different trust anchors built in, and the record of which 3234 batch the device is in would be recorded in the asset database. The 3235 manufacturer would then know which anchor to sign an artifact 3236 against. 3238 Aside from the concern about long-term access to private keys, a 3239 major limiting factor for the shelf-life of many devices will be the 3240 age of the cryptographic algorithms included. A device produced in 3241 2019 will have hardware and software capable of validating algorithms 3242 common in 2019, and will have no defense against attacks (both 3243 quantum and von-neuman brute force attacks) which have not yet been 3244 invented. This concern is orthogonal to the concern about access to 3245 private keys, but this concern likely dominates and limits the 3246 lifespan of a device in a warehouse. If any update to firmware to 3247 support new cryptographic mechanism were possible (while the device 3248 was in a warehouse), updates to trust anchors would also be done at 3249 the same time. 3251 11. Acknowledgements 3253 We would like to thank the various reviewers for their input, in 3254 particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu 3255 Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, 3256 Peter van der Stok, and Thomas Werner 3258 Significant reviews were done by Jari Arko, Christian Huitema and 3259 Russ Housley. 3261 12. References 3263 12.1. Normative References 3265 [I-D.ietf-anima-autonomic-control-plane] 3266 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 3267 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 3268 plane-19 (work in progress), March 2019. 3270 [I-D.ietf-anima-grasp] 3271 Bormann, C., Carpenter, B., and B. Liu, "A Generic 3272 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 3273 grasp-15 (work in progress), July 2017. 3275 [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, 3276 . 3279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3280 Requirement Levels", BCP 14, RFC 2119, 3281 DOI 10.17487/RFC2119, March 1997, 3282 . 3284 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3285 Levkowetz, Ed., "Extensible Authentication Protocol 3286 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 3287 . 3289 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 3290 Configuration of IPv4 Link-Local Addresses", RFC 3927, 3291 DOI 10.17487/RFC3927, May 2005, 3292 . 3294 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3295 "Randomness Requirements for Security", BCP 106, RFC 4086, 3296 DOI 10.17487/RFC4086, June 2005, 3297 . 3299 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 3300 (LDAP): Schema for User Applications", RFC 4519, 3301 DOI 10.17487/RFC4519, June 2006, 3302 . 3304 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3305 Address Autoconfiguration", RFC 4862, 3306 DOI 10.17487/RFC4862, September 2007, 3307 . 3309 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3310 Extensions for Stateless Address Autoconfiguration in 3311 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3312 . 3314 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3315 (TLS) Protocol Version 1.2", RFC 5246, 3316 DOI 10.17487/RFC5246, August 2008, 3317 . 3319 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 3320 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 3321 . 3323 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3324 Housley, R., and W. Polk, "Internet X.509 Public Key 3325 Infrastructure Certificate and Certificate Revocation List 3326 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3327 . 3329 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 3330 Security: An Unauthenticated Mode of IPsec", RFC 5386, 3331 DOI 10.17487/RFC5386, November 2008, 3332 . 3334 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3335 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3336 . 3338 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 3339 RFC 5660, DOI 10.17487/RFC5660, October 2009, 3340 . 3342 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3343 Verification of Domain-Based Application Service Identity 3344 within Internet Public Key Infrastructure Using X.509 3345 (PKIX) Certificates in the Context of Transport Layer 3346 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3347 2011, . 3349 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 3350 DOI 10.17487/RFC6762, February 2013, 3351 . 3353 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 3354 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 3355 . 3357 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3358 "Enrollment over Secure Transport", RFC 7030, 3359 DOI 10.17487/RFC7030, October 2013, 3360 . 3362 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3363 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 3364 2014, . 3366 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3367 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3368 . 3370 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 3371 RFC 7951, DOI 10.17487/RFC7951, August 2016, 3372 . 3374 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3375 "A Voucher Artifact for Bootstrapping Protocols", 3376 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3377 . 3379 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 3380 Control Plane for Stable Connectivity of Network 3381 Operations, Administration, and Maintenance (OAM)", 3382 RFC 8368, DOI 10.17487/RFC8368, May 2018, 3383 . 3385 12.2. Informative References 3387 [Dingledine2004] 3388 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 3389 second-generation onion router", 2004, 3390 . 3392 [docsisroot] 3393 "CableLabs Digital Certificate Issuance Service", February 3394 2018, . 3397 [I-D.ietf-ace-coap-est] 3398 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 3399 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 3400 est-10 (work in progress), March 2019. 3402 [I-D.ietf-anima-constrained-voucher] 3403 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 3404 Voucher Artifacts for Bootstrapping Protocols", draft- 3405 ietf-anima-constrained-voucher-03 (work in progress), 3406 March 2019. 3408 [I-D.ietf-anima-reference-model] 3409 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 3410 and J. Nobre, "A Reference Model for Autonomic 3411 Networking", draft-ietf-anima-reference-model-10 (work in 3412 progress), November 2018. 3414 [I-D.ietf-anima-stable-connectivity] 3415 Eckert, T. and M. Behringer, "Using Autonomic Control 3416 Plane for Stable Connectivity of Network OAM", draft-ietf- 3417 anima-stable-connectivity-10 (work in progress), February 3418 2018. 3420 [I-D.ietf-cbor-cddl] 3421 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 3422 definition language (CDDL): a notational convention to 3423 express CBOR and JSON data structures", draft-ietf-cbor- 3424 cddl-08 (work in progress), March 2019. 3426 [I-D.ietf-netconf-zerotouch] 3427 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 3428 Touch Provisioning (SZTP)", draft-ietf-netconf- 3429 zerotouch-29 (work in progress), January 2019. 3431 [I-D.ietf-opsawg-mud] 3432 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 3433 Description Specification", draft-ietf-opsawg-mud-25 (work 3434 in progress), June 2018. 3436 [I-D.richardson-anima-state-for-joinrouter] 3437 Richardson, M., "Considerations for stateful vs stateless 3438 join router in ANIMA bootstrap", draft-richardson-anima- 3439 state-for-joinrouter-02 (work in progress), January 2018. 3441 [imprinting] 3442 "Wikipedia article: Imprinting", July 2015, 3443 . 3445 [IoTstrangeThings] 3446 "IoT of toys stranger than fiction: Cybersecurity and data 3447 privacy update (accessed 2018-12-02)", March 2017, 3448 . 3451 [livingwithIoT] 3452 "What is it actually like to live in a house filled with 3453 IoT devices? (accessed 2018-12-02)", February 2018, 3454 . 3457 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3458 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 3459 December 1998, . 3461 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3462 Translator (NAT) Terminology and Considerations", 3463 RFC 2663, DOI 10.17487/RFC2663, August 1999, 3464 . 3466 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3467 Uniform Resource Identifiers (URIs)", RFC 5785, 3468 DOI 10.17487/RFC5785, April 2010, 3469 . 3471 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3472 Galperin, S., and C. Adams, "X.509 Internet Public Key 3473 Infrastructure Online Certificate Status Protocol - OCSP", 3474 RFC 6960, DOI 10.17487/RFC6960, June 2013, 3475 . 3477 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 3478 Multiple Certificate Status Request Extension", RFC 6961, 3479 DOI 10.17487/RFC6961, June 2013, 3480 . 3482 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 3483 Interface Identifiers with IPv6 Stateless Address 3484 Autoconfiguration (SLAAC)", RFC 7217, 3485 DOI 10.17487/RFC7217, April 2014, 3486 . 3488 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 3489 Constrained-Node Networks", RFC 7228, 3490 DOI 10.17487/RFC7228, May 2014, 3491 . 3493 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3494 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 3495 DOI 10.17487/RFC7231, June 2014, 3496 . 3498 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 3499 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 3500 2014, . 3502 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 3503 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 3504 December 2014, . 3506 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 3507 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 3508 Networking: Definitions and Design Goals", RFC 7575, 3509 DOI 10.17487/RFC7575, June 2015, 3510 . 3512 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3513 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3514 . 3516 [slowloris] 3517 "Slowloris (computer security)", February 2019, 3518 . 3521 [Stajano99theresurrecting] 3522 Stajano, F. and R. Anderson, "The resurrecting duckling: 3523 security issues for ad-hoc wireless networks", 1999, 3524 . 3527 [TR069] "TR-69: CPE WAN Management Protocol", February 2018, 3528 . 3531 Appendix A. IPv4 and non-ANI operations 3533 The secification of BRSKI in Section 4 intentionally only covers the 3534 mechanisms for an IPv6 pledge using Link-Local addresses. This 3535 section describes non-normative extensions that can be used in other 3536 environments. 3538 A.1. IPv4 Link Local addresses 3540 Instead of an IPv6 link-local address, an IPv4 address may be 3541 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 3542 Addresses. 3544 In the case that an IPv4 Link-Local address is formed, then the 3545 bootstrap process would continue as in the IPv6 case by looking for a 3546 (circuit) proxy. 3548 A.2. Use of DHCPv4 3550 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 3551 provided parameters for the Domain Name System can be used to perform 3552 DNS operations if all local discovery attempts fail. 3554 Appendix B. mDNS / DNSSD proxy discovery options 3556 Pledge discovery of the proxy (Section 4.1) MAY be performed with 3557 DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to 3558 discover the proxy at "_brski-proxy._tcp.local.". 3560 Proxy discovery of the registrar (Section 4.3) MAY be performed with 3561 DNS-based Service Discovery over Multicast DNS to discover registrars 3562 by searching for the service "_brski-registrar._tcp.local.". 3564 To prevent unaccceptable levels of network traffic, when using mDNS, 3565 the congestion avoidance mechanisms specified in [RFC6762] section 7 3566 MUST be followed. The pledge SHOULD listen for an unsolicited 3567 broadcast response as described in [RFC6762]. This allows devices to 3568 avoid announcing their presence via mDNS broadcasts and instead 3569 silently join a network by watching for periodic unsolicited 3570 broadcast responses. 3572 Discovery of registrar MAY also be performed with DNS-based service 3573 discovery by searching for the service "_brski- 3574 registrar._tcp.example.com". In this case the domain "example.com" 3575 is discovered as described in [RFC6763] section 11 (Appendix A.2 3576 suggests the use of DHCP parameters). 3578 If no local proxy or registrar service is located using the GRASP 3579 mechanisms or the above mentioned DNS-based Service Discovery methods 3580 the pledge MAY contact a well known manufacturer provided 3581 bootstrapping server by performing a DNS lookup using a well known 3582 URI such as "brski-registrar.manufacturer.example.com". The details 3583 of the URI are manufacturer specific. Manufacturers that leverage 3584 this method on the pledge are responsible for providing the registrar 3585 service. Also see Section 2.7. 3587 The current DNS services returned during each query are maintained 3588 until bootstrapping is completed. If bootstrapping fails and the 3589 pledge returns to the Discovery state, it picks up where it left off 3590 and continues attempting bootstrapping. For example, if the first 3591 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 3592 second and third responses are tried. If these fail the pledge moves 3593 on to normal DNS-based Service Discovery. 3595 Appendix C. MUD Extension 3597 The following extension augments the MUD model to include a single 3598 node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the 3599 following sample module that has the following tree structure: 3601 module: ietf-mud-brski-masa 3602 augment /ietf-mud:mud: 3603 +--rw masa-server? inet:uri 3605 The model is defined as follows: 3607 file "ietf-mud-extension@2018-02-14.yang" 3608 module ietf-mud-brski-masa { 3609 yang-version 1.1; 3610 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 3611 prefix ietf-mud-brski-masa; 3612 import ietf-mud { 3613 prefix ietf-mud; 3614 } 3615 import ietf-inet-types { 3616 prefix inet; 3617 } 3619 organization 3620 "IETF ANIMA (Autonomic Networking Integrated Model and 3621 Approach) Working Group"; 3622 contact 3623 "WG Web: http://tools.ietf.org/wg/anima/ 3624 WG List: anima@ietf.org 3625 "; 3626 description 3627 "BRSKI extension to a MUD file to indicate the 3628 MASA URL."; 3630 revision 2018-02-14 { 3631 description 3632 "Initial revision."; 3633 reference 3634 "RFC XXXX: Manufacturer Usage Description 3635 Specification"; 3636 } 3638 augment "/ietf-mud:mud" { 3639 description 3640 "BRSKI extension to a MUD file to indicate the 3641 MASA URL."; 3642 leaf masa-server { 3643 type inet:uri; 3644 description 3645 "This value is the URI of the MASA server"; 3646 } 3647 } 3648 } 3649 3651 The MUD extensions string "masa" is defined, and MUST be included in 3652 the extensions array of the mud container of a MUD file when this 3653 extension is used. 3655 Appendix D. Example Vouchers 3657 Three entities are involved in a voucher: the MASA issues (signs) it, 3658 the registrar's public key is mentioned in the voucher, and the 3659 pledge validates it. In order to provide reproduceable examples the 3660 public and private keys for an example MASA and registrar are first 3661 listed. 3663 D.1. Keys involved 3665 The Manufacturer has a Certificate Authority that signs the pledge's 3666 IDevID. In addition the Manufacturer's signing authority (the MASA) 3667 signs the vouchers, and that certificate must distributed to the 3668 devices at manufacturing time so that vouchers can be validated. 3670 D.1.1. MASA key pair for voucher signatures 3672 This private key signs vouchers: 3674 -----BEGIN EC PRIVATE KEY----- 3675 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 3676 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 3677 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 3678 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 3679 -----END EC PRIVATE KEY----- 3681 This public key validates vouchers: 3683 -----BEGIN CERTIFICATE----- 3684 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3685 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3686 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 3687 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 3688 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 3689 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 3690 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 3691 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 3692 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 3693 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 3694 -----END CERTIFICATE----- 3696 D.1.2. Manufacturer key pair for IDevID signatures 3698 This private key signs IDevID certificates: 3700 -----BEGIN EC PRIVATE KEY----- 3701 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 3702 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 3703 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 3704 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 3705 -----END EC PRIVATE KEY----- 3707 This public key validates IDevID certificates: 3709 -----BEGIN CERTIFICATE----- 3710 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3711 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3712 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 3713 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 3714 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 3715 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 3716 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 3717 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 3718 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 3719 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 3720 -----END CERTIFICATE----- 3722 D.1.3. Registrar key pair 3724 The registrar key (or chain) is the representative of the domain 3725 owner. This key signs registrar voucher-requests: 3727 -----BEGIN EC PRIVATE KEY----- 3728 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 3729 AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g 3730 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 3731 -----END EC PRIVATE KEY----- 3733 The public key is indicated in a pledge voucher-request to show 3734 proximity. 3736 -----BEGIN CERTIFICATE----- 3737 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC 3738 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n 3739 IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 3740 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw 3741 EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N 3742 w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ 3743 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 3744 /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC 3745 MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR 3746 c3o= 3747 -----END CERTIFICATE----- 3748 The registrar public certificate as decoded by openssl's x509 3749 utility. Note that the registrar certificate is marked with the 3750 cmcRA extension. 3752 Certificate: 3753 Data: 3754 Version: 3 (0x2) 3755 Serial Number: 3 (0x3) 3756 Signature Algorithm: ecdsa-with-SHA384 3757 Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA 3758 Validity 3759 Not Before: Sep 5 01:12:45 2017 GMT 3760 Not After : Sep 5 01:12:45 2019 GMT 3761 Subject: DC=ca, DC=sandelman, CN=localhost 3762 Subject Public Key Info: 3763 Public Key Algorithm: id-ecPublicKey 3764 Public-Key: (256 bit) 3765 pub: 3766 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 3767 8:17: 3768 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 3769 3:3e: 3770 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 3771 9:ba: 3772 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 3773 f:96: 3774 e9:9d:e2:bc:b2 3775 ASN1 OID: prime256v1 3776 X509v3 extensions: 3777 X509v3 Basic Constraints: 3778 CA:FALSE 3779 Signature Algorithm: ecdsa-with-SHA384 3780 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 3781 5b: 3782 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 3783 b6: 3784 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 3785 02: 3786 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 3787 c3: 3788 ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: 3789 4b: 3790 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 3792 D.1.4. Pledge key pair 3794 The pledge has an IDevID key pair built in at manufacturing time: 3796 -----BEGIN EC PRIVATE KEY----- 3797 MHcCAQEEIBgR6SV+uEvWfl5zCQWZxWjYbMhXPyNqdHJ3KPh11mm4oAoGCCqGSM49 3798 AwEHoUQDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 3799 KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6Tw== 3800 -----END EC PRIVATE KEY----- 3802 The public key is used by the registrar to find the MASA. The MASA 3803 URL is in an extension described in Section 2.3. 3805 -----BEGIN CERTIFICATE----- 3806 MIICBDCCAYugAwIBAgIECe20qTAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB 3807 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry 3808 dW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa 3809 MBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJkMFkwEwYHKoZIzj0CAQYIKoZI 3810 zj0DAQcDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 3811 KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6T6OBhzCBhDAdBgNVHQ4EFgQUj8KYdUoE 3812 OvJ0kcOIbjEWwgWdDYkwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S 3813 AaATDBEwMC1EMC1FNS0wMi0wMC0yRDArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l 3814 eWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNnADBkAjAmvMjmNgjypDhc 3815 fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F 3816 z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg== 3817 -----END CERTIFICATE----- 3819 The pledge public certificate as decoded by openssl's x509 utility so 3820 that the extensions can be seen. There is a second Custom Extension 3821 is included to provided to contain the EUI48/EUI64 that the pledge 3822 will configure as it's layer-2 address (this is non-normative). 3824 Certificate: 3825 Data: 3826 Version: 3 (0x2) 3827 Serial Number: 166573225 (0x9edb4a9) 3828 Signature Algorithm: ecdsa-with-SHA256 3829 Issuer: DC = ca, DC = sandelman, CN = Unstrung Highway CA 3830 Validity 3831 Not Before: Apr 24 02:16:58 2019 GMT 3832 Not After : Dec 31 00:00:00 2999 GMT 3833 Subject: serialNumber = 00-d0-e5-02-00-2d 3834 Subject Public Key Info: 3835 Public Key Algorithm: id-ecPublicKey 3836 Public-Key: (256 bit) 3837 pub: 3838 04:5a:2f:e3:a8:fa:51:27:42:60:5a:08:59:46:07: 3839 99:94:b2:ae:b5:b5:d5:8e:69:c7:6f:ed:40:61:a1: 3840 05:fd:84:23:13:68:39:15:95:7c:2a:38:91:fd:b9: 3841 04:97:e9:7c:33:8a:27:20:2e:ca:1d:a5:ca:2a:4b: 3842 9a:83:d4:ba:4f 3843 ASN1 OID: prime256v1 3844 NIST CURVE: P-256 3845 X509v3 extensions: 3846 X509v3 Subject Key Identifier: 3847 8F:C2:98:75:4A:04:3A:F2:74:91:C3:88:6E:31:16:C2:05:9D:0D:89 3848 X509v3 Basic Constraints: 3849 CA:FALSE 3850 X509v3 Subject Alternative Name: 3851 othername: 3852 1.3.6.1.4.1.46930.2: 3853 ..masa.honeydukes.sandelman.ca 3854 Signature Algorithm: ecdsa-with-SHA256 3855 30:64:02:30:26:bc:c8:e6:36:08:f2:a4:38:5c:7f:29:cc:57: 3856 79:0c:b8:8a:52:2a:b6:33:45:6a:f8:83:73:ed:4f:05:c3:b0: 3857 07:b4:a2:2b:53:4e:3e:10:b5:4d:5b:6a:38:4e:7d:39:02:30: 3858 63:0d:6e:c5:b6:43:8d:45:cf:db:7a:3c:35:5d:b4:e2:9a:6c: 3859 16:c0:3f:54:55:a0:54:e5:0d:0b:8e:f6:79:8b:cd:be:64:53: 3860 e7:14:a8:2b:4f:44:56:41:51:73:f7:92 3862 D.2. Example process 3864 RFC-EDITOR: these examples will need to be replaced with CMS versions 3865 once IANA has assigned the eContentType in [RFC8366]. 3867 D.2.1. Pledge to Registrar 3869 As described in Section 5.2, the pledge will sign a pledge voucher- 3870 request containing the registrar's public key in the proximity- 3871 registrar-cert field. The base64 has been wrapped at 60 characters 3872 for presentation reasons. 3874 MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC 3875 Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 3876 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 3877 OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw 3878 LTAyIiwibm9uY2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGlt 3879 aXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFL 3880 QmdncWhrak9QUVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH 3881 VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJB 3882 TU1GRlZ1YzNSeWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRB 3883 eE1USTBOVm9YRFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21U 3884 OGl4a0FSa1dBbU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNi 3885 V0Z1TVJJd0VBWURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BR 3886 SUJCZ2dxaGtqT1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3Ra 3887 OTR3YUFJVjBpL29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgv 3888 d2ZBcFI2c3ZsdW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdT 3889 TTQ5QkFNREEya0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FD 3890 NnFqSWVZMmprRHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjll 3891 ZmJUTGJkdERrM3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0 3892 MWx5Rk0rMGZZcFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqG 3893 SM49BAMCME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkW 3894 CXNhbmRlbG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0x 3895 NzEwMTIxMzUyNTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixk 3896 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEw 3897 MC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmn 3898 mLR1TVpSdHa7zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE 3899 98ZnyFT+chS96rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoT 3900 thVfOQvtdkMqMAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGg 3901 EwwRMDAtRDAtRTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8v 3902 aGlnaHdheS5zYW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355 3903 qdbVT97mqgxIa9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIx 3904 AKvW7G91h4qruZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkA 3905 FvuwDDGCAaUwggGhAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 3906 CZImiZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdo 3907 d2F5IENBAgEMMA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkq 3908 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjE3NTQzMFowLwYJKoZI 3909 hvcNAQkEMSIEIP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkG 3910 CSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglg 3911 hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 3912 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEYw 3913 RAIgYUy0NTdP+xTkm/Et69eI++S/2z3dQwPKOwdL0cDCSvACIAh3jJbybMnK 3914 cf7DKKnsn2G/O06HeB/8imMI+hnA7CfN 3916 file: examples/vr_00-D0-E5-F2-00-02.pkcs 3918 The ASN1 decoding of the artifact: 3920 0:d=0 hl=4 l=1820 cons: SEQUENCE 3921 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 3922 Data 3923 15:d=1 hl=4 l=1805 cons: cont [ 0 ] 3924 19:d=2 hl=4 l=1801 cons: SEQUENCE 3925 23:d=3 hl=2 l= 1 prim: INTEGER :01 3926 26:d=3 hl=2 l= 15 cons: SET 3927 28:d=4 hl=2 l= 13 cons: SEQUENCE 3928 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 3929 41:d=5 hl=2 l= 0 prim: NULL 3930 43:d=3 hl=4 l= 782 cons: SEQUENCE 3931 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 3932 58:d=4 hl=4 l= 767 cons: cont [ 0 ] 3933 62:d=5 hl=4 l= 763 prim: OCTET STRING :{"ietf-vouch 3934 er-request:voucher":{"assertion":"proximity","created-on":"2 3935 017-09-01","serial-number":"00-D0-E5-F2-00-02","nonce":"Dss9 3936 9sBr3pNMOACe-LYY7w","proximity-registrar-cert":"MIIBrjCCATOg 3937 AwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAX 3938 BgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5nIEZv 3939 dW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 3940 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFu 3941 MRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC 3942 AAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/p 3943 uhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49 3944 BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNi 3945 fVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR 3946 54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 3947 829:d=3 hl=4 l= 566 cons: cont [ 0 ] 3948 833:d=4 hl=4 l= 562 cons: SEQUENCE 3949 837:d=5 hl=4 l= 439 cons: SEQUENCE 3950 841:d=6 hl=2 l= 3 cons: cont [ 0 ] 3951 843:d=7 hl=2 l= 1 prim: INTEGER :02 3952 846:d=6 hl=2 l= 1 prim: INTEGER :0C 3953 849:d=6 hl=2 l= 10 cons: SEQUENCE 3954 851:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3955 HA256 3956 861:d=6 hl=2 l= 77 cons: SEQUENCE 3957 863:d=7 hl=2 l= 18 cons: SET 3958 865:d=8 hl=2 l= 16 cons: SEQUENCE 3959 867:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3960 ent 3961 879:d=9 hl=2 l= 2 prim: IA5STRING :ca 3962 883:d=7 hl=2 l= 25 cons: SET 3963 885:d=8 hl=2 l= 23 cons: SEQUENCE 3964 887:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3965 ent 3966 899:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3967 910:d=7 hl=2 l= 28 cons: SET 3968 912:d=8 hl=2 l= 26 cons: SEQUENCE 3969 914:d=9 hl=2 l= 3 prim: OBJECT :commonName 3970 919:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 3971 hway CA 3972 940:d=6 hl=2 l= 32 cons: SEQUENCE 3973 942:d=7 hl=2 l= 13 prim: UTCTIME :171012135252 3974 Z 3975 957:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :299912310000 3976 00Z 3977 974:d=6 hl=2 l= 75 cons: SEQUENCE 3978 976:d=7 hl=2 l= 18 cons: SET 3979 978:d=8 hl=2 l= 16 cons: SEQUENCE 3980 980:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3981 ent 3982 992:d=9 hl=2 l= 2 prim: IA5STRING :ca 3983 996:d=7 hl=2 l= 25 cons: SET 3984 998:d=8 hl=2 l= 23 cons: SEQUENCE 3985 1000:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3986 ent 3987 1012:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3988 1023:d=7 hl=2 l= 26 cons: SET 3989 1025:d=8 hl=2 l= 24 cons: SEQUENCE 3990 1027:d=9 hl=2 l= 3 prim: OBJECT :commonName 3991 1032:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2- 3992 00-02 3993 1051:d=6 hl=2 l= 89 cons: SEQUENCE 3994 1053:d=7 hl=2 l= 19 cons: SEQUENCE 3995 1055:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 3996 ey 3997 1064:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 3998 1074:d=7 hl=2 l= 66 prim: BIT STRING 3999 1142:d=6 hl=3 l= 135 cons: cont [ 3 ] 4000 1145:d=7 hl=3 l= 132 cons: SEQUENCE 4001 1148:d=8 hl=2 l= 29 cons: SEQUENCE 4002 1150:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subje 4003 ct Key Identifier 4004 1155:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04 4005 141D311661B611509B3CFA13B6155F390BED76432A 4006 1179:d=8 hl=2 l= 9 cons: SEQUENCE 4007 1181:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 4008 Constraints 4009 1186:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 4010 00 4011 1190:d=8 hl=2 l= 43 cons: SEQUENCE 4012 1192:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subje 4013 ct Alternative Name 4014 1197:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:30 4015 22A02006092B0601040182EE5201A0130C1130302D44302D45352D46322D 4016 30302D3032 4017 1235:d=8 hl=2 l= 43 cons: SEQUENCE 4018 1237:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1. 4019 46930.2 4020 1248:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C 4021 1C68747470733A2F2F686967687761792E73616E64656C6D616E2E6361 4022 1280:d=5 hl=2 l= 10 cons: SEQUENCE 4023 1282:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4024 HA256 4025 1292:d=5 hl=2 l= 105 prim: BIT STRING 4026 1399:d=3 hl=4 l= 421 cons: SET 4027 1403:d=4 hl=4 l= 417 cons: SEQUENCE 4028 1407:d=5 hl=2 l= 1 prim: INTEGER :01 4029 1410:d=5 hl=2 l= 82 cons: SEQUENCE 4030 1412:d=6 hl=2 l= 77 cons: SEQUENCE 4031 1414:d=7 hl=2 l= 18 cons: SET 4032 1416:d=8 hl=2 l= 16 cons: SEQUENCE 4033 1418:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4034 ent 4035 1430:d=9 hl=2 l= 2 prim: IA5STRING :ca 4036 1434:d=7 hl=2 l= 25 cons: SET 4037 1436:d=8 hl=2 l= 23 cons: SEQUENCE 4038 1438:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4039 ent 4040 1450:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4041 1461:d=7 hl=2 l= 28 cons: SET 4042 1463:d=8 hl=2 l= 26 cons: SEQUENCE 4043 1465:d=9 hl=2 l= 3 prim: OBJECT :commonName 4044 1470:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4045 hway CA 4046 1491:d=6 hl=2 l= 1 prim: INTEGER :0C 4047 1494:d=5 hl=2 l= 13 cons: SEQUENCE 4048 1496:d=6 hl=2 l= 9 prim: OBJECT :sha256 4049 1507:d=6 hl=2 l= 0 prim: NULL 4050 1509:d=5 hl=3 l= 228 cons: cont [ 0 ] 4051 1512:d=6 hl=2 l= 24 cons: SEQUENCE 4052 1514:d=7 hl=2 l= 9 prim: OBJECT :contentType 4053 1525:d=7 hl=2 l= 11 cons: SET 4054 1527:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4055 1538:d=6 hl=2 l= 28 cons: SEQUENCE 4056 1540:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4057 1551:d=7 hl=2 l= 15 cons: SET 4058 1553:d=8 hl=2 l= 13 prim: UTCTIME :171012175430 4059 Z 4060 1568:d=6 hl=2 l= 47 cons: SEQUENCE 4061 1570:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 4062 t 4063 1581:d=7 hl=2 l= 34 cons: SET 4064 1583:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:FE 4065 7D72E29500F90A38E95021A215FD6D40B1629B99598177DC054AE0F9C8B6 4066 9F 4067 1617:d=6 hl=2 l= 121 cons: SEQUENCE 4068 1619:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 4069 ilities 4070 1630:d=7 hl=2 l= 108 cons: SET 4071 1632:d=8 hl=2 l= 106 cons: SEQUENCE 4072 1634:d=9 hl=2 l= 11 cons: SEQUENCE 4073 1636:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 4074 1647:d=9 hl=2 l= 11 cons: SEQUENCE 4075 1649:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 4076 1660:d=9 hl=2 l= 11 cons: SEQUENCE 4077 1662:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 4078 1673:d=9 hl=2 l= 10 cons: SEQUENCE 4079 1675:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 4080 1685:d=9 hl=2 l= 14 cons: SEQUENCE 4081 1687:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4082 1697:d=10 hl=2 l= 2 prim: INTEGER :80 4083 1701:d=9 hl=2 l= 13 cons: SEQUENCE 4084 1703:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4085 1713:d=10 hl=2 l= 1 prim: INTEGER :40 4086 1716:d=9 hl=2 l= 7 cons: SEQUENCE 4087 1718:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 4088 1725:d=9 hl=2 l= 13 cons: SEQUENCE 4089 1727:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4090 1737:d=10 hl=2 l= 1 prim: INTEGER :28 4091 1740:d=5 hl=2 l= 10 cons: SEQUENCE 4092 1742:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4093 HA256 4094 1752:d=5 hl=2 l= 70 prim: OCTET STRING [HEX DUMP]:30 4095 440220614CB435374FFB14E49BF12DEBD788FBE4BFDB3DDD4303CA3B074B 4096 D1C0C24AF0022008778C96F26CC9CA71FEC328A9EC9F61BF3B4E87781FFC 4097 8A6308FA19C0EC27CD 4099 The JSON contained in the voucher request: 4101 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr 4102 eated-on":"2017-09-01","serial-number":"00-D0-E5-F2-00-02"," 4103 nonce":"Dss99sBr3pNMOACe-LYY7w","proximity-registrar-cert":" 4104 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQB 4105 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVu 4106 c3RydW5nIEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAx 4107 MTI0NVowQzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJ 4108 c2FuZGVsbWFuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggq 4109 hkjOPQMBBwNCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6 4110 MwF5z+Dpb8/puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAA 4111 MAoGCCqGSM49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY 4112 2jkDx062nuNifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77 4113 XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 4115 D.2.2. Registrar to MASA 4117 As described in Section 5.5 the registrar will sign a registrar 4118 voucher-request, and will include pledge's voucher request in the 4119 prior-signed-voucher-request. 4121 MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC 4122 Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 4123 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 4124 OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi 4125 SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu 4126 ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI 4127 RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT 4128 SWIzRFFFSEFhQ0NBdjhFZ2dMN2V5SnBaWFJtTFhadmRXTm9aWEl0Y21WeGRX 4129 VnpkRHAyYjNWamFHVnlJanA3SW1GemMyVnlkR2x2YmlJNkluQnliM2hwYlds 4130 MGVTSXNJbU55WldGMFpXUXRiMjRpT2lJeU1ERTNMVEE1TFRBeElpd2ljMlZ5 4131 YVdGc0xXNTFiV0psY2lJNklqQXdMVVF3TFVVMUxVWXlMVEF3TFRBeUlpd2li 4132 bTl1WTJVaU9pSkVjM001T1hOQ2NqTndUazFQUVVObExVeFpXVGQzSWl3aWNI 4133 SnZlR2x0YVhSNUxYSmxaMmx6ZEhKaGNpMWpaWEowSWpvaVRVbEpRbkpxUTBO 4134 QlZFOW5RWGRKUWtGblNVSkJla0ZMUW1kbmNXaHJhazlRVVZGRVFYcENUMDFT 4135 U1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlExa3lSWGhIVkVGWVFtZHZT 4136 bXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRGbFhOSGhJVkVGaVFt 4137 ZE9Wa0pCVFUxR1JsWjFZek5TZVdSWE5XNUpSVnAyWkZjMU1GbFhiSFZKUlU1 4138 Q1RVSTBXRVJVUlROTlJHdDNUbFJCZUUxVVNUQk9WbTlZUkZSRk5VMUVhM2RP 4139 VkVGNFRWUkpNRTVXYjNkUmVrVlRUVUpCUjBObmJWTktiMjFVT0dsNGEwRlNh 4140 MWRCYlU1b1RWSnJkMFozV1V0RFdrbHRhVnBRZVV4SFVVSkhVbGxLWXpKR2RW 4141 cEhWbk5pVjBaMVRWSkpkMFZCV1VSV1VWRkVSRUZzYzJJeVRtaGlSMmgyWXpO 4142 UmQxZFVRVlJDWjJOeGFHdHFUMUJSU1VKQ1oyZHhhR3RxVDFCUlRVSkNkMDVE 4143 UVVGUk1WcEJOMDUzTUhoVFRTOVJNblV4T1RSR2VsRk5hM1JhT1RSM1lVRkpW 4144 akJwTDI5V1ZGQm5UMG80ZWxjMlRYZEdOWG9yUkhCaU9DOXdkV2hQWWtwTldq 4145 QlZOa2d2ZDJaQmNGSTJjM1pzZFcxa05ISjVlVzkzTUhkRGVrRktRbWRPVmto 4146 U1RVVkJha0ZCVFVGdlIwTkRjVWRUVFRRNVFrRk5SRUV5YTBGTlIxbERUVkZE 4147 TXk5cFZGRktNMlYyV1ZsaloySllhR0p0ZW5Kd05qUjBNMUZETm5GcVNXVlpN 4148 bXByUkhnd05qSnVkVTVwWmxaTGRIbGhZWEpoTTBZek1FRkphMHRUUlVOTlVV 4149 UnBNamxsWm1KVVRHSmtkRVJyTTNSbFkxa3Zja1EzVmpjM1dHRktObTVaUTIx 4150 a1JFTlNOVFJVY2xOR1RreG5lSFowTVd4NVJrMHJNR1paY0ZsU1l6TnZQU0o5 4151 ZmFDQ0FqWXdnZ0l5TUlJQnQ2QURBZ0VDQWdFTU1Bb0dDQ3FHU000OUJBTUNN 4152 RTB4RWpBUUJnb0praWFKay9Jc1pBRVpGZ0pqWVRFWk1CY0dDZ21TSm9tVDhp 4153 eGtBUmtXQ1hOaGJtUmxiRzFoYmpFY01Cb0dBMVVFQXd3VFZXNXpkSEoxYm1j 4154 Z1NHbG5hSGRoZVNCRFFUQWdGdzB4TnpFd01USXhNelV5TlRKYUdBOHlPVGs1 4155 TVRJek1UQXdNREF3TUZvd1N6RVNNQkFHQ2dtU0pvbVQ4aXhrQVJrV0FtTmhN 4156 Umt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdWc2JXRnVNUm93R0FZRFZR 4157 UUREQkV3TUMxRU1DMUZOUzFHTWkwd01DMHdNakJaTUJNR0J5cUdTTTQ5QWdF 4158 R0NDcUdTTTQ5QXdFSEEwSUFCRW1ubUxSMVRWcFNkSGE3ekF4SENDUTI2azFz 4159 MHp1YldmU2FQN1FvbG1Odzhpb2dQNjJzK05OS2h1MjRoMmxFOThabnlGVCtj 4160 aFM5NnJES2hnandFOXVqZ1ljd2dZUXdIUVlEVlIwT0JCWUVGQjB4Rm1HMkVW 4161 Q2JQUG9UdGhWZk9RdnRka01xTUFrR0ExVWRFd1FDTUFBd0t3WURWUjBSQkNR 4162 d0lxQWdCZ2tyQmdFRUFZTHVVZ0dnRXd3Uk1EQXRSREF0UlRVdFJqSXRNREF0 4163 TURJd0t3WUpLd1lCQkFHQzdsSUNCQjRNSEdoMGRIQnpPaTh2YUdsbmFIZGhl 4164 UzV6WVc1a1pXeHRZVzR1WTJFd0NnWUlLb1pJemowRUF3SURhUUF3WmdJeEFP 4165 RW5VMzU1cWRiVlQ5N21xZ3hJYTlTOVlkSHU2Snp4d2x1SHU5ZkxuelNjR3p4 4166 dWsyZnJTVC80ak84UlI2MHpNZ0l4QUt2VzdHOTFoNHFydVp0RmNKSGhrSW16 4167 RHJ0OG51UEpkbHNKUktLdjdmQUZQYjZWYUNETThOR0JnSGtBRnZ1d0RER0NB 4168 YVl3Z2dHaUFnRUJNRkl3VFRFU01CQUdDZ21TSm9tVDhpeGtBUmtXQW1OaE1S 4169 a3dGd1lLQ1pJbWlaUHlMR1FCR1JZSmMyRnVaR1ZzYldGdU1Sd3dHZ1lEVlFR 4170 RERCTlZibk4wY25WdVp5QklhV2RvZDJGNUlFTkJBZ0VNTUEwR0NXQ0dTQUZs 4171 QXdRQ0FRVUFvSUhrTUJnR0NTcUdTSWIzRFFFSkF6RUxCZ2txaGtpRzl3MEJC 4172 d0V3SEFZSktvWklodmNOQVFrRk1ROFhEVEUzTVRBeE1qRXpOVGd5TTFvd0x3 4173 WUpLb1pJaHZjTkFRa0VNU0lFSVA1OWN1S1ZBUGtLT09sUUlhSVYvVzFBc1dL 4174 Ym1WbUJkOXdGU3VENXlMYWZNSGtHQ1NxR1NJYjNEUUVKRHpGc01Hb3dDd1lK 4175 WUlaSUFXVURCQUVxTUFzR0NXQ0dTQUZsQXdRQkZqQUxCZ2xnaGtnQlpRTUVB 4176 UUl3Q2dZSUtvWklodmNOQXdjd0RnWUlLb1pJaHZjTkF3SUNBZ0NBTUEwR0ND 4177 cUdTSWIzRFFNQ0FnRkFNQWNHQlNzT0F3SUhNQTBHQ0NxR1NJYjNEUU1DQWdF 4178 b01Bb0dDQ3FHU000OUJBTUNCRWN3UlFJZ0VNZzFkSkw3RmNkdHJWRHg4cUNh 4179 em9lOSsyMk56NFp3UkI5Z0FUR0w3TU1DSVFEanNzVWxaekpxcDIva0NkNFdo 4180 eFVoc2FDcFRGd1Bybk5ldzV3Q2tZVUY4UT09In19oIIBsjCCAa4wggEzoAMC 4181 AQICAQMwCgYIKoZIzj0EAwMwTjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 4182 CZImiZPyLGQBGRYJc2FuZGVsbWFuMR0wGwYDVQQDDBRVbnN0cnVuZyBGb3Vu 4183 dGFpbiBDQTAeFw0xNzA5MDUwMTEyNDVaFw0xOTA5MDUwMTEyNDVaMEMxEjAQ 4184 BgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjES 4185 MBAGA1UEAwwJbG9jYWxob3N0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 4186 NWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g6W/P6boT 4187 myTGdFOh/8HwKUerL5bpneK8sqMNMAswCQYDVR0TBAIwADAKBggqhkjOPQQD 4188 AwNpADBmAjEAt/4k0Cd3r2GHIG14W5s66euLd0AuqoyHmNo5A8dOtp7jYn1S 4189 rcmmq2txd9ACJCkhAjEA4tvXn20y23bQ5N7XnGP6w+1e+12iep2ApnQwkeeE 4190 60hTS4Mb7dZchTPtH2KWEXN6MYIBpzCCAaMCAQEwUzBOMRIwEAYKCZImiZPy 4191 LGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMM 4192 FFVuc3RydW5nIEZvdW50YWluIENBAgEDMA0GCWCGSAFlAwQCAQUAoIHkMBgG 4193 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAy 4194 NjAxMzYxOFowLwYJKoZIhvcNAQkEMSIEIEQBM73PZzPo7tE9Mj8gQvaaYeMQ 4195 OsxlACaW/HenAqNwMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG 4196 CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN 4197 AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo 4198 MAoGCCqGSM49BAMCBEcwRQIgDdp5uPUlMKp7GFQAD7ypAgqFv8q+KkJt6c3O 4199 7iVpVI8CIQCD1u8BkxipvigwvIDmWfjlYdJxcvozNjffq5j3UHg7Rg== 4201 file: examples/parboiled_vr_00-D0-E5-F2-00-02.pkcs 4203 The ASN1 decoding of the artifact: 4205 0:d=0 hl=4 l=3546 cons: SEQUENCE 4206 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 4207 Data 4208 15:d=1 hl=4 l=3531 cons: cont [ 0 ] 4209 19:d=2 hl=4 l=3527 cons: SEQUENCE 4210 23:d=3 hl=2 l= 1 prim: INTEGER :01 4211 26:d=3 hl=2 l= 15 cons: SET 4212 28:d=4 hl=2 l= 13 cons: SEQUENCE 4213 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 4214 41:d=5 hl=2 l= 0 prim: NULL 4215 43:d=3 hl=4 l=2638 cons: SEQUENCE 4216 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 4217 58:d=4 hl=4 l=2623 cons: cont [ 0 ] 4218 62:d=5 hl=4 l=2619 prim: OCTET STRING :{"ietf-vouch 4219 er-request:voucher":{"assertion":"proximity","created-on":"2 4220 017-09-15T00:00:00.000Z","serial-number":"JADA123456789","no 4221 nce":"abcd1234","prior-signed-voucher-request":"MIIHHQYJKoZI 4222 hvcNAQcCoIIHDjCCBwoCAQExDzANBglghkgBZQMEAgEFADCCAw4GCSqGSIb3 4223 DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7 4224 ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24iOiIyMDE3LTA5 4225 LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9u 4226 Y2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGltaXR5LXJlZ2lz 4227 dHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFLQmdncWhrak9Q 4228 UVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtp 4229 YUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJBTU1GRlZ1YzNS 4230 eWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRBeE1USTBOVm9Y 4231 RFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21UOGl4a0FSa1dB 4232 bU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNiV0Z1TVJJd0VB 4233 WURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtq 4234 T1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3RaOTR3YUFJVjBp 4235 L29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgvd2ZBcFI2c3Zs 4236 dW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdTTTQ5QkFNREEy 4237 a0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FDNnFqSWVZMmpr 4238 RHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjllZmJUTGJkdERr 4239 M3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0MWx5Rk0rMGZZ 4240 cFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqGSM49BAMCME0x 4241 EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1h 4242 bjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0xNzEwMTIxMzUy 4243 NTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixkARkWAmNhMRkw 4244 FwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEwMC1EMC1FNS1G 4245 Mi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmnmLR1TVpSdHa7 4246 zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE98ZnyFT+chS9 4247 6rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoTthVfOQvtdkMq 4248 MAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGgEwwRMDAtRDAt 4249 RTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8vaGlnaHdheS5z 4250 YW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355qdbVT97mqgxI 4251 a9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIxAKvW7G91h4qr 4252 uZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkAFvuwDDGCAaYw 4253 ggGiAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 4254 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBAgEM 4255 MA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw 4256 HAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjEzNTgyM1owLwYJKoZIhvcNAQkEMSIE 4257 IP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkGCSqGSIb3DQEJ 4258 DzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw 4259 CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG 4260 BSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEcwRQIgEMg1dJL7 4261 FcdtrVDx8qCazoe9+22Nz4ZwRB9gATGL7MMCIQDjssUlZzJqp2/kCd4WhxUh 4262 saCpTFwPrnNew5wCkYUF8Q=="}} 4263 2685:d=3 hl=4 l= 434 cons: cont [ 0 ] 4264 2689:d=4 hl=4 l= 430 cons: SEQUENCE 4265 2693:d=5 hl=4 l= 307 cons: SEQUENCE 4266 2697:d=6 hl=2 l= 3 cons: cont [ 0 ] 4267 2699:d=7 hl=2 l= 1 prim: INTEGER :02 4268 2702:d=6 hl=2 l= 1 prim: INTEGER :03 4269 2705:d=6 hl=2 l= 10 cons: SEQUENCE 4270 2707:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4271 HA384 4272 2717:d=6 hl=2 l= 78 cons: SEQUENCE 4273 2719:d=7 hl=2 l= 18 cons: SET 4274 2721:d=8 hl=2 l= 16 cons: SEQUENCE 4275 2723:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4276 ent 4277 2735:d=9 hl=2 l= 2 prim: IA5STRING :ca 4278 2739:d=7 hl=2 l= 25 cons: SET 4279 2741:d=8 hl=2 l= 23 cons: SEQUENCE 4280 2743:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4281 ent 4282 2755:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4283 2766:d=7 hl=2 l= 29 cons: SET 4284 2768:d=8 hl=2 l= 27 cons: SEQUENCE 4285 2770:d=9 hl=2 l= 3 prim: OBJECT :commonName 4286 2775:d=9 hl=2 l= 20 prim: UTF8STRING :Unstrung Fou 4287 ntain CA 4288 2797:d=6 hl=2 l= 30 cons: SEQUENCE 4289 2799:d=7 hl=2 l= 13 prim: UTCTIME :170905011245 4290 Z 4291 2814:d=7 hl=2 l= 13 prim: UTCTIME :190905011245 4292 Z 4293 2829:d=6 hl=2 l= 67 cons: SEQUENCE 4294 2831:d=7 hl=2 l= 18 cons: SET 4295 2833:d=8 hl=2 l= 16 cons: SEQUENCE 4296 2835:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4297 ent 4298 2847:d=9 hl=2 l= 2 prim: IA5STRING :ca 4299 2851:d=7 hl=2 l= 25 cons: SET 4300 2853:d=8 hl=2 l= 23 cons: SEQUENCE 4301 2855:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4302 ent 4303 2867:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4304 2878:d=7 hl=2 l= 18 cons: SET 4305 2880:d=8 hl=2 l= 16 cons: SEQUENCE 4306 2882:d=9 hl=2 l= 3 prim: OBJECT :commonName 4307 2887:d=9 hl=2 l= 9 prim: UTF8STRING :localhost 4308 2898:d=6 hl=2 l= 89 cons: SEQUENCE 4309 2900:d=7 hl=2 l= 19 cons: SEQUENCE 4310 2902:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 4311 ey 4312 2911:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 4313 2921:d=7 hl=2 l= 66 prim: BIT STRING 4314 2989:d=6 hl=2 l= 13 cons: cont [ 3 ] 4315 2991:d=7 hl=2 l= 11 cons: SEQUENCE 4316 2993:d=8 hl=2 l= 9 cons: SEQUENCE 4317 2995:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 4318 Constraints 4319 3000:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 4320 00 4321 3004:d=5 hl=2 l= 10 cons: SEQUENCE 4322 3006:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4323 HA384 4324 3016:d=5 hl=2 l= 105 prim: BIT STRING 4325 3123:d=3 hl=4 l= 423 cons: SET 4326 3127:d=4 hl=4 l= 419 cons: SEQUENCE 4327 3131:d=5 hl=2 l= 1 prim: INTEGER :01 4328 3134:d=5 hl=2 l= 83 cons: SEQUENCE 4329 3136:d=6 hl=2 l= 78 cons: SEQUENCE 4330 3138:d=7 hl=2 l= 18 cons: SET 4331 3140:d=8 hl=2 l= 16 cons: SEQUENCE 4332 3142:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4333 ent 4334 3154:d=9 hl=2 l= 2 prim: IA5STRING :ca 4335 3158:d=7 hl=2 l= 25 cons: SET 4336 3160:d=8 hl=2 l= 23 cons: SEQUENCE 4337 3162:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4338 ent 4339 3174:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4340 3185:d=7 hl=2 l= 29 cons: SET 4341 3187:d=8 hl=2 l= 27 cons: SEQUENCE 4342 3189:d=9 hl=2 l= 3 prim: OBJECT :commonName 4343 3194:d=9 hl=2 l= 20 prim: UTF8STRING :Unstrung Fou 4344 ntain CA 4345 3216:d=6 hl=2 l= 1 prim: INTEGER :03 4346 3219:d=5 hl=2 l= 13 cons: SEQUENCE 4347 3221:d=6 hl=2 l= 9 prim: OBJECT :sha256 4348 3232:d=6 hl=2 l= 0 prim: NULL 4349 3234:d=5 hl=3 l= 228 cons: cont [ 0 ] 4350 3237:d=6 hl=2 l= 24 cons: SEQUENCE 4351 3239:d=7 hl=2 l= 9 prim: OBJECT :contentType 4352 3250:d=7 hl=2 l= 11 cons: SET 4353 3252:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4354 3263:d=6 hl=2 l= 28 cons: SEQUENCE 4355 3265:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4356 3276:d=7 hl=2 l= 15 cons: SET 4357 3278:d=8 hl=2 l= 13 prim: UTCTIME :171026013618 4358 Z 4359 3293:d=6 hl=2 l= 47 cons: SEQUENCE 4360 3295:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 4361 t 4362 3306:d=7 hl=2 l= 34 cons: SET 4363 3308:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:44 4364 0133BDCF6733E8EED13D323F2042F69A61E3103ACC65002696FC77A702A3 4365 70 4366 3342:d=6 hl=2 l= 121 cons: SEQUENCE 4367 3344:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 4368 ilities 4369 3355:d=7 hl=2 l= 108 cons: SET 4370 3357:d=8 hl=2 l= 106 cons: SEQUENCE 4371 3359:d=9 hl=2 l= 11 cons: SEQUENCE 4372 3361:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 4373 3372:d=9 hl=2 l= 11 cons: SEQUENCE 4374 3374:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 4375 3385:d=9 hl=2 l= 11 cons: SEQUENCE 4376 3387:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 4377 3398:d=9 hl=2 l= 10 cons: SEQUENCE 4378 3400:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 4379 3410:d=9 hl=2 l= 14 cons: SEQUENCE 4380 3412:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4381 3422:d=10 hl=2 l= 2 prim: INTEGER :80 4382 3426:d=9 hl=2 l= 13 cons: SEQUENCE 4383 3428:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4384 3438:d=10 hl=2 l= 1 prim: INTEGER :40 4385 3441:d=9 hl=2 l= 7 cons: SEQUENCE 4386 3443:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 4387 3450:d=9 hl=2 l= 13 cons: SEQUENCE 4388 3452:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4389 3462:d=10 hl=2 l= 1 prim: INTEGER :28 4390 3465:d=5 hl=2 l= 10 cons: SEQUENCE 4391 3467:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4392 HA256 4393 3477:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30 4394 4502200DDA79B8F52530AA7B1854000FBCA9020A85BFCABE2A426DE9CDCE 4395 EE2569548F02210083D6EF019318A9BE2830BC80E659F8E561D27172FA33 4396 3637DFAB98F750783B46 4398 D.2.3. MASA to Registrar 4400 The MASA will return a voucher to the registrar, to be relayed to the 4401 pledge. 4403 MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC 4404 AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6 4405 eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x 4406 MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt 4407 RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci 4408 LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6 4409 QUtCZ2dxaGtqT1BRUURBekJPTVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJF 4410 eEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eEhUQWJCZ05W 4411 QkFNTUZGVnVjM1J5ZFc1bklFWnZkVzUwWVdsdUlFTkJNQjRYRFRFM01Ea3dO 4412 VEF4TVRJME5Wb1hEVEU1TURrd05UQXhNVEkwTlZvd1F6RVNNQkFHQ2dtU0pv 4413 bVQ4aXhrQVJrV0FtTmhNUmt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdW 4414 c2JXRnVNUkl3RUFZRFZRUUREQWxzYjJOaGJHaHZjM1F3V1RBVEJnY3Foa2pP 4415 UFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVExWkE3TncweFNNL1EydTE5NEZ6UU1r 4416 dFo5NHdhQUlWMGkvb1ZUUGdPSjh6VzZNd0Y1eitEcGI4L3B1aE9iSk1aMFU2 4417 SC93ZkFwUjZzdmx1bWQ0cnl5b3cwd0N6QUpCZ05WSFJNRUFqQUFNQW9HQ0Nx 4418 R1NNNDlCQU1EQTJrQU1HWUNNUUMzL2lUUUozZXZZWWNnYlhoYm16cnA2NHQz 4419 UUM2cWpJZVkyamtEeDA2Mm51TmlmVkt0eWFhcmEzRjMwQUlrS1NFQ01RRGky 4420 OWVmYlRMYmR0RGszdGVjWS9yRDdWNzdYYUo2bllDbWREQ1I1NFRyU0ZOTGd4 4421 dnQxbHlGTSswZllwWVJjM289In19oIIB0zCCAc8wggFWoAMCAQICAQEwCgYI 4422 KoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 4423 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBMB4X 4424 DTE3MDMyNjE2MTk0MFoXDTE5MDMyNjE2MTk0MFowRzESMBAGCgmSJomT8ixk 4425 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRYwFAYDVQQDDA1V 4426 bnN0cnVuZyBNQVNBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2QB90W9hbyCT 4427 p7bPr17llt+aH8jWwh84wMzotpFmRRNQcrqyiJjXDTBRoqxp0VyFxqlgn8OS 4428 AoCfArjN71ebcvW3+ylJTpHo8077/uT1fvnpZD/R0PN76kwMLNlsFk8SoxAw 4429 DjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAMCA2cAMGQCMBm9KMjNHaD+rd/y 4430 0jy+Tg7mrRMDGIe1hjviGExwvCuxMhwTpgmEXik9vhoVfwi1swIwTculDCU7 4431 dbbMSbCanTD1CBY/uMGYNQDiG/yaAOjO6996cC0E6x0cRM1TBn1jpGFMMYIB 4432 xjCCAcICAQEwUjBNMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/Is 4433 ZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EC 4434 AQEwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH 4435 ATAcBgkqhkiG9w0BCQUxDxcNMTcxMDEyMTc1NDMxWjAvBgkqhkiG9w0BCQQx 4436 IgQgQXnG628cIW8MoYfB1ljDDlLlJQlxED2tnjcvkLEfix0weQYJKoZIhvcN 4437 AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB 4438 AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw 4439 BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIzj0EAwIEZzBlAjEAhzid 4440 /AkNjttpSP1rflNppdHsi324Z2+TXJxueewnJ8z/2NXb+Tf3DsThv7du00Oz 4441 AjBjyOnmkkSKHsPR2JluA5c6wovuPEnNKP32daGGeFKGEHMkTInbrqipC881 4442 /5K9Q+k= 4444 file: examples/voucher_00-D0-E5-F2-00-02.pkcs 4446 The ASN1 decoding of the artifact: 4448 0:d=0 hl=4 l=1756 cons: SEQUENCE 4449 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 4450 Data 4451 15:d=1 hl=4 l=1741 cons: cont [ 0 ] 4452 19:d=2 hl=4 l=1737 cons: SEQUENCE 4453 23:d=3 hl=2 l= 1 prim: INTEGER :01 4454 26:d=3 hl=2 l= 15 cons: SET 4455 28:d=4 hl=2 l= 13 cons: SEQUENCE 4456 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 4457 41:d=5 hl=2 l= 0 prim: NULL 4458 43:d=3 hl=4 l= 784 cons: SEQUENCE 4459 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 4460 58:d=4 hl=4 l= 769 cons: cont [ 0 ] 4461 62:d=5 hl=4 l= 765 prim: OCTET STRING :{"ietf-vouch 4462 er:voucher":{"assertion":"logged","created-on":"2017-10-12T1 4463 3:54:31.439-04:00","serial-number":"00-D0-E5-F2-00-02","nonc 4464 e":"Dss99sBr3pNMOACe-LYY7w","pinned-domain-cert":"MIIBrjCCAT 4465 OgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYCY2ExGT 4466 AXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5nIE 4467 ZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQz 4468 ESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbW 4469 FuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBw 4470 NCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8 4471 /puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM 4472 49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nu 4473 NifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdD 4474 CR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 4475 831:d=3 hl=4 l= 467 cons: cont [ 0 ] 4476 835:d=4 hl=4 l= 463 cons: SEQUENCE 4477 839:d=5 hl=4 l= 342 cons: SEQUENCE 4478 843:d=6 hl=2 l= 3 cons: cont [ 0 ] 4479 845:d=7 hl=2 l= 1 prim: INTEGER :02 4480 848:d=6 hl=2 l= 1 prim: INTEGER :01 4481 851:d=6 hl=2 l= 10 cons: SEQUENCE 4482 853:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4483 HA256 4484 863:d=6 hl=2 l= 77 cons: SEQUENCE 4485 865:d=7 hl=2 l= 18 cons: SET 4486 867:d=8 hl=2 l= 16 cons: SEQUENCE 4487 869:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4488 ent 4489 881:d=9 hl=2 l= 2 prim: IA5STRING :ca 4490 885:d=7 hl=2 l= 25 cons: SET 4491 887:d=8 hl=2 l= 23 cons: SEQUENCE 4492 889:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4493 ent 4494 901:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4495 912:d=7 hl=2 l= 28 cons: SET 4496 914:d=8 hl=2 l= 26 cons: SEQUENCE 4497 916:d=9 hl=2 l= 3 prim: OBJECT :commonName 4498 921:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4500 hway CA 4501 942:d=6 hl=2 l= 30 cons: SEQUENCE 4502 944:d=7 hl=2 l= 13 prim: UTCTIME :170326161940 4503 Z 4504 959:d=7 hl=2 l= 13 prim: UTCTIME :190326161940 4505 Z 4506 974:d=6 hl=2 l= 71 cons: SEQUENCE 4507 976:d=7 hl=2 l= 18 cons: SET 4508 978:d=8 hl=2 l= 16 cons: SEQUENCE 4509 980:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4510 ent 4511 992:d=9 hl=2 l= 2 prim: IA5STRING :ca 4512 996:d=7 hl=2 l= 25 cons: SET 4513 998:d=8 hl=2 l= 23 cons: SEQUENCE 4514 1000:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4515 ent 4516 1012:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4517 1023:d=7 hl=2 l= 22 cons: SET 4518 1025:d=8 hl=2 l= 20 cons: SEQUENCE 4519 1027:d=9 hl=2 l= 3 prim: OBJECT :commonName 4520 1032:d=9 hl=2 l= 13 prim: UTF8STRING :Unstrung MAS 4521 A 4522 1047:d=6 hl=2 l= 118 cons: SEQUENCE 4523 1049:d=7 hl=2 l= 16 cons: SEQUENCE 4524 1051:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 4525 ey 4526 1060:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 4527 1067:d=7 hl=2 l= 98 prim: BIT STRING 4528 1167:d=6 hl=2 l= 16 cons: cont [ 3 ] 4529 1169:d=7 hl=2 l= 14 cons: SEQUENCE 4530 1171:d=8 hl=2 l= 12 cons: SEQUENCE 4531 1173:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 4532 Constraints 4533 1178:d=9 hl=2 l= 1 prim: BOOLEAN :255 4534 1181:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 4535 00 4536 1185:d=5 hl=2 l= 10 cons: SEQUENCE 4537 1187:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4538 HA256 4539 1197:d=5 hl=2 l= 103 prim: BIT STRING 4540 1302:d=3 hl=4 l= 454 cons: SET 4541 1306:d=4 hl=4 l= 450 cons: SEQUENCE 4542 1310:d=5 hl=2 l= 1 prim: INTEGER :01 4543 1313:d=5 hl=2 l= 82 cons: SEQUENCE 4544 1315:d=6 hl=2 l= 77 cons: SEQUENCE 4545 1317:d=7 hl=2 l= 18 cons: SET 4546 1319:d=8 hl=2 l= 16 cons: SEQUENCE 4547 1321:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4549 ent 4550 1333:d=9 hl=2 l= 2 prim: IA5STRING :ca 4551 1337:d=7 hl=2 l= 25 cons: SET 4552 1339:d=8 hl=2 l= 23 cons: SEQUENCE 4553 1341:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 4554 ent 4555 1353:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4556 1364:d=7 hl=2 l= 28 cons: SET 4557 1366:d=8 hl=2 l= 26 cons: SEQUENCE 4558 1368:d=9 hl=2 l= 3 prim: OBJECT :commonName 4559 1373:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 4560 hway CA 4561 1394:d=6 hl=2 l= 1 prim: INTEGER :01 4562 1397:d=5 hl=2 l= 13 cons: SEQUENCE 4563 1399:d=6 hl=2 l= 9 prim: OBJECT :sha256 4564 1410:d=6 hl=2 l= 0 prim: NULL 4565 1412:d=5 hl=3 l= 228 cons: cont [ 0 ] 4566 1415:d=6 hl=2 l= 24 cons: SEQUENCE 4567 1417:d=7 hl=2 l= 9 prim: OBJECT :contentType 4568 1428:d=7 hl=2 l= 11 cons: SET 4569 1430:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4570 1441:d=6 hl=2 l= 28 cons: SEQUENCE 4571 1443:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4572 1454:d=7 hl=2 l= 15 cons: SET 4573 1456:d=8 hl=2 l= 13 prim: UTCTIME :171012175431 4574 Z 4575 1471:d=6 hl=2 l= 47 cons: SEQUENCE 4576 1473:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 4577 t 4578 1484:d=7 hl=2 l= 34 cons: SET 4579 1486:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:41 4580 79C6EB6F1C216F0CA187C1D658C30E52E5250971103DAD9E372F90B11F8B 4581 1D 4582 1520:d=6 hl=2 l= 121 cons: SEQUENCE 4583 1522:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 4584 ilities 4585 1533:d=7 hl=2 l= 108 cons: SET 4586 1535:d=8 hl=2 l= 106 cons: SEQUENCE 4587 1537:d=9 hl=2 l= 11 cons: SEQUENCE 4588 1539:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 4589 1550:d=9 hl=2 l= 11 cons: SEQUENCE 4590 1552:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 4591 1563:d=9 hl=2 l= 11 cons: SEQUENCE 4592 1565:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 4593 1576:d=9 hl=2 l= 10 cons: SEQUENCE 4594 1578:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 4595 1588:d=9 hl=2 l= 14 cons: SEQUENCE 4596 1590:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4597 1600:d=10 hl=2 l= 2 prim: INTEGER :80 4598 1604:d=9 hl=2 l= 13 cons: SEQUENCE 4599 1606:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4600 1616:d=10 hl=2 l= 1 prim: INTEGER :40 4601 1619:d=9 hl=2 l= 7 cons: SEQUENCE 4602 1621:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 4603 1628:d=9 hl=2 l= 13 cons: SEQUENCE 4604 1630:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 4605 1640:d=10 hl=2 l= 1 prim: INTEGER :28 4606 1643:d=5 hl=2 l= 10 cons: SEQUENCE 4607 1645:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 4608 HA256 4609 1655:d=5 hl=2 l= 103 prim: OCTET STRING [HEX DUMP]:30 4610 6502310087389DFC090D8EDB6948FD6B7E5369A5D1EC8B7DB8676F935C9C 4611 6E79EC2727CCFFD8D5DBF937F70EC4E1BFB76ED343B3023063C8E9E69244 4612 8A1EC3D1D8996E03973AC28BEE3C49CD28FDF675A1867852861073244C89 4613 DBAEA8A90BCF35FF92BD43E9 4615 Authors' Addresses 4617 Max Pritikin 4618 Cisco 4620 Email: pritikin@cisco.com 4622 Michael C. Richardson 4623 Sandelman Software Works 4625 Email: mcr+ietf@sandelman.ca 4626 URI: http://www.sandelman.ca/ 4628 Michael H. Behringer 4630 Email: Michael.H.Behringer@gmail.com 4632 Steinthor Bjarnason 4633 Arbor Networks 4635 Email: sbjarnason@arbor.net 4637 Kent Watsen 4638 Juniper Networks 4640 Email: kwatsen@juniper.net