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