idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-10.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 (February 13, 2018) is 2257 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: 'RFC3987' is mentioned on line 619, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1624, 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 2091, but not defined == Missing Reference: 'RFC2131' is mentioned on line 2539, but not defined == Missing Reference: 'FIND-good-REF' is mentioned on line 2584, but not defined == Missing Reference: 'HEX DUMP' is mentioned on line 3733, but not defined == Unused Reference: 'RFC3542' is defined on line 2381, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 2417, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 2426, but no explicit reference was found in the text == Unused Reference: 'I-D.behringer-homenet-trust-bootstrap' is defined on line 2462, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 2468, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 2498, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 2513, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-13 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' ** Downref: Normative reference to an Informational RFC: RFC 3542 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-19 == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-15 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-02 -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 19 warnings (==), 4 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: August 17, 2018 SSW 6 M. Behringer 8 S. Bjarnason 9 Arbor Networks 10 K. Watsen 11 Juniper Networks 12 February 13, 2018 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-10 17 Abstract 19 This document specifies automated bootstrapping of a remote secure 20 key infrastructure (BRSKI) using vendor installed X.509 certificate, 21 in combination with a vendor's authorizing service, both online and 22 offline. Bootstrapping a new device can occur using a routable 23 address and a cloud service, or using only link-local connectivity, 24 or on limited/disconnected networks. Support for lower security 25 models, including devices with minimal identity, is described for 26 legacy reasons but not encouraged. Bootstrapping is complete when 27 the cryptographic identity of the new key infrastructure is 28 successfully deployed to the device but the established secure 29 connection can be used to deploy a locally issued certificate to the 30 device as well. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 17, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 5 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8 70 1.4. Leveraging the new key infrastructure / next steps . . . 9 71 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 10 72 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 11 73 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 13 74 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 14 75 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 15 76 2.4.1. Architectural component: Pledge . . . . . . . . . . . 17 77 2.4.2. Architectural component: Circuit Proxy . . . . . . . 17 78 2.4.3. Architectural component: Domain Registrar . . . . . . 17 79 2.4.4. Architectural component: Vendor Service . . . . . . . 17 80 2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 17 81 2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 18 82 2.7. Determining the MASA to contact . . . . . . . . . . . . . 18 83 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 19 84 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 19 85 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 86 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 87 4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 24 88 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 25 89 4.1.1. Proxy Grasp announcements . . . . . . . . . . . . . . 26 90 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 27 91 4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 27 92 4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 28 93 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 29 94 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 31 95 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 31 96 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 33 97 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 33 98 5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 36 99 5.5.1. Completing authentication of Provisional TLS 100 connection . . . . . . . . . . . . . . . . . . . . . 37 101 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 38 102 5.7. MASA authorization log Request . . . . . . . . . . . . . 39 103 5.7.1. MASA authorization log Response . . . . . . . . . . . 40 104 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 41 105 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 42 106 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 42 107 5.8.3. EST Client Certificate Request . . . . . . . . . . . 43 108 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 43 109 5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 44 110 6. Reduced security operational modes . . . . . . . . . . . . . 44 111 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 44 112 6.2. Pledge security reductions . . . . . . . . . . . . . . . 45 113 6.3. Registrar security reductions . . . . . . . . . . . . . . 46 114 6.4. MASA security reductions . . . . . . . . . . . . . . . . 47 115 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 116 7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 48 117 7.2. Voucher Status Telemetry . . . . . . . . . . . . . . . . 48 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 119 8.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 50 120 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 122 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 123 10.2. Informative References . . . . . . . . . . . . . . . . . 54 124 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 55 125 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 55 126 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 55 127 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 55 128 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 56 129 C.1. Multiple Join networks on the Join Proxy side . . . . . . 57 130 C.2. Automatic configuration of tunnels on Registrar . . . . . 57 131 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 58 132 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on 133 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 58 134 C.5. Use of socket extension rather than virtual interface . . 58 135 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 59 136 Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 61 137 E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 61 138 E.1.1. MASA key pair for voucher signatures . . . . . . . . 61 139 E.1.2. Manufacturer key pair for IDevID signatures . . . . . 61 140 E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 62 141 E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 64 142 E.2. Example process . . . . . . . . . . . . . . . . . . . . . 65 143 E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 65 144 E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 71 145 E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 77 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 148 1. Introduction 150 BRSKI provides a foundation to securely answer the following 151 questions between an element of the network domain called the 152 "Registrar" and an unconfigured and untouched device called a 153 "Pledge": 155 o Registrar authenticating the Pledge: "Who is this device? What is 156 its identity?" 158 o Registrar authorization the Pledge: "Is it mine? Do I want it? 159 What are the chances it has been compromised?" 161 o Pledge authenticating the Registrar/Domain: "What is this domain's 162 identity?" 164 o Pledge authorization the Registrar: "Should I join it?" 166 This document details protocols and messages to the endpoints to 167 answer the above questions. The Registrar actions derive from Pledge 168 identity, third party cloud service communications, and local access 169 control lists. The Pledge actions derive from a cryptographically 170 protected "voucher" message delivered through the Registrar but 171 originating at a Manufacturer Authorized Signing Authority. 173 The syntactic details of vouchers are described in detail in 174 [I-D.ietf-anima-voucher]. This document details automated protocol 175 mechanisms to obtain vouchers, including the definition of a 176 'voucher-request' message that is a minor extension to the voucher 177 format (see Section 3). 179 BRSKI results in the Pledge storing an X.509 root certificate 180 sufficient for verifying the Registrar identity. In the process a 181 TLS connection is established which can be directly used for 182 Enrollment over Secure Transport (EST). In effect BRSKI provides an 183 automated mechanism for the "Bootstrap Distribution of CA 184 Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge 185 "MUST [...]. engage a human user to authorize the CA certificate 186 using out-of-band" information". With BRSKI the Pledge now can 187 automate this process using the voucher. Integration with a complete 188 EST enrollment is optional but trivial. 190 BRSKI is agile enough to support bootstrapping alternative key 191 infrastructures, such as a symmetric key solutions, but no such 192 system is described in this document. 194 1.1. Other Bootstrapping Approaches 196 To literally "pull yourself up by the bootstraps" is an impossible 197 action. Similarly the secure establishment of a key infrastructure 198 without external help is also an impossibility. Today it is commonly 199 accepted that the initial connections between nodes are insecure, 200 until key distribution is complete, or that domain-specific keying 201 material is pre-provisioned on each new device in a costly and non- 202 scalable manner. Existing mechanisms are known as non-secured 'Trust 203 on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 204 [Stajano99theresurrecting] or 'pre-staging'. 206 Another approach is to try and minimize user actions during 207 bootstrapping. The enrollment protocol EST [RFC7030] details a set 208 of non-autonomic bootstrapping methods in this vein: 210 o using the Implicit Trust Anchor database (not an autonomic 211 solution because the URL must be securely distributed), 213 o engaging a human user to authorize the CA certificate using out- 214 of-band data (not an autonomic solution because the human user is 215 involved), 217 o using a configured Explicit TA database (not an autonomic solution 218 because the distribution of an explicit TA database is not 219 autonomic), 221 o and using a Certificate-Less TLS mutual authentication method (not 222 an autonomic solution because the distribution of symmetric key 223 material is not autonomic). 225 These "touch" methods do not meet the requirements for zero-touch. 227 There are "call home" technologies where the Pledge first establishes 228 a connection to a well known vendor service using a common client- 229 server authentication model. After mutual authentication appropriate 230 credentials to authenticate the target domain are transfered to the 231 Pledge. This creates serveral problems and limitations: 233 o the pledge requires realtime connectivity to the vendor service, 235 o the domain identity is exposed to the vendor service (this is a 236 privacy concern), 238 o the vendor is responsible for making the authorization decisions 239 (this is a liability concern), 241 BRSKI addresses these issues by defining extensions to the EST 242 protocol for the automated distribution of vouchers. 244 1.2. Terminology 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 248 "OPTIONAL" in this document are to be interpreted as described in 249 [RFC2119]. 251 The following terms are defined for clarity: 253 domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT 254 STRING of the subjectPublicKey of the root certificate for the 255 registrars in the domain. This is consistent with the subject key 256 identifier (Section 4.2.1.2 [RFC5280]). 258 drop ship: The physical distribution of equipment containing the 259 "factory default" configuration to a final destination. In zero- 260 touch scenarios there is no staging or pre-configuration during 261 drop-ship. 263 imprint: The process where a device obtains the cryptographic key 264 material to identify and trust future interactions with a network. 265 This term is taken from Konrad Lorenz's work in biology with new 266 ducklings: during a critical period, the duckling would assume 267 that anything that looks like a mother duck is in fact their 268 mother. An equivalent for a device is to obtain the fingerprint 269 of the network's root certification authority certificate. A 270 device that imprints on an attacker suffers a similar fate to a 271 duckling that imprints on a hungry wolf. Securely imprinting is a 272 primary focus of this document.[imprinting]. The analogy to 273 Lorenz's work was first noted in [Stajano99theresurrecting]. 275 enrollment: The process where a device presents key material to a 276 network and acquires a network specific identity. For example 277 when a certificate signing request is presented to a certification 278 authority and a certificate is obtained in response. 280 Pledge: The prospective device, which has an identity installed by a 281 third-party (e.g., vendor, manufacturer or integrator). 283 Voucher A signed statement from the MASA service that indicates to a 284 Pledge the cryptographic identity of the Registrar it should 285 trust. There are different types of vouchers depending on how 286 that trust asserted. Multiple voucher types are defined in 287 [I-D.ietf-anima-voucher] 289 Domain: The set of entities that trust a common key infrastructure 290 trust anchor. This includes the Proxy, Registrar, Domain 291 Certificate Authority, Management components and any existing 292 entity that is already a member of the domain. 294 Domain CA: The domain Certification Authority (CA) provides 295 certification functionalities to the domain. At a minimum it 296 provides certification functionalities to a Registrar and stores 297 the trust anchor that defines the domain. Optionally, it 298 certifies all elements. 300 Join Registrar (and Coordinator): A representative of the domain 301 that is configured, perhaps autonomically, to decide whether a new 302 device is allowed to join the domain. The administrator of the 303 domain interfaces with a Join Registrar (and Coordinator) to 304 control this process. Typically a Join Registrar is "inside" its 305 domain. For simplicity this document often refers to this as just 306 "Registrar". The term JRC is used in common with other bootstrap 307 mechanisms. 309 Join Proxy: A domain entity that helps the pledge join the domain. 310 A Proxy facilitates communication for devices that find themselves 311 in an environment where they are not provided connectivity until 312 after they are validated as members of the domain. The pledge is 313 unaware that they are communicating with a proxy rather than 314 directly with a Registrar. 316 MASA Service: A third-party Manufacturer Authorized Signing 317 Authority (MASA) service on the global Internet. The MASA signs 318 vouchers. It also provides a repository for audit log information 319 of privacy protected bootstrapping events. It does not track 320 ownership. 322 Ownership Tracker: An Ownership Tracker service on the global 323 internet. The Ownership Tracker uses business processes to 324 accurately track ownership of all devices shipped against domains 325 that have purchased them. Although optional this component allows 326 vendors to provide additional value in cases where their sales and 327 distribution channels allow for accurately tracking of such 328 ownership. Ownership tracking information is indicated in 329 vouchers as described in [I-D.ietf-anima-voucher] 331 IDevID: An Initial Device Identity X.509 certificate installed by 332 the vendor on new equipment. 334 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 335 where a Pledge device makes no security decisions but rather 336 simply trusts the first Registrar it is contacted by. This is 337 also known as the "resurrecting duckling" model. 339 nonced: a voucher (or request) that contains a nonce (the normal 340 case). 342 nonceless: a voucher (or request) that does not contain a nonce, 343 relying upon accurate clocks for expiration, or which does not 344 expire. 346 1.3. Scope of solution 348 Questions have been posed as to whether this solution is suitable in 349 general for Internet of Things (IoT) networks. This depends on the 350 capabilities of the devices in question. The terminology of 351 [RFC7228] is best used to describe the boundaries. 353 The solution described in this document is aimed in general at non- 354 constrained (i.e. class 2+) devices operating on a non-Challenged 355 network. The entire solution as described here is not intended to be 356 useable as-is by constrained devices operating on challenged networks 357 (such as 802.15.4 LLNs). 359 In many target applications, the systems involved are large router 360 platforms with multi-gigabit inter-connections, mounted in controlled 361 access data centers. But this solution is not exclusive to the 362 large, it is intended to scale to thousands of devices located in 363 hostile environments, such as ISP provided CPE devices which are 364 drop-shipped to the end user. The situation where an order is 365 fulfilled from distributed warehouse from a common stock and shipped 366 directly to the target location at the request of the domain owner is 367 explicitly supported. That stock ("SKU") could be provided to a 368 number of potential domain owners, and the eventual domain owner will 369 not know a-priori which device will go to which location. 371 The bootstrapping process can take minutes to complete depending on 372 the network infrastructure and device processing speed. The network 373 communication itself is not optimized for speed; for privacy reasons, 374 the discovery process allows for the Pledge to avoid announcing it's 375 presence through broadcasting. 377 This protocol is not intended for low latency handoffs. In networks 378 requiring such things, the pledge SHOULD already have been enrolled. 380 Specifically, there are protocol aspects described here which might 381 result in congestion collapse or energy-exhaustion of intermediate 382 battery powered routers in an LLN. Those types of networks SHOULD 383 NOT use this solution. These limitations are predominately related 384 to the large credential and key sizes required for device 385 authentication. Defining symmetric key techniques that meet the 386 operational requirements is out-of-scope but the underlying protocol 387 operations (TLS handshake and signing structures) have sufficient 388 algorithm agility to support such techniques when defined. 390 The imprint protocol described here could, however, be used by non- 391 energy constrained devices joining a non-constrained network (for 392 instance, smart light bulbs are usually mains powered, and speak 393 802.11). It could also be used by non-constrained devices across a 394 non-energy constrained, but challenged network (such as 802.15.4). 395 The certificate contents, and the process by which the four questions 396 above are resolved do apply to constrained devices. It is simply the 397 actual on-the-wire imprint protocol which could be inappropriate. 399 This document presumes that network access control has either already 400 occurred, is not required, or is integrated by the proxy and 401 registrar in such a way that the device itself does not need to be 402 aware of the details. Although the use of an X.509 Initial Device 403 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 404 alignment with 802.1X network access control methods, its use here is 405 for Pledge authentication rather than network access control. 406 Integrating this protocol with network access control, perhaps as an 407 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 408 out-of-scope. 410 1.4. Leveraging the new key infrastructure / next steps 412 As a result of the protocol described herein the bootstrapped devices 413 have a common trust anchor and a certificate has optionally been 414 issued from a local PKI. This makes it possible to automatically 415 deploy services across the domain in a secure manner. 417 Services which benefit from this: 419 o Device management. 421 o Routing authentication. 423 o Service discovery. 425 The major beneficiary is that it possible to use the credentials 426 deployed by this protocol to secure the Autonomic Control Plane (ACP) 427 ([I-D.ietf-anima-autonomic-control-plane]). 429 2. Architectural Overview 431 The logical elements of the bootstrapping framework are described in 432 this section. Figure 1 provides a simplified overview of the 433 components. Each component is logical and may be combined with other 434 components as necessary. 436 +------------------------+ 437 +--------------Drop Ship--------------->| Vendor Service | 438 | +------------------------+ 439 | | M anufacturer| | 440 | | A uthorized |Ownership| 441 | | S igning |Tracker | 442 | | A uthority | | 443 | +--------------+---------+ 444 | ^ 445 | | BRSKI- 446 V | MASA 447 +-------+ ............................................|... 448 | | . | . 449 | | . +------------+ +-----------+ | . 450 | | . | | | | | . 451 |Pledge | . | Circuit | | Domain <-------+ . 452 | | . | Proxy | | Registrar | . 453 | <-------->............<-------> (PKI RA) | . 454 | | | BRSKI-EST | | . 455 | | . | | +-----+-----+ . 456 |IDevID | . +------------+ | EST RFC7030 . 457 | | . +-----------------+----------+ . 458 | | . | Key Infrastructure | . 459 | | . | (e.g. PKI Certificate | . 460 +-------+ . | Authority) | . 461 . +----------------------------+ . 462 . . 463 ................................................ 464 "Domain" components 466 Figure 1 468 We assume a multi-vendor network. In such an environment there could 469 be a Vendor Service for each vendor that supports devices following 470 this document's specification, or an integrator could provide a 471 generic service authorized by multiple vendors. It is unlikely that 472 an integrator could provide Ownership Tracking services for multiple 473 vendors due to the required sales channel integrations necessary to 474 track ownership. 476 The domain is the managed network infrastructure with a Key 477 Infrastructure the Pledge is joining. The a domain provides initial 478 device connectivity sufficient for bootstrapping with a Circuit 479 Proxy. The Domain Registrar authenticates the Pledge, makes 480 authorization decisions, and distributes vouchers obtained from the 481 Vendor Service. Optionally the Registrar also acts as a PKI 482 Registration Authority. 484 2.1. Behavior of a Pledge 486 The pledge goes through a series of steps which are outlined here at 487 a high level. 489 +--------------+ 490 | Factory | 491 | default | 492 +------+-------+ 493 | 494 +------v-------+ 495 | Discover | 496 +------------> | 497 | +------+-------+ 498 | | 499 | +------v-------+ 500 | | Identity | 501 ^------------+ | 502 | rejected +------+-------+ 503 | | 504 | +------v-------+ 505 | | Request | 506 | | Join | 507 | +------+-------+ 508 | | 509 | +------v-------+ 510 | | Imprint | Optional 511 ^------------+ <--+Manual input (Appendix C) 512 | Bad Vendor +------+-------+ 513 | response | send Voucher Status Telemetry 514 | +------v-------+ 515 | | Enroll | 516 ^------------+ | 517 | Enroll +------+-------+ 518 | Failure | 519 | +------v-------+ 520 | | Enrolled | 521 ^------------+ | 522 Factory +--------------+ 523 reset 525 Figure 2 527 State descriptions for the pledge are as follows: 529 1. Discover a communication channel to a Registrar. 531 2. Identify itself. This is done by presenting an X.509 IDevID 532 credential to the discovered Registrar (via the Proxy) in a TLS 533 handshake. (The Registrar credentials are only provisionally 534 accepted at this time). 536 3. Requests to Join the discovered Registrar. A unique nonce can be 537 included ensuring that any responses can be associated with this 538 particular bootstrapping attempt. 540 4. Imprint on the Registrar. This requires verification of the 541 vendor service provided voucher. A voucher contains sufficient 542 information for the Pledge to complete authentication of a 543 Registrar. (It enables the Pledge to finish authentication of 544 the Registrar TLS server certificate). 546 5. Enroll. By accepting the domain specific information from a 547 Registrar, and by obtaining a domain certificate from a Registrar 548 using a standard enrollment protocol, e.g. Enrollment over 549 Secure Transport (EST) [RFC7030]. 551 6. The Pledge is now a member of, and can be managed by, the domain 552 and will only repeat the discovery aspects of bootstrapping if it 553 is returned to factory default settings. 555 2.2. Secure Imprinting using Vouchers 557 A voucher is a cryptographically protected statement to the Pledge 558 device authorizing a zero-touch imprint on the Registrar domain. 560 The format and cryptographic mechanism of vouchers is described in 561 detail in [I-D.ietf-anima-voucher]. 563 Vouchers provide a flexible mechanism to secure imprinting: the 564 Pledge device only imprints when a voucher can be validated. At the 565 lowest security levels the MASA server can indiscriminately issue 566 vouchers. At the highest security levels issuance of vouchers can be 567 integrated with complex sales channel integrations that are beyond 568 the scope of this document. This provides the flexibility for a 569 number of use cases via a single common protocol mechanism on the 570 Pledge and Registrar devices that are to be widely deployed in the 571 field. The MASA vendor services have the flexibility to leverage 572 either the currently defined claim mechanisms or to experiment with 573 higher or lower security levels. 575 Vouchers provide a signed but non-encrypted communication channel 576 between the Pledge, the MASA, and the Registrar. The Registrar 577 maintains control over the transport and policy decisions allowing 578 the local security policy of the domain network to be enforced. 580 2.3. Initial Device Identifier 582 Pledge authentication and Pledge voucher-request signing is via an 583 X.509 certificate installed during the manufacturing process. This 584 Initial Device Identifier provides a basis for authenticating the 585 Pledge during subsequent protocol exchanges and informing the 586 Registrar of the MASA URI. There is no requirement for a common root 587 PKI hierarchy. Each device vendor can generate their own root 588 certificate. 590 The following previously defined fields are in the X.509 IDevID 591 certificate: 593 o The subject field's DN encoding MUST include the "serialNumber" 594 attribute with the device's unique serial number. 596 o The subject-alt field's encoding SHOULD include a non-critical 597 version of the RFC4108 defined HardwareModuleName. 599 In order to build the voucher "serial-number" field these IDevID 600 fields need to be converted into a serial-number of "type string". 601 The following methods is used depending on the first available IDevID 602 certificate field (attempted in this order): 604 o An RFC4514 String Representation of the Distinguished Name 605 "serialNumber" attribute. 607 o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded. 609 o The RFC4514 String Representation of the Distinguished Name 610 "common name" attribute. 612 The following newly defined field SHOULD be in the X.509 IDevID 613 certificate: An X.509 non-critical certificate extension that 614 contains a single Uniform Resource Identifier (URI) that points to an 615 on-line Manufacturer Authorized Signing Authority. The URI is 616 represented as described in Section 7.4 of [RFC5280]. 618 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 619 URIs as specified in Section 3.1 of [RFC3987] before they are placed 620 in the certificate extension. The URI provides the authority 621 information. The BRSKI .well-known tree is described in Section 5 623 The new extension is identified as follows: 625 627 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 628 internet(1) security(5) mechanisms(5) pkix(7) 629 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 631 DEFINITIONS IMPLICIT TAGS ::= BEGIN 633 -- EXPORTS ALL -- 635 IMPORTS 636 EXTENSION 637 FROM PKIX-CommonTypes-2009 638 { iso(1) identified-organization(3) dod(6) internet(1) 639 security(5) mechanisms(5) pkix(7) id-mod(0) 640 id-mod-pkixCommon-02(57) } 642 id-pe 643 FROM PKIX1Explicit-2009 644 { iso(1) identified-organization(3) dod(6) internet(1) 645 security(5) mechanisms(5) pkix(7) id-mod(0) 646 id-mod-pkix1-explicit-02(51) } ; 647 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 648 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 649 IDENTIFIED BY id-pe-masa-url } 651 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 653 MASAURLSyntax ::= IA5String 655 END 657 659 The choice of id-pe is based on guidance found in Section 4.2.2 of 660 [RFC5280], "These extensions may be used to direct applications to 661 on-line information about the issuer or the subject". The MASA URL 662 is precisely that: online information about the particular subject. 664 2.4. Protocol Flow 666 A representative flow is shown in Figure 3: 668 +--------+ +---------+ +------------+ +------------+ 669 | Pledge | | Circuit | | Domain | | Vendor | 670 | | | Proxy | | Registrar | | Service | 671 | | | | | (JRC) | | (MASA) | 672 +--------+ +---------+ +------------+ +------------+ 673 | | | Internet | 674 |<-RFC4862 IPv6 addr | | | 675 |<-RFC3927 IPv4 addr | Appendix A | | 676 | | | | 677 |-------------------->| | | 678 | optional: mDNS query| Appendix B | | 679 | RFC6763/RFC6762 | | | 680 | | | | 681 |<--------------------| | | 682 | GRASP M_FLOOD | | | 683 | periodic broadcast| | | 684 | | | | 685 |<------------------->C<----------------->| | 686 | TLS via the Circuit Proxy | | 687 |<--Registrar TLS server authentication---| | 688 [PROVISIONAL accept of server cert] | | 689 P---X.509 client authentication---------->| | 690 P | | | 691 P---Voucher Request (include nonce)------>| | 692 P | | | 693 P | /---> | | 694 P | | [accept device?] | 695 P | | [contact Vendor] | 696 P | | |--Pledge ID-------->| 697 P | | |--Domain ID-------->| 698 P | | |--optional:nonce--->| 699 P | | | [extract DomainID] 700 P | | | | 701 P | optional: | [update audit log] 702 P | |can | | 703 P | |occur | | 704 P | |in | | 705 P | |advance | | 706 P | |if | | 707 P | |nonceless | | 708 P | | |<- voucher ---------| 709 P | \----> | | 710 P | | | 711 P<------voucher---------------------------| | 712 [verify voucher ] | | | 713 [verify provisional cert| | | 714 | | | | 715 |---------------------------------------->| | 716 | [voucher status telemetry] |<-device audit log--| 717 | | [verify audit log and voucher] | 718 | | | | 719 |<--------------------------------------->| | 720 | Continue with RFC7030 enrollment | | 721 | using now bidirectionally authenticated | | 722 | TLS session. | | | 723 | | | | 725 Figure 3 727 2.4.1. Architectural component: Pledge 729 The Pledge is the device which is attempting to join. Until the 730 pledge completes the enrollment process, it has network connectivity 731 only to the Proxy. 733 2.4.2. Architectural component: Circuit Proxy 735 The (Circuit) Proxy provides HTTPS connectivity between the pledge 736 and the registrar. The proxy mechanism is described in Section 4, 737 with an optional stateless mechanism described in Appendix C. 739 2.4.3. Architectural component: Domain Registrar 741 The Domain Registrar (having the formal name Join Registrar/ 742 Coordinator (JRC)), operates as a CMC Registrar, terminating the EST 743 and BRSKI connections. The Registrar is manually configured or 744 distributed with a list of trust anchors necessary to authenticate 745 any Pledge device expected on the network. The Registrar 746 communicates with the Vendor supplied MASA to establish ownership. 748 2.4.4. Architectural component: Vendor Service 750 The Vendor Service provides two logically seperate functions: the 751 Manufacturer Authorized Signing Authority (MASA), and an ownership 752 tracking/auditing function. 754 2.5. Lack of realtime clock 756 Many devices when bootstrapping do not have knowledge of the current 757 time. Mechanisms like Network Time Protocols can not be secured 758 until bootstrapping is complete. Therefore bootstrapping is defined 759 in a method that does not require knowledge of the current time. 761 Unfortunately there are moments during bootstrapping when 762 certificates are verified, such as during the TLS handshake, where 763 validity periods are confirmed. This paradoxical "catch-22" is 764 resolved by the Pledge maintaining a concept of the current "window" 765 of presumed time validity that is continually refined throughout the 766 bootstrapping process as follows: 768 o Initially the Pledge does not know the current time. 770 o During Pledge authentiation by the Registrar a realtime clock can 771 be used by the Registrar. This bullet expands on a closely 772 related issue regarding Pledge lifetimes. RFC5280 indicates that 773 long lived Pledge certifiates "SHOULD be assigned the 774 GeneralizedTime value of 99991231235959Z" [RFC7030] so the 775 Registrar MUST support such lifetimes and SHOULD support ignoring 776 Pledge lifetimes if they did not follow the RFC5280 777 recommendations. 779 o The Pledge authenticates the voucher presented to it. During this 780 authentication the Pledge ignores certificate lifetimes (by 781 necessity because it does not have a realtime clock). 783 o If the voucher contains a nonce then the Pledge MUST confirm the 784 nonce matches the original Pledge voucher-request. This ensures 785 the voucher is fresh. See / (Section 5.2). 787 o Once the voucher is accepted the validity period of the pinned- 788 domain-cert in the voucher now serves as a valid time window. Any 789 subsequent certificate validity periods checked during RFC5280 790 path validation MUST occur within this window. 792 o When accepting an enrollment certificate the validity period 793 within the new certificate is assumed to be valid by the Pledge. 794 The Pledge is now willing to use this credential for client 795 authentication. 797 2.6. Cloud Registrar 799 The Pledge MAY contact a well known URI of a cloud Registrar if a 800 local Registrar can not be discovered or if the Pledge's target use 801 cases do not include a local Registrar. 803 If the Pledge uses a well known URI for contacting a cloud Registrar 804 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 805 authenticate service as described in RFC6125. This is consistent 806 with the human user configuration of an EST server URI in [RFC7030] 807 which also depends on RFC6125. 809 2.7. Determining the MASA to contact 811 The registrar needs to be able to contact a MASA that is trusted by 812 the Pledge in order to obtain vouchers. There are three mechanisms 813 described: 815 The device's Initial Device Identifier will normally contain the MASA 816 URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. 818 If the Registrar is integrated with [I-D.ietf-opsawg-mud] and the 819 Pledge IDevID contains the id-pe-mud-url then the Registrar MAY 820 attempt to obtain the MASA URL from the MUD file. The MUD file 821 extension for the MASA URL is defined in Appendix D. 823 It can be operationally difficult to ensure the necessary X.509 824 extensions are in the Pledge's' IDevID due to the difficulty of 825 aligning current Pledge manufacturing with software releases and 826 development. As a final fallback the Registrar MAY be manually 827 configured or distributed with a MASA URL for each vendor. Note that 828 the Registrar can only select the configured MASA URL based on the 829 trust anchor -- so vendors can only leverage this approach if they 830 ensure a single MASA URL works for all Pledge's associated with each 831 trust anchor. 833 3. Voucher-Request artifact 835 The Pledge voucher-request is how a Pledge requests a voucher. The 836 Pledge forms a voucher-request and submits it to the Registrar. The 837 Registrar in turn submits a voucher-request to the MASA server. To 838 help differentiate this document refers to "Pledge voucher-request" 839 and "Registrar voucher-request" when indicating the source is 840 beneficial. The "proximity-registrar-cert" leaf is used in Pledge 841 voucher-requests. The "prior-signed-voucher-request" is used in 842 Registrar voucher-requests that include a Pledge voucher-request. 844 Unless otherwise signaled (outside the voucher-request artifact), the 845 signing structure is as defined for vouchers, see 846 [I-D.ietf-anima-voucher]. 848 3.1. Tree Diagram 850 The following tree diagram illustrates a high-level view of a 851 voucher-request document. The notation used in this diagram is 852 described in [I-D.ietf-anima-voucher]. Each node in the diagram is 853 fully described by the YANG module in Section 3.3. Please review the 854 YANG module for a detailed description of the voucher-request format. 856 module: ietf-voucher-request 858 grouping voucher-request-grouping 859 +---- voucher 860 +---- created-on? yang:date-and-time 861 +---- expires-on? yang:date-and-time 862 +---- assertion enumeration 863 +---- serial-number string 864 +---- idevid-issuer? binary 865 +---- pinned-domain-cert? binary 866 +---- domain-cert-revocation-checks? boolean 867 +---- nonce? binary 868 +---- last-renewal-date? yang:date-and-time 869 +---- prior-signed-voucher-request? binary 870 +---- proximity-registrar-cert? binary 872 3.2. Examples 874 This section provides voucher examples for illustration purposes. 875 That these examples conform to the encoding rules defined in 876 [RFC7951]. 878 Example (1) The following example illustrates a Pledge voucher- 879 request. The assertion leaf is indicated as 'proximity' 880 and the Registrar's TLS server certificate is included 881 in the 'proximity-registrar-cert' leaf. See 882 Section 5.2. 884 { 885 "ietf-voucher-request:voucher": { 886 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 887 "created-on": "2017-01-01T00:00:00.000Z", 888 "assertion": "proximity", 889 "proximity-registrar-cert": "base64encodedvalue==" 890 } 891 } 893 Example (2) The following example illustrates a Registrar voucher- 894 request. The 'prior-signed-voucher-request' leaf is 895 populated with the Pledge's voucher-request (such as the 896 prior example). See Section 5.4. 898 { 899 "ietf-voucher-request:voucher": { 900 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 901 "created-on": "2017-01-01T00:00:02.000Z", 902 "assertion": "proximity", 903 "idevid-issuer": "base64encodedvalue==" 904 "serial-number": "JADA123456789" 905 "prior-signed-voucher": "base64encodedvalue==" 906 } 907 } 909 Example (3) The following example illustrates a Registrar voucher- 910 request. The 'prior-signed-voucher-request' leaf is not 911 populated with the Pledge's voucher-request nor is the 912 nonce leaf. This form might be used by a Registrar 913 requesting a voucher when the Pledge is offline or when 914 the Registrar expects to be offline during deployment. 915 See Section 5.4. 917 { 918 "ietf-voucher-request:voucher": { 919 "created-on": "2017-01-01T00:00:02.000Z", 920 "assertion": "TBD", 921 "idevid-issuer": "base64encodedvalue==" 922 "serial-number": "JADA123456789" 923 } 924 } 926 Example (4) The following example illustrates a Registrar voucher- 927 request. The 'prior-signed-voucher-request' leaf is not 928 populated with the Pledge voucher-request because the 929 Pledge did not sign it's own request. This form might 930 be used when more constrained Pledges are being 931 deployed. The nonce is populated from the Pledge's 932 request. See Section 5.4. 934 { 935 "ietf-voucher-request:voucher": { 936 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 937 "created-on": "2017-01-01T00:00:02.000Z", 938 "assertion": "proximity", 939 "idevid-issuer": "base64encodedvalue==" 940 "serial-number": "JADA123456789" 941 } 942 } 944 3.3. YANG Module 946 Following is a YANG [RFC7950] module formally extending the 947 [I-D.ietf-anima-voucher] voucher into a voucher-request. 949 file "yang/ietf-voucher-request@2018-02-13.yang" 950 module ietf-voucher-request { 951 yang-version 1.1; 953 namespace 954 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 955 prefix "vch"; 957 import ietf-restconf { 958 prefix rc; 959 description 960 "This import statement is only present to access 961 the yang-data extension defined in RFC 8040."; 962 reference "RFC 8040: RESTCONF Protocol"; 963 } 965 import ietf-voucher { 966 prefix v; 967 description 968 "FIXME"; 969 reference "RFC ????: Voucher Profile for Bootstrapping Protocols"; 970 } 972 organization 973 "IETF ANIMA Working Group"; 975 contact 976 "WG Web: 977 WG List: 978 Author: Kent Watsen 979 980 Author: Max Pritikin 981 982 Author: Michael Richardson 983 984 Author: Toerless Eckert 985 "; 987 description 988 "This module... FIXME 990 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 991 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 992 the module text are to be interpreted as described in RFC 2119. 994 Copyright (c) 2017 IETF Trust and the persons identified as 995 authors of the code. All rights reserved. 997 Redistribution and use in source and binary forms, with or without 998 modification, is permitted pursuant to, and subject to the license 999 terms contained in, the Simplified BSD License set forth in Section 1000 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1001 (http://trustee.ietf.org/license-info). 1003 This version of this YANG module is part of RFC XXXX; see the RFC 1004 itself for full legal notices."; 1006 revision "2018-02-13" { 1007 description 1008 "Initial version"; 1009 reference 1010 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 1011 } 1013 // Top-level statement 1014 rc:yang-data voucher-request-artifact { 1015 uses voucher-request-grouping; 1016 } 1018 // Grouping defined for future usage 1019 grouping voucher-request-grouping { 1020 description 1021 "Grouping to allow reuse/extensions in future work."; 1023 uses v:voucher-artifact-grouping { 1024 refine "voucher/created-on" { 1025 mandatory false; 1026 } 1028 refine "voucher/pinned-domain-cert" { 1029 mandatory false; 1030 } 1032 augment "voucher" { 1033 description 1034 "Adds leaf nodes appropriate for requesting vouchers."; 1036 leaf prior-signed-voucher-request { 1037 type binary; 1038 description 1039 "If it is necessary to change a voucher, or re-sign and 1040 forward a voucher that was previously provided along a 1041 protocol path, then the previously signed voucher SHOULD be 1042 included in this field. 1044 For example, a pledge might sign a proximity voucher, which 1045 an intermediate registrar then re-signs to make its own 1046 proximity assertion. This is a simple mechanism for a 1047 chain of trusted parties to change a voucher, while 1048 maintaining the prior signature information. 1050 The pledge MUST ignore all prior voucher information when 1051 accepting a voucher for imprinting. Other parties MAY 1052 examine the prior signed voucher information for the 1053 purposes of policy decisions. For example this information 1054 could be useful to a MASA to determine that both pledge and 1055 registrar agree on proximity assertions. The MASA SHOULD 1056 remove all prior-signed-voucher information when signing 1057 a voucher for imprinting so as to minimize the final 1058 voucher size."; 1059 } 1061 leaf proximity-registrar-cert { 1062 type binary; 1063 description 1064 "An X.509 v3 certificate structure as specified by RFC 5280, 1065 Section 4 encoded using the ASN.1 distinguished encoding 1066 rules (DER), as specified in ITU-T X.690. 1068 The first certificate in the Registrar TLS server 1069 certificate_list sequence (see [RFC5246]) presented by 1070 the Registrar to the Pledge. This MUST be populated in a 1071 Pledge's voucher request if the proximity assertion is 1072 populated."; 1073 } 1074 } 1075 } 1076 } 1078 } 1080 1082 4. Proxy details 1084 The role of the Proxy is to facilitate communications. The Proxy 1085 forwards packets between the Pledge and a Registrar that has been 1086 configured on the Proxy. 1088 The Proxy does not terminate the TLS handshake: it passes streams of 1089 bytes onward without examination. 1091 A proxy MAY assume TLS framing for auditing purposes, but MUST NOT 1092 assume any TLS version. 1094 A Proxy is always assumed even if it is directly integrated into a 1095 Registrar. (In a completely autonomic network, the Registrar MUST 1096 provide proxy functionality so that it can be discovered, and the 1097 network can grow concentrically around the Registrar) 1099 As a result of the Proxy Discovery process in section Section 4.1.1, 1100 the port number exposed by the proxy does not need to be well known, 1101 or require an IANA allocation. 1103 If the Proxy joins an Autonomic Control Plane 1104 ([I-D.ietf-anima-autonomic-control-plane]) it SHOULD use Autonomic 1105 Control Plane secured GRASP ([I-D.ietf-anima-grasp]) to discovery the 1106 Registrar address and port. As part of the discovery process, the 1107 proxy mechanism (Circuit Proxy vs IPIP encapsulation) is agreed to 1108 between the Registrar and Join Proxy. 1110 For the IPIP encapsulation methods (described in Appendix C), the 1111 port announced by the Proxy SHOULD be the same as on the registrar in 1112 order for the proxy to remain stateless. 1114 In order to permit the proxy functionality to be implemented on the 1115 maximum variety of devices the chosen mechanism SHOULD use the 1116 minimum amount of state on the proxy device. While many devices in 1117 the ANIMA target space will be rather large routers, the proxy 1118 function is likely to be implemented in the control plane CPU of such 1119 a device, with available capabilities for the proxy function similar 1120 to many class 2 IoT devices. 1122 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1123 more extensive analysis and background of the alternative proxy 1124 methods. 1126 4.1. Pledge discovery of Proxy 1128 The result of discovery is a logical communication with a Registrar, 1129 through a Proxy. The Proxy is transparent to the Pledge but is 1130 always assumed to exist. 1132 To discover the Proxy the Pledge performs the following actions: 1134 1. MUST: Obtains a local address using IPv6 methods as described in 1135 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1137 [RFC4941] temporary addresses is encouraged. A new temporary 1138 address SHOULD be allocated whenever the discovery process is 1139 forced to restart due to failures. Pledges will generally prefer 1140 use of IPv6 Link-Local addresses, and discovery of Proxy will be 1141 by Link-Local mechanisms. IPv4 methods are described in 1142 Appendix A 1144 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1145 announcements of the objective: "AN_Proxy". See section 1146 Section 4.1.1 for the details of the objective. The Pledge may 1147 listen concurrently for other sources of information, see 1148 Appendix B. 1150 Once a proxy is discovered the Pledge communicates with a Registrar 1151 through the proxy using the bootstrapping protocol defined in 1152 Section 5. 1154 Each discovery method attempted SHOULD exponentially back-off 1155 attempts (to a maximum of one hour) to avoid overloading the network 1156 infrastructure with discovery. The back-off timer for each method 1157 MUST be independent of other methods. 1159 Methods SHOULD be run in parallel to avoid head of queue problems 1160 wherein an attacker running a fake proxy or registrar can operate 1161 protocol actions intentionally slowly. 1163 Once a connection to a Registrar is established (e.g. establishment 1164 of a TLS session key) there are expectations of more timely 1165 responses, see Section 5.2. 1167 Once all discovered services are attempted the device SHOULD return 1168 to listening for GRASP M_FLOOD. It should periodically retry the 1169 vendor specific mechanisms. The Pledge MAY prioritize selection 1170 order as appropriate for the anticipated environment. 1172 4.1.1. Proxy Grasp announcements 1174 A proxy uses the GRASP M_FLOOD mechanism to announce itself. The 1175 pledge SHOULD listen for messages of these form. This announcement 1176 can be within the same message as the ACP announcement detailed in 1177 [I-D.ietf-anima-autonomic-control-plane]. The M_FLOOD is formatted 1178 as follows: 1180 [M_FLOOD, 12340815, h'fe80::1', 180000, 1181 ["AN_Proxy", 4, 1, ""], 1182 [O_IPv6_LOCATOR, 1183 h'fe80::1', 'TCP', 4443]] 1185 Figure 6b: Proxy Discovery 1187 The formal CDDL definition is: 1189 flood-message = [M_FLOOD, session-id, initiator, ttl, 1190 +[objective, (locator-option / [])]] 1192 objective = ["AN_Proxy", objective-flags, loop-count, 1193 objective-value] 1195 ttl = 180000 ; 180,000 ms (3 minutes) 1196 initiator = ACP address to contact Registrar 1197 objective-flags = sync-only ; as in GRASP spec 1198 sync-only = 4 ; M_FLOOD only requires synchronization 1199 loop-count = 1 ; one hop only 1200 objective-value = any ; none 1202 locator = [ O_IPv6_LOCATOR, ipv6-address, 1203 transport-proto, port-number ] 1204 ipv6-address = the v6 LL of the proxy 1205 transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 1206 port-number = selected by proxy 1208 Figure 6c: AN_Proxy CDDL 1210 4.2. CoAP connection to Registrar 1212 The use of CoAP to connect from Pledge to Registrar is out of scope 1213 for this document, and may be described in future work. 1215 4.3. HTTPS proxy connection to Registrar 1217 The proxy SHOULD also provide one of: an IPIP encapsulation of HTTP 1218 traffic to the registrar, or a TCP circuit proxy that connects the 1219 Pledge to a Registrar. 1221 When the Proxy provides a circuit proxy to a Registrar the Registrar 1222 MUST accept HTTPS connections. 1224 4.4. Proxy discovery of Registrar 1226 The Registrar SHOULD announce itself so that proxies can find it and 1227 determine what kind of connections can be terminated. 1229 The registrar announces itself using GRASP M_FLOOD messages. The 1230 M_FLOOD is formatted as follows: 1232 [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, 1233 ["AN_join_registrar", 4, 255, "EST-TLS"], 1234 [O_IPv6_LOCATOR, 1235 h'fda379a6f6ee0000200000064000001', TCP, 80 1237 Figure 6: Registrar Discovery 1239 The formal CDDL definition is: 1241 flood-message = [M_FLOOD, session-id, initiator, ttl, 1242 +[objective, (locator-option / [])]] 1244 objective = ["AN_join_registrar", objective-flags, loop-count, 1245 objective-value] 1247 initiator = ACP address to contact Registrar 1248 objective-flags = sync-only ; as in GRASP spec 1249 sync-only = 4 ; M_FLOOD only requires synchronization 1250 loop-count = 255 ; mandatory maximum 1251 objective-value = text ; name of the (list of) of supported 1252 ; protocols: "EST-TLS" for RFC7030. 1254 Figure 7: AN_join_registrar CDDL 1256 The M_FLOOD message MUST be sent periodically. The period is subject 1257 to network administrator policy (EST server configuration). It must 1258 be so low that the aggregate amount of periodic M_FLOODs from all EST 1259 servers causes negligible traffic across the ACP. 1261 The locators are to be interpreted as follows: 1263 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1264 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1265 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1267 Figure 7: Registrar Response 1269 The set of locators is to be interpreted as follows. A protocol of 6 1270 indicates that TCP proxying on the indicated port is desired. A 1271 protocol of 17 indicates that UDP proxying on the indicated port is 1272 desired. In each case, the traffic SHOULD be proxied to the same 1273 port at the ULA address provided. 1275 A protocol of 41 indicates that packets may be IPIP proxy'ed. In the 1276 case of that IPIP proxying is used, then the provided link-local 1277 address MUST be advertised on the local link using proxy neighbour 1278 discovery. The Join Proxy MAY limit forwarded traffic to the 1279 protocol (6 and 17) and port numbers indicated by locator1 and 1280 locator2. The address to which the IPIP traffic should be sent is 1281 the initiator address (an ACP address of the Registrar), not the 1282 address given in the locator. 1284 Registrars MUST accept TCP / UDP traffic on the ports given at the 1285 ACP address of the Registrar. If the Registrar supports IPIP 1286 ntunnelling, it MUST also accept traffic encapsulated with IPIP. 1288 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1289 Registrars MAY accept DTLS/CoAP/EST traffic on the UDP in addition to 1290 TCP traffic. 1292 5. Protocol Details 1294 The Pledge MUST initiate BRSKI after boot if it is unconfigured. The 1295 Pledge MUST NOT automatically initiate BRSKI if it has been 1296 configured or is in the process of being configured. 1298 BRSKI is described as extensions to EST [RFC7030] to reduce the 1299 number of TLS connections and crypto operations required on the 1300 Pledge. The Registrar implements the BRSKI REST interface within the 1301 same .well-known URI tree as the existing EST URIs as described in 1302 EST [RFC7030] section 3.2.2. The communication channel between the 1303 Pledge and the Registrar is referred to as "BRSKI-EST" (see 1304 Figure 1). 1306 The communication channel between the Registrar and MASA is similarly 1307 described as extensions to EST within the same ./well-known tree. 1308 For clarity this channel is referred to as "BRSKI-MASA". (See 1309 Figure 1). 1311 MASA URI is "https:// authority "./well-known/est". 1313 BRSKI uses EST message formats for existing operations, uses JSON 1314 [RFC7159] for all new operations defined here, and voucher formats. 1316 While EST section 3.2 does not insist upon use of HTTP 1.1 persistent 1317 connections, BRSKI-EST connections SHOULD use persistent connections. 1318 The intention of this guidance is to ensure the provisional TLS 1319 authentication occurs only once and is properly managed. 1321 Summarized automation extensions for the BRSKI-EST flow are: 1323 o The Pledge provisionally accepts the Registrar certificate during 1324 the TLS handshake as detailed in Section 5.1. 1326 o If the Registrar responds with a redirection to other web origins 1327 the Pledge MUST follow only a single redirection. (EST supports 1328 redirection but does not allow redirections to other web origins 1329 without user input). 1331 o The Registar MAY respond with an HTTP 202 ("the request has been 1332 accepted for processing, but the processing has not been 1333 completed") as described in EST [RFC7030] section 4.2.3 wherein 1334 the client "MUST wait at least the specified 'retry-after' time 1335 before repeating the same request". The Pledge is RECOMMENDED to 1336 provide local feed (blinked LED etc) during this wait cycle if 1337 mechanisms for this are available. To prevent an attacker 1338 Registrar from significantly delaying bootstrapping the Pledge 1339 MUST limit the 'retry-after' time to 60 seconds. To avoid 1340 blocking on a single erroneous Registrar the Pledge MUST drop the 1341 connection after 5 seconds in which there has been no progress on 1342 the TCP connection. It should proceed to other discovered 1343 Registrars if there are any. If there were no other Registrars 1344 discovered, the pledge MAY continue to wait, as long as it is 1345 concurrently listening for new proxy announcements. 1347 o Ideally the Pledge could keep track of the appropriate retry-after 1348 value for any number of outstanding Registrars but this would 1349 involve a large state table on the Pledge. Instead the pledge MAY 1350 ignore the exact retry-after value in favor of a single hard coded 1351 value that takes effect between discovery ([[ProxyDiscovery]]) 1352 attempts. A Registrar that is unable to complete the transaction 1353 the first time due to timing reasons will have future chances. 1355 o The Pledge requests and validates a voucher using the new REST 1356 calls described below. 1358 o If necessary the Pledge calls the EST defined /cacerts method to 1359 obtain the domain owners' CA certificate. The pinned-domain- 1360 certificate element from the voucher should validate this 1361 certificate, or be identical to it. 1363 o The Pledge completes authentication of the server certificate as 1364 detailed in Section 5.5.1. This moves the BRSKI-EST TLS 1365 connection out of the provisional state. Optionally, the BRSKI- 1366 EST TLS connection can now be used for EST enrollment. 1368 The extensions for a Registrar (equivalent to EST server) are: 1370 o Client authentication is automated using Initial Device Identity 1371 (IDevID) as per the EST certificate based client authentication. 1372 The subject field's DN encoding MUST include the "serialNumber" 1373 attribute with the device's unique serial number. In the language 1374 of RFC6125 this provides for a SERIALNUM-ID category of identifier 1375 that can be included in a certificate and therefore that can also 1376 be used for matching purposes. The SERIALNUM-ID whitelist is 1377 collated according to vendor trust anchor since serial numbers are 1378 not globally unique. 1380 o The Registrar requests and validates the Voucher from the vendor 1381 authorized MASA service. 1383 o The Registrar forwards the Voucher to the Pledge when requested. 1385 o The Registar performs log verifications in addition to local 1386 authorization checks before accepting optional Pledge device 1387 enrollment requests. 1389 5.1. BRSKI-EST TLS establishment details 1391 The Pledge establishes the TLS connection with the Registrar through 1392 the circuit proxy (see Section 4) but the TLS handshake is with the 1393 Registar. The BRSKI-EST Pledge is the TLS client and the BRSKI-EST 1394 Registrar is the TLS server. All security associations established 1395 are between the Pledge and the Registrar regardless of proxy 1396 operations. 1398 Establishment of the BRSKI-EST TLS connection is as specified in EST 1399 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1400 [RFC7030] wherein the client is authenticated with the IDevID 1401 certificate, and the EST server (the Registrar) is provisionally 1402 authenticated with a unverified server certificate. 1404 The Pledge maintains a security paranoia concerning the provisional 1405 state, and all data received, until a voucher is received and 1406 verified as specified in Section 5.5.1 1408 5.2. Pledge Requests Voucher from the Registrar 1410 When the Pledge bootstraps it makes a request for a Voucher from a 1411 Registrar. 1413 This is done with an HTTPS POST using the operation path value of 1414 "/.well-known/est/requestvoucher". 1416 The request media types are: 1418 application/voucher-cms+json The request is a "YANG-defined JSON 1419 document that has been signed using a CMS structure" as described 1420 in Section 3 using the JSON encoding described in [RFC7951]. The 1421 Pledge SHOULD sign the request using the Section 2.3 credential. 1423 application/json The request is the "YANG-defined JSON document" as 1424 described in Section 3 with exception that it is not within a 1425 PKCS#7 structure. It is protected only by the TLS client 1426 authentication. This reduces the cryptographic requirements on 1427 the Pledge. 1429 For simplicity the term 'voucher-request' is used to refer to either 1430 of these media types. Registrar impementations SHOULD anticipate 1431 future media types but of course will simply fail the request if 1432 those types are not yet known. 1434 The Pledge populates the voucher-request fields as follows: 1436 created-on: Pledges that have a realtime clock are RECOMMENDED to 1437 populate this field. This provides additional information to the 1438 MASA. 1440 nonce: The Pledge voucher-request MUST contain a cryptographically 1441 strong random or pseudo-random number nonce. Doing so ensures 1442 Section 2.5 functionality. The nonce MUST NOT be reused for 1443 bootstrapping attempts. 1445 assertion: The Pledge voucher-request MAY contain an assertion of 1446 "proximity". 1448 proximity-registrar-cert: In a Pledge voucher-request this is the 1449 first certificate in the TLS server 'certificate_list' sequence 1450 (see [RFC5246]) presented by the Registrar to the Pledge. This 1451 MUST be populated in a Pledge voucher-request if the "proximity" 1452 assertion is populated. 1454 All other fields MAY be omitted in the Pledge voucher-request. 1456 An example JSON payload of a Pledge voucher-request is in Section 3.2 1457 Example 1. 1459 The Registrar validates the client identity as described in EST 1460 [RFC7030] section 3.3.2. If the request is signed the Registrar 1461 confirms the 'proximity' asserion and associated 'proximity- 1462 registrar-cert' are correct. The registrar performs authorization as 1463 detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge 1464 Authorization"]]. If these validations fail the Registrar SHOULD 1465 respond with an appropriate HTTP error code. 1467 If authorization is successful the Registrar obtains a voucher from 1468 the MASA service (see Section 5.4) and returns that MASA signed 1469 voucher to the pledge as described in Section 5.5. 1471 5.3. BRSKI-MASA TLS establishment details 1473 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1474 appropriate for HTTPS REST interfaces. The Registrar initiates the 1475 connection and uses the MASA URL obtained as described in Section 2.7 1476 for RFC6125 authentication of the MASA server. 1478 The primary method of Registrar "authentication" by the MASA is 1479 detailed in Section 5.4. As detailed in Section 8 the MASA might 1480 find it necessary to request additional Registrar authentication. 1481 Registrars MUST be prepared to support TLS client certificate 1482 authentication and HTTP Basic or Digest authentication as described 1483 in RFC7030 for EST clients. Implementors are advised that contacting 1484 the MASA is to establish a secured REST connection with a web service 1485 and that there are a number of authentication models being explored 1486 within the industry. Registrars are RECOMMENDED to fail gracefully 1487 and generate useful administrative notifications or logs in the 1488 advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. 1490 5.4. Registrar Requests Voucher from MASA 1492 When a Registrar receives a Pledge voucher-request it in turn submits 1493 a Registrar voucher-request to the MASA service. For simplicity this 1494 is defined as an optional EST message between a Registrar and an EST 1495 server running on the MASA service although the Registrar is not 1496 required to make use of any other EST functionality when 1497 communicating with the MASA service. (The MASA service MUST properly 1498 reject any EST functionality requests it does not wish to service; a 1499 requirement that holds for any REST interface). 1501 This is done with an HTTP POST using the operation path value of 1502 "/.well-known/est/requestvoucher". 1504 The request media type is defined in [I-D.ietf-anima-voucher] and is 1505 application/voucher-cms+json. It is a JSON document that has been 1506 signed using a CMS structure. The Registrar MUST sign the Registrar 1507 voucher-request. The entire Registrar certificate chain, up to and 1508 including the Domain CA, MUST be included in the PKCS#7 structure. 1510 MASA impementations SHOULD anticipate future media types but of 1511 course will simply fail the request if those types are not yet known. 1513 The Registrar populates the voucher-request fields as follows: 1515 created-on: Registrars are RECOMMENDED to populate this field. This 1516 provides additional information to the MASA. 1518 nonce: The optional nonce value from the Pledge request if desired 1519 (see below). 1521 serial-number: The serial number of the Pledge the Registrar would 1522 like a voucher for. 1524 idevid-issuer: The idevid-issuer value from the pledge certificate 1525 is included to ensure a statistically unique identity. The 1526 Pledge's serial number is extracted from the X.509 IDevID. See 1527 Section 2.3. 1529 prior-signed-voucher: If a signed Pledge voucher-request was 1530 received then it SHOULD be included in the Registrar voucher- 1531 request. (NOTE: what is included is the complete Pledge voucher- 1532 request, inclusive of the 'assertion', 'proximity-registrar-cert', 1533 etc wrapped by the pledge's original signature). 1535 A nonceless Registrar voucher-request MAY be submitted to the MASA. 1536 Doing so allows the Registrar to request a Voucher when the Pledge is 1537 offline, or when the Registrar is expected to be offline when the 1538 Pledge is being deployed. These use cases require the Registrar to 1539 learn the appropriate IDevID SerialNumber field from the physical 1540 device labeling or from the sales channel (out-of-scope of this 1541 document). If a nonceless voucher-reqeust is submitted the MASA 1542 server MUST authenticate the Registrar as described in either EST 1543 [RFC7030] section 3.2, section 3.3, or by validating the Registrar's 1544 certificate used to sign the Registrar voucher-request. Any of these 1545 methods reduce the risk of DDoS attacks and provide an authenticated 1546 identity as an input to sales channel integration and authorizations 1547 (the actual sale-channel integration is also out-of-scope of this 1548 document). 1550 All other fields MAY be omitted in the Registrar voucher-request. 1552 Example JSON payloads of Registrar voucher-requests are in 1553 Section 3.2 Example 2 through 4. 1555 The MASA verifies that the Registrar voucher-request is internally 1556 consistent but does not necessarily authenticate the Registrar 1557 certificate since the registrar is not know to the MASA server in 1558 advance. The MASA validation checks before issuing a voucher are as 1559 follows: 1561 Renew for expired voucher: As described in [I-D.ietf-anima-voucher] 1562 vouchers are normally short lived to avoid revocation issues. If 1563 the request is for a previous (expired) voucher using the same 1564 Registrar (as determined by the Registrar pinned-domain-cert) and 1565 the MASA has not been informed that the claim is invalid then the 1566 request for a renewed voucher SHOULD be automatically authorized. 1568 Voucher signature consistency: The MASA MUST verify that the 1569 Registrar voucher-request is signed by a Registrar. This is 1570 confirmed by verifying that the id-kp-cmcRA extended key usage 1571 extension field (as detailed in EST RFC7030 section 3.6.1) exists 1572 in the certificate of the entity that signed the Registrar 1573 voucher-request. This verification is only a consistency check 1574 that the unauthenticated domain CA intended this to be a 1575 Registrar. Performing this check provides value to domain PKI by 1576 assuring the domain administrator that the MASA service will only 1577 respect claims from authorized Registration Authorities of the 1578 domain. (The requirement for the Registrar to include the Domain 1579 CA certificate in the signature structure was stated above). 1581 Registrar revocation consistency: The MASA SHOULD check for 1582 revocation of the Registrar certificate. The maximum lifetime of 1583 the voucher issued SHOULD NOT exceed the lifetime of the 1584 Registrar's revocation validation (for example if the Registrar 1585 revocation status is indicated in a CRL that is valid for two 1586 weeks then that is an appropriate lifetime for the voucher). 1587 Because the Registar certificate authority is unknown to the MASA 1588 in advance this is only an extended consistency check and is not 1589 required. The maximum lifetime of the voucher issued SHOULD NOT 1590 exceed the lifetime of the Registrar's revocation validation (for 1591 example if the Registrar revocation status is indicated in a CRL 1592 that is valid for two weeks then that is an appropriate lifetime 1593 for the voucher). 1595 Pledge proximity assertion: The MASA server MAY verify that the 1596 Registrar voucher-request includes the 'prior-signed-voucher' 1597 field populated with a Pledge voucher-request that includes a 1598 'proximity-registrar-cert' that is consistent with the certificate 1599 used to sign the Registrar voucher-request. The MASA server is 1600 aware of which Pledge's support signing of their voucher requests 1601 and can use this information to confirm proximity of the Pledge 1602 with the Registrar. 1604 Registar (certificate) authentication: This only occurs if the 1605 Registrar voucher-request is nonceless. As noted above the 1606 details concerning necessary sales-channel integration for the 1607 MASA to authenticate a Registrar certificate is out-of-scope. 1609 The Registrar's certificate chain is extracted from the signature 1610 method and the root certificate is used to populate the "pinned- 1611 domain-cert" of the Voucher being issued. The domainID (e.g. hash of 1612 the root public key) is determined from the pinned-domain-cert and is 1613 used to update the audit log. 1615 5.5. Voucher Response 1617 The voucher response to requests from the Pledge and requests from a 1618 Registrar are in the same format. A Registrar either caches prior 1619 MASA responses or dynamically requests a new Voucher based on local 1620 policy. 1622 If the join operation is successful, the server response MUST contain 1623 an HTTP 200 response code. The server MUST answer with a suitable 1624 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. The 1625 response data from the MASA server MUST be a plaintext human-readable 1626 (ASCII, english) error message containing explanatory information 1627 describing why the request was rejected. 1629 A 403 (Forbidden) response is appropriate if the voucher-request is 1630 not signed correctly, stale, or if the pledge has another outstanding 1631 voucher which can not be overridden. 1633 A 404 (Not Found) response is appropriate when the request is for a 1634 device which is not known to the MASA. 1636 A 406 (Not Acceptable) response is appropriate if a voucher of the 1637 desired type, or using the desired algorithms (as indicated by the 1638 Accept: headers, and algorithms used in the signature) can not be 1639 issued, such as because the MASA knows the pledge can not process 1640 that type. 1642 A 415 (Unsupported Media Type) response is approriate for a request 1643 that has a voucher encoding that is not understood. 1645 The response media type is: 1647 application/pkcs7-mime; smime-type=voucher The response is a "YANG- 1648 defined JSON document that has been signed using a PKCS#7 1649 structure" as described in [I-D.ietf-anima-voucher] using the JSON 1650 encoded described in [RFC7951]. The MASA MUST sign the request. 1652 The syntactic details of vouchers are described in detail in 1653 [I-D.ietf-anima-voucher]. For example, the voucher consists of: 1655 { 1656 "ietf-voucher:voucher": { 1657 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1658 "assertion": "logging" 1659 "pinned-domain-cert": "base64encodedvalue==" 1660 "serial-number": "JADA123456789" 1661 } 1662 } 1664 The Pledge verifies the signed voucher using the manufacturer 1665 installed trust anchor associated with the vendor's selected 1666 Manufacturer Authorized Signing Authority. 1668 The 'pinned-domain-cert' element of the voucher contains the domain 1669 CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust 1670 anchor to immediately complete authentication of the provisional TLS 1671 connection. 1673 The Pledge MUST be prepared to parse and fail gracefully from a 1674 Voucher response that does not contain a 'pinned-domain-cert' field. 1675 The Pledge MUST be prepared to ignore additional fields it does not 1676 recognize. 1678 5.5.1. Completing authentication of Provisional TLS connection 1680 If a Registrar's credentials can not be verified using the pinned- 1681 domain-cert trust anchor from the voucher then the TLS connection is 1682 immediately discarded and the Pledge abandons attempts to bootstrap 1683 with this discovered registrar. The pledge SHOULD send voucher 1684 status telemetry (described below) before closing the TLS connection. 1685 The pledge MUST attempt to enroll using any other proxies it has 1686 found. It SHOULD return to the same proxy again after attempting 1687 with other proxies. Attempts should be attempted in the exponential 1688 backoff described earlier. Attempts SHOULD be repeated as failure 1689 may be the result of a temporary inconsistently (an inconsistently 1690 rolled Registrar key, or some other mis-configuration). The 1691 inconsistently could also be the result an active MITM attack on the 1692 EST connection. 1694 The Registrar MUST use a certificate that chains to the pinned- 1695 domain-cert as its TLS server certificate. 1697 The Pledge's PKIX path validation of a Registrar certificate's 1698 validity period information is as described in Section 2.5. Once the 1699 PKIX path validation is successful the TLS connection is no longer 1700 provisional. 1702 The pinned-domain-cert is installed as an Explicit Trust Anchor for 1703 future operations. It can therefore can be used to authenticate any 1704 dynamically discovered EST server that contain the id-kp-cmcRA 1705 extended key usage extension as detailed in EST RFC7030 section 1706 3.6.1; but to reduce system complexity the Pledge SHOULD avoid 1707 additional discovery operations. Instead the Pledge SHOULD 1708 communicate directly with the Registrar as the EST server. The ' 1709 pinned-domain-cert' is not a complete distribution of the EST section 1710 4.1.3 CA Certificate Response which is an additional justification 1711 for the recommendation to proceed with EST key management operations. 1712 Once a full CA Certificate Response is obtained it is more 1713 authoritative for the domain than the limited 'pinned-domain-cert' 1714 response.' 1716 5.6. Voucher Status Telemetry 1718 The domain is expected to provide indications to the system 1719 administrators concerning device lifecycle status. To facilitate 1720 this it needs telemetry information concerning the device's status. 1722 To indicate Pledge status regarding the Voucher, the pledge MUST post 1723 a status message. 1725 The posted data media type: application/json 1727 The client HTTP POSTs the following to the server at the EST well 1728 known URI /voucher_status. The Status field indicates if the Voucher 1729 was acceptable. If it was not acceptable the Reason string indicates 1730 why. In the failure case this message is being sent to an 1731 unauthenticated, potentially malicious Registrar and therefore the 1732 Reason string SHOULD NOT provide information beneficial to an 1733 attacker. The operational benefit of this telemetry information is 1734 balanced against the operational costs of not recording that an 1735 Voucher was ignored by a client the registar expected to continue 1736 joining the domain. 1738 { 1739 "version":"1", 1740 "Status":FALSE /* TRUE=Success, FALSE=Fail" 1741 "Reason":"Informative human readable message" 1742 "reason-context": { additional JSON } 1743 } 1745 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1746 an HTTP 404 error. The client ignores any response. Within the 1747 server logs the server SHOULD capture this telemetry information. 1749 The reason-context attribute is an arbitrary JSON object (literal 1750 value or hash of values) which provides additional information 1751 specific to this pledge. The contents of this field are not subject 1752 to standardization." 1754 Additional standard responses MAY be added via Specification 1755 Required. 1757 5.7. MASA authorization log Request 1759 After receiving the voucher status telemetry Section 5.6, the 1760 Registrar SHOULD request the MASA authorization log from the MASA 1761 service using this EST extension. If a device had previously 1762 registered with another domain, a Registrar of that domain would show 1763 in the log. 1765 This is done with an HTTP GET using the operation path value of 1766 "/.well-known/est/requestauditlog". 1768 The Registrar MUST HTTP POSTs the same Registrar voucher-request as 1769 it did when requesting a Voucher. It is posted to the 1770 /requestauditlog URI instead. The "idevid-issuer" and "serial- 1771 number" informs the MASA server which log is requested so the 1772 appropriate log can be prepared for the response. Using the same 1773 media type and message minimizes cryptographic and message operations 1774 although it results in additional network traffic. The relying MASA 1775 server implementation MAY leverage internal state to associate this 1776 request with the original, and by now already validated, Registrar 1777 voucher-request so as to avoid an extra crypto validation. 1779 A MASA which receives a request for a device which does not exist, or 1780 for which the requesting owner was never an owner returns an HTTP 404 1781 ("Not found") code. 1783 Rather than returning the audit log as a response to the POST (with a 1784 return code 200), the MASA MAY instead return a 201 ("Created") 1785 RESTful response ([RFC7231] section 7.1) containing a URL to the 1786 prepared (and easily cachable) audit response. 1788 MASA servers that return URLs SHOULD take care to make the returned 1789 URL unguessable. URLs containing a database number such as 1790 https://example.com/auditlog/1234 or the EUI of the device such 1791 https://example.com/auditlog/10-00-00-11-22-33, would be easily 1792 enumerable by an attacker. It is recommended put to put some 1793 meaningless randomly generated slug that indexes a database instead. 1795 A MASA that returns a code 200 MAY also include a Location: header 1796 for future reference by the Registrar. 1798 The request media type is: 1800 application/voucher-cms+json The request is a "YANG-defined JSON 1801 document that has been signed using a CMS structure" as described 1802 in Section 3 using the JSON encoded described in [RFC7951]. The 1803 Registrar MUST sign the request. The entire Registrar certificate 1804 chain, up to and including the Domain CA, MUST be included in the 1805 CMS structure. 1807 5.7.1. MASA authorization log Response 1809 A log data file is returned consisting of all log entries. For 1810 example: 1812 { 1813 "version":"1", 1814 "events":[ 1815 { 1816 "date":"", 1817 "domainID":"", 1818 "nonce":"" 1819 }, 1820 { 1821 "date":"", 1822 "domainID":"", 1823 "nonce":"" 1824 } 1825 ], 1826 "truncation": { 1827 "nonced duplicates": , 1828 "nonceless duplicates": , 1829 "arbitrary": 1830 } 1831 } 1833 A Registrar SHOULD use this log information to make an informed 1834 decision regarding the continued bootstrapping of the Pledge. For 1835 example if the log includes an unexpected domainID then the Pledge 1836 could have imprinted on an unexpected domain. If the log includes 1837 nonceless entries then any registrar in the same domain could 1838 theoretically trigger a reset of the device and take over management 1839 of the Pledge. Equipment that is purchased pre-owned can be expected 1840 to have an extensive history. A Registrar MAY request logs at future 1841 times. A Registrar MAY be configured to ignore the history of the 1842 device but it is RECOMMENDED that this only be configured if hardware 1843 assisted NEA [RFC5209] is supported. 1845 Log entries can be compared against local history logs in search of 1846 discrepancies. 1848 Distribution of a large log is less than ideal. This structure can 1849 be optimized as follows: Nonced or Nonceless entries for the same 1850 domainID MAY be truncated from the log leaving only the single most 1851 recent nonced or nonceless entry. The log SHOULD NOT be further 1852 reduced but there could exist operational situation where maintaining 1853 the full log is not possible. In such situations the log MAY be 1854 arbitrarily truncated for length. The trunctation method(s) used 1855 MUST be indicated in the JSON truncation dictionary using "nonced 1856 duplicates", "nonceless duplicates", and "arbitrary" where the number 1857 of entries that have been truncation is indicated. If the truncation 1858 count exceeds 1024 then the MASA MAY use this value without further 1859 incrementing it. 1861 A log where duplicate entries for the same domain have been truncated 1862 ("nonced duplicates" and/or "nonceless duplicates) could still be 1863 acceptable for informed decisions. A log that has had "arbitrary" 1864 truncations is less acceptable but vendor transparency is better than 1865 hidden truncations. 1867 This document specifies a simple log format as provided by the MASA 1868 service to the registar. This format could be improved by 1869 distributed consensus technologies that integrate vouchers with a 1870 technologies such as block-chain or hash trees or optimized logging 1871 approaches. Doing so is out of the scope of this document but are 1872 anticipated improvements for future work. As such, the Registrar 1873 client SHOULD anticipate new kinds of responses, and SHOULD provide 1874 operator controls to indicate how to process unknown responses. 1876 5.8. EST Integration for PKI bootstrapping 1878 The Pledge SHOULD follow the BRSKI operations with EST enrollment 1879 operations including "CA Certificates Request", "CSR Attributes" and 1880 "Client Certificate Request" or "Server-Side Key Generation" etc. 1881 This is a relatively seamless integration since BRSKI REST calls 1882 provide an automated alternative to the manual bootstrapping method 1883 described in [RFC7030]. As noted above, use of HTTP 1.1 persistent 1884 connections simplifies the Pledge state machine. 1886 The Pledge is also RECOMMENDED to implement the following EST 1887 automation extensions. They supplement the RFC7030 EST to better 1888 support automated devices that do not have an end user. 1890 Although EST allows clients to obtain multiple certificates by 1891 sending multiple CSR requests BRSKI mandates use of the CSR 1892 Attributes request and mandates that the Registrar validate the CSR 1893 against the expected attributes. This implies that client requests 1894 will "look the same" and therefore result in a single logical 1895 certificate being issued even if the client were to make multiple 1896 requests. Registrars MAY contain more complex logic but doing so is 1897 out-of-scope of this specification. BRSKI does not signal any 1898 enhancement or restriction to this capability. Pledges that require 1899 multiple certificates could establish direct EST connections to the 1900 Registrar. 1902 5.8.1. EST Distribution of CA Certificates 1904 The Pledge MUST request the full EST Distribution of CA Certificates 1905 message. See RFC7030, section 4.1. 1907 This ensures that the Pledge has the complete set of current CA 1908 certificates beyond the pinned-domain-cert (see Section 5.5.1 for a 1909 discussion of the limitations inherent in having a single certificate 1910 instead of a full CA Certificates response). Although these 1911 limitations are acceptable during initial bootstrapping they are not 1912 appropriate for ongoing PKIX end entity certificate validation. 1914 5.8.2. EST CSR Attributes 1916 Automated bootstrapping occurs without local administrative 1917 configuration of the Pledge. In some deployments its plausible that 1918 the Pledge generates a certificate request containing only identity 1919 information known to the Pledge (essentially the X.509 IDevID 1920 information) and ultimately receives a certificate containing domain 1921 specific identity information. Conceptually the CA has complete 1922 control over all fields issued in the end entity certificate. 1923 Realistically this is operationally difficult with the current status 1924 of PKI certificate authority deployments where the CSR is submitted 1925 to the CA via a number of non-standard protocols. Even with all 1926 standardized protocols used, it could operationally be problematic to 1927 expect that service specific certificate fields can be created by a 1928 CA that is likely operated by a group that has no insight into 1929 different network services/protocols used. For example, the CA could 1930 even be outsourced. 1932 To alleviate these operational difficulties, the Pledge MUST request 1933 the EST "CSR Attributes" from the EST server and the EST server needs 1934 to be able to reply with the attributes necessary for use of the 1935 certificate in its intended protocols/services. This approach allows 1936 for minimal CA integrations and instead the local infrastructure (EST 1937 server) informs the Pledge of the proper fields to include in the 1938 generated CSR. This approach is beneficial to automated boostrapping 1939 in the widest number of environments. 1941 If the hardwareModuleName in the X.509 IDevID is populated then it 1942 SHOULD by default be propagated to the LDevID along with the 1943 hwSerialNum. The EST server SHOULD support local policy concerning 1944 this functionality. 1946 In networks using the BRSKI enrolled certificate to authenticate the 1947 ACP (Autonomic Control Plane), the EST attributes MUST include the 1948 "ACP information" field. See 1949 [I-D.ietf-anima-autonomic-control-plane] for more details. 1951 The Registar MUST also confirm the resulting CSR is formatted as 1952 indicated before forwarding the request to a CA. If the Registar is 1953 communicating with the CA using a protocol like full CMC which 1954 provides mechanisms to override the CSR attributes, then these 1955 mechanisms MAY be used even if the client ignores CSR Attribute 1956 guidance. 1958 5.8.3. EST Client Certificate Request 1960 The Pledge MUST request a new client certificate. See RFC7030, 1961 section 4.2. 1963 5.8.4. Enrollment Status Telemetry 1965 For automated bootstrapping of devices the adminstrative elements 1966 providing bootstrapping also provide indications to the system 1967 administrators concerning device lifecycle status. This might 1968 include information concerning attempted bootstrapping messages seen 1969 by the client, MASA provides logs and status of credential 1970 enrollment. The EST protocol assumes an end user and therefore does 1971 not include a final success indication back to the server. This is 1972 insufficient for automated use cases. 1974 To indicate successful enrollment the client SHOULD re-negotiate the 1975 EST TLS session using the newly obtained credentials. This occurs by 1976 the client initiating a new TLS ClientHello message on the existing 1977 TLS connection. The client MAY simply close the old TLS session and 1978 start a new one. The server MUST support either model. 1980 In the case of a FAIL the Reason string indicates why the most recent 1981 enrollment failed. The SubjectKeyIdentifier field MUST be included 1982 if the enrollment attempt was for a keypair that is locally known to 1983 the client. If EST /serverkeygen was used and failed then the field 1984 is omitted from the status telemetry. 1986 In the case of a SUCCESS the Reason string is omitted. The 1987 SubjectKeyIdentifier is included so that the server can record the 1988 successful certificate distribution. 1990 Status media type: application/json 1992 The client HTTP POSTs the following to the server at the new EST well 1993 known URI /enrollstatus. 1995 { 1996 "version":"1", 1997 "Status":TRUE /* TRUE=Success, FALSE=Fail" 1998 "Reason":"Informative human readable message" 1999 "reason-context": "Additional information" 2000 } 2002 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2003 an HTTP 404 error. 2005 Within the server logs the server MUST capture if this message was 2006 received over an TLS session with a matching client certificate. 2007 This allows for clients that wish to minimize their crypto operations 2008 to simply POST this response without renegotiating the TLS session - 2009 at the cost of the server not being able to accurately verify that 2010 enrollment was truly successful. 2012 5.8.5. EST over CoAP 2014 This document describes extensions to EST for the purposes of 2015 bootstrapping of remote key infrastructures. Bootstrapping is 2016 relevant for CoAP enrollment discussions as well. The defintion of 2017 EST and BRSKI over CoAP is not discussed within this document beyond 2018 ensuring proxy support for CoAP operations. Instead it is 2019 anticipated that a definition of CoAP mappings will occur in 2020 subsequent documents such as [I-D.vanderstok-ace-coap-est] and that 2021 CoAP mappings for BRSKI will be discussed either there or in future 2022 work. 2024 6. Reduced security operational modes 2026 A common requirement of bootstrapping is to support less secure 2027 operational modes for support specific use cases. The following 2028 sections detail specific ways that the Pledge, Registrar and MASA can 2029 be configured to run in a less secure mode for the indicated reasons. 2031 6.1. Trust Model 2032 +--------+ +---------+ +------------+ +------------+ 2033 | Pledge | | Circuit | | Domain | | Vendor | 2034 | | | Proxy | | Registrar | | Service | 2035 | | | | | | | (Internet | 2036 +--------+ +---------+ +------------+ +------------+ 2038 Figure 10 2040 Pledge: The Pledge could be compromised and providing an attack 2041 vector for malware. The entity is trusted to only imprint using 2042 secure methods described in this document. Additional endpoint 2043 assessment techniques are RECOMMENDED but are out-of-scope of this 2044 document. 2046 Proxy: Provides proxy functionalities but is not involved in 2047 security considerations. 2049 Registrar: When interacting with a MASA server a Registrar makes all 2050 decisions. When Ownership Vouchers are involved a Registrar is 2051 only a conduit and all security decisions are made on the vendor 2052 service. 2054 Vendor Service, MASA: This form of vendor service is trusted to 2055 accurately log all claim attempts and to provide authoritative log 2056 information to Registrars. The MASA does not know which devices 2057 are associated with which domains. These claims could be 2058 strengthened by using cryptographic log techniques to provide 2059 append only, cryptographic assured, publicly auditable logs. 2060 Current text provides only for a trusted vendor. 2062 Vendor Service, Ownership Validation: This form of vendor service is 2063 trusted to accurately know which device is owned by which domain. 2065 6.2. Pledge security reductions 2067 The Pledge can choose to accept vouchers using less secure methods. 2068 These methods enable offline and emergency (touch based) deployment 2069 use cases: 2071 1. The Pledge MUST accept nonceless vouchers. This allows for 2072 offline use cases. Logging and validity periods address the 2073 inherent security considerations of supporting these use cases. 2075 2. The Pledge MAY support "trust on first use" for physical 2076 interfaces such as a local console port or physical user 2077 interface but MUST NOT support "trust on first use" on network 2078 interfaces. This is because "trust on first use" permanently 2079 degrades the security for all use cases. 2081 3. The Pledge MAY have an operational mode where it skips Voucher 2082 validation one time. For example if a physical button is 2083 depressed during the bootstrapping operation. This can be useful 2084 if the vendor service is unavailable. This behavior SHOULD be 2085 available via local configuration or physical presence methods to 2086 ensure new entities can always be deployed even when autonomic 2087 methods fail. This allows for unsecured imprint. 2089 It is RECOMMENDED that "trust on first use" or skipping voucher 2090 validation only be available if hardware assisted Network Endpoint 2091 Assessment [RFC5209] is supported. This recommendation ensures that 2092 domain network monitoring can detect innappropriate use of offline or 2093 emergency deployment procedures. 2095 6.3. Registrar security reductions 2097 A Registrar can choose to accept devices using less secure methods. 2098 These methods are acceptable when low security models are needed, as 2099 the security decisions are being made by the local administrator, but 2100 they MUST NOT be the default behavior: 2102 1. A registrar MAY choose to accept all devices, or all devices of a 2103 particular type, at the administrator's discretion. This could 2104 occur when informing all Registrars of unique identifiers of new 2105 entities might be operationally difficult. 2107 2. A registrar MAY choose to accept devices that claim a unique 2108 identity without the benefit of authenticating that claimed 2109 identity. This could occur when the Pledge does not include an 2110 X.509 IDevID factory installed credential. New Entities without 2111 an X.509 IDevID credential MAY form the Section 5.2 request using 2112 the Section 5.4 format to ensure the Pledge's serial number 2113 information is provided to the Registar (this includes the IDevID 2114 AuthorityKeyIdentifier value which would be statically configured 2115 on the Pledge). The Pledge MAY refuse to provide a TLS client 2116 certificate (as one is not available). The Pledge SHOULD support 2117 HTTP-based or certificate-less TLS authentication as described in 2118 EST RFC7030 section 3.3.2. A Registrar MUST NOT accept 2119 unauthenticated New Entities unless it has been configured to do 2120 so by an administrator that has verified that only expected new 2121 entities can communicate with a Registrar (presumably via a 2122 physically secured perimeter). 2124 3. A Registrar MAY submit a nonceless voucher-requests to MASA 2125 service (by not including a nonce in the voucher-request). The 2126 resulting Vouchers can then be stored by the Registrar until they 2127 are needed during bootstrapping operations. This is for use 2128 cases where target network is protected by an air gap and 2129 therefore can not contact the MASA service during Pledge 2130 deployment. 2132 4. A registrar MAY ignore unrecognized nonceless log entries. This 2133 could occur when used equipment is purchased with a valid history 2134 being deployed in air gap networks that required permanent 2135 Vouchers. 2137 6.4. MASA security reductions 2139 Lower security modes chosen by the MASA service effect all device 2140 deployments unless bound to the specific device identities. In which 2141 case these modes can be provided as additional features for specific 2142 customers. The MASA service can choose to run in less secure modes 2143 by: 2145 1. Not enforcing that a nonce is in the Voucher. This results in 2146 distribution of Voucher that never expires and in effect makes 2147 the Domain an always trusted entity to the Pledge during any 2148 subsequent bootstrapping attempts. That this occurred is 2149 captured in the log information so that the Registrar can make 2150 appropriate security decisions when a Pledge joins the Domain. 2151 This is useful to support use cases where Registrars might not be 2152 online during actual device deployment. Because this results in 2153 long lived Voucher and does not require the proof that the device 2154 is online this is only accepted when the Registrar is 2155 authenticated by the MASA server and authorized to provide this 2156 functionality. The MASA server is RECOMMENDED to use this 2157 functionality only in concert with an enhanced level of ownership 2158 tracking (out-of-scope). If the Pledge device is known to have a 2159 real-time-clock that is set from the factory use of a voucher 2160 validity period is RECOMMENDED. 2162 2. Not verifying ownership before responding with an Voucher. This 2163 is expected to be a common operational model because doing so 2164 relieves the vendor providing MASA services from having to track 2165 ownership during shipping and supply chain and allows for a very 2166 low overhead MASA service. A Registrar uses the audit log 2167 information as a defense in depth strategy to ensure that this 2168 does not occur unexpectedly (for example when purchasing new 2169 equipment the Registrar would throw an error if any audit log 2170 information is reported). The MASA should verify the 'prior- 2171 signed-voucher' information for Pledge's that support that 2172 functionality. This provides a proof-of-proximity check that 2173 reduces the need for ownership verification. 2175 7. IANA Considerations 2177 This document requires the following IANA actions: 2179 7.1. PKIX Registry 2181 IANA is requested to register the following: 2183 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 2184 the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] 2186 This document requests a number from the id-pe registry for id-pe- 2187 masa-url. XXX 2189 7.2. Voucher Status Telemetry 2191 IANA is requested to create a registry entitled: _Voucher Status 2192 Telemetry Attributes_. New items can be added using the 2193 Specification Required. The following items are to be in the initial 2194 registration, with this document as the reference: 2196 o version 2198 o Status 2200 o Reason 2202 o reason-context 2204 8. Security Considerations 2206 There are uses cases where the MASA could be unavailable or 2207 uncooperative to the Registrar. They include planned and unplanned 2208 network partitions, changes to MASA policy, or other instances where 2209 MASA policy rejects a claim. These introduce an operational risk to 2210 the Registrar owner that MASA/vendor behavior might limit the ability 2211 to re-boostrap a Pledge device. For example this might be an issue 2212 during disaster recovery. This risk can be mitigated by Registrars 2213 that request and maintain long term copies of "nonceless" Vouchers. 2214 In that way they are guaranteed to be able to repeat bootstrapping 2215 for their devices. 2217 The issuance of nonceless vouchers themselves create a security 2218 concern. If the Registrar of a previous domain can intercept 2219 protocol communications then it can use a previously issued nonceless 2220 voucher to establish management control of a pledge device even after 2221 having sold it. This risk is mitigated by recording the issuance of 2222 such vouchers in the MASA audit log that is verified by the 2223 subsequent Registrar. This reduces the resale value of the equipment 2224 because future owners will detect the lowered security inherent in 2225 the existence of a nonceless voucher that would be trusted by their 2226 Pledge. This reflects a balance between partition resistant recovery 2227 and security of future bootstrapping. Registrars take the Pledge's 2228 audit history into account when applying policy to new devices. 2230 The MASA server is exposed to DoS attacks wherein attackers claim an 2231 unbounded number of devices. Ensuring a Registrar is representative 2232 of a valid vendor customer, even without validating ownership of 2233 specific Pledge devices, helps to mitigate this. Pledge signatures 2234 on the Pledge voucher-request, as forwarded by the Registrar in the 2235 prior-signed-voucher field of the Registrar voucher-request, 2236 significantly reduce this risk by ensuring the MASA can confirm 2237 proximity between the Pledge and the Registrar making the request. 2238 This mechanism is optional to allow for constrained devices. 2240 To facilitate logging and administrative oversight in addition to 2241 triggering Registration verification of MASA logs the Pledge reports 2242 on Voucher parsing status to the Registrar. In the case of a failure 2243 this information is informative to a potentially malicious Registar 2244 but this is mandated anyway because of the operational benefits of an 2245 informed administrator in cases where the failure is indicative of a 2246 problem. The Registrar is RECOMMENDED to verify MASA logs if voucher 2247 status telemetry is not received. 2249 The MASA authorization log includes a hash of the domainID for each 2250 registrar a voucher has been issued to. This information is closely 2251 related to the actual domain identity, especially when paired with 2252 the anti-DDoS authentication information the MASA might collect. 2253 This could provide sufficient information for the MASA service to 2254 build a detailed understanding the devices that have been provisioned 2255 within a domain. There are a number of design choices that mitigate 2256 this risk. The domain can maintain some privacy since it has not 2257 necessarily been authenticated and is not authoritatively bound to 2258 the supply chain. Additionally the domainID captures only the 2259 unauthenticated subject key identifier of the domain. A privacy 2260 sensitive domain could theoretically generate a new domainID for each 2261 device being deployed. Similarly a privacy sensitive domain would 2262 likely purchase devices that support proximity assertions from a 2263 vendor that does not require sales channel integrations. This would 2264 result in a significant level of privacy while maintaining the 2265 security characteristics provided by Registrar based audit log 2266 inspection. 2268 To facilitate truely limited clients EST RFC7030 section 3.3.2 2269 requirements that the client MUST support a client authentication 2270 model have been reduced in Section 6 to a statement that the 2271 Registrar "MAY" choose to accept devices that fail cryptographic 2272 authentication. This reflects current (poor) practices in shipping 2273 devices without a cryptographic identity that are NOT RECOMMENDED. 2275 During the provisional period of the connection the Pledge MUST treat 2276 all HTTP header and content data as untrusted data. HTTP libraries 2277 are regularly exposed to non-secured HTTP traffic: mature libraries 2278 should not have any problems. 2280 Pledge's might chose to engage in protocol operations with multiple 2281 discovered Registrars in parallel. As noted above they will only do 2282 so with distinct nonce values, but the end result could be multiple 2283 voucher's issued from the MASA if all registrars attempt to claim the 2284 device. This is not a failure and the Pledge choses whichever 2285 voucher to accept based on internal logic. The Registrar's verifying 2286 log information will see multiple entries and take this into account 2287 for their analytics purposes. 2289 8.1. Freshness in Voucher-Requests 2291 A concern has been raised that the Pledge voucher-request should 2292 contain some content (a nonce) provided by the Registrar and/or MASA 2293 in order for those actors to verify that the Pledge voucher-request 2294 is fresh. 2296 There are a number of operational problems with getting a nonce from 2297 the MASA to the pledge. It is somewhat easier to collect a random 2298 value from the Registrar, but as the Registrar is not yet vouched 2299 for, such a Registrar nonce has little value. There are privacy and 2300 logistical challenges to addressing these operational issues, so if 2301 such a thing were to be considered, it would have to provide some 2302 clear value. This section examines the impacts of not having a fresh 2303 Pledge voucher-request. 2305 Because the Registrar authenticates the Pledge a full Man-in-the- 2306 Middle attack is not possible, despite the provisional TLS 2307 authentication by the Pledge (see Section 5). Instead we examine the 2308 case of a fake Registrar (Rm) that communicates with the Pledge in 2309 parallel or in close time proximity with the intended Registrar. 2310 (This scenario is intentionally supported as described in 2311 Section 4.1). 2313 The fake Registrar (Rm) can obtain a voucher signed by the MASA 2314 either directly or through arbitrary intermediaries. Assuming that 2315 the MASA accepts the Registar voucher-request (either because Rm is 2316 collaborating with a legitimate Registrar according to supply chain 2317 information, or because the MASA is in audit-log only mode), then a 2318 voucher linking the pledge to the Registrar Rm is issued. 2320 Such a voucher, when passed back to the Pledge, would link the pledge 2321 to Registrar Rm, and would permit the Pledge to end the provisional 2322 state. It now trusts Rm and, if it has any security vulnerabilities 2323 leveragable by an Rm with full administrative control, can be assumed 2324 to be a threat against the intended Registrar. 2326 This flow is mitigated by the intended Registar verifying the audit 2327 logs available from the MASA as described in Section 5.7. Rm might 2328 chose to wait until after the intended Registrar completes the 2329 authorization process before submitting the now-stale Pledge voucher- 2330 request. The Rm would need to remove the Pledge's nonce. 2332 In order to successfully use the resulting "stale voucher" Rm would 2333 have to attack the Pledge and return it to a bootstrapping enabled 2334 state. This would require wiping the Pledge of current configuration 2335 and triggering a re-bootstrapping of the Pledge. This is no more 2336 likely than simply taking control of the Pledge directly but if this 2337 is a consideration the target network is RECOMMENDED to take the 2338 following steps: 2340 o Ongoing network monitoring for unexpected bootstrapping attempts 2341 by Pledges. 2343 o Retreival and examination of MASA log information upon the 2344 occurance of any such unexpected events. Rm will be listed in the 2345 logs. 2347 9. Acknowledgements 2349 We would like to thank the various reviewers for their input, in 2350 particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear, 2351 Sergey Kasatkin, Markus Stenberg, and Peter van der Stok 2353 10. References 2355 10.1. Normative References 2357 [I-D.ietf-anima-autonomic-control-plane] 2358 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2359 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2360 plane-13 (work in progress), December 2017. 2362 [I-D.ietf-anima-grasp] 2363 Bormann, C., Carpenter, B., and B. Liu, "A Generic 2364 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 2365 grasp-15 (work in progress), July 2017. 2367 [I-D.ietf-anima-voucher] 2368 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2369 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 2370 anima-voucher-07 (work in progress), January 2018. 2372 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 2373 December 2009, . 2376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2377 Requirement Levels", BCP 14, RFC 2119, 2378 DOI 10.17487/RFC2119, March 1997, 2379 . 2381 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 2382 "Advanced Sockets Application Program Interface (API) for 2383 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 2384 . 2386 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2387 Levkowetz, Ed., "Extensible Authentication Protocol 2388 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2389 . 2391 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 2392 Configuration of IPv4 Link-Local Addresses", RFC 3927, 2393 DOI 10.17487/RFC3927, May 2005, 2394 . 2396 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2397 Address Autoconfiguration", RFC 4862, 2398 DOI 10.17487/RFC4862, September 2007, 2399 . 2401 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2402 Extensions for Stateless Address Autoconfiguration in 2403 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2404 . 2406 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2407 (TLS) Protocol Version 1.2", RFC 5246, 2408 DOI 10.17487/RFC5246, August 2008, 2409 . 2411 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2412 Housley, R., and W. Polk, "Internet X.509 Public Key 2413 Infrastructure Certificate and Certificate Revocation List 2414 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2415 . 2417 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 2418 Security: An Unauthenticated Mode of IPsec", RFC 5386, 2419 DOI 10.17487/RFC5386, November 2008, 2420 . 2422 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2423 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2424 . 2426 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 2427 RFC 5660, DOI 10.17487/RFC5660, October 2009, 2428 . 2430 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2431 DOI 10.17487/RFC6762, February 2013, 2432 . 2434 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2435 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2436 . 2438 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2439 "Enrollment over Secure Transport", RFC 7030, 2440 DOI 10.17487/RFC7030, October 2013, 2441 . 2443 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2444 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2445 2014, . 2447 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2448 Constrained-Node Networks", RFC 7228, 2449 DOI 10.17487/RFC7228, May 2014, 2450 . 2452 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2453 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2454 . 2456 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2457 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2458 . 2460 10.2. Informative References 2462 [I-D.behringer-homenet-trust-bootstrap] 2463 Behringer, M., Pritikin, M., and S. Bjarnason, 2464 "Bootstrapping Trust on a Homenet", draft-behringer- 2465 homenet-trust-bootstrap-02 (work in progress), February 2466 2014. 2468 [I-D.ietf-netconf-zerotouch] 2469 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 2470 Provisioning for NETCONF or RESTCONF based Management", 2471 draft-ietf-netconf-zerotouch-19 (work in progress), 2472 October 2017. 2474 [I-D.ietf-opsawg-mud] 2475 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 2476 Description Specification", draft-ietf-opsawg-mud-15 (work 2477 in progress), January 2018. 2479 [I-D.richardson-anima-state-for-joinrouter] 2480 Richardson, M., "Considerations for stateful vs stateless 2481 join router in ANIMA bootstrap", draft-richardson-anima- 2482 state-for-joinrouter-02 (work in progress), January 2018. 2484 [I-D.vanderstok-ace-coap-est] 2485 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 2486 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 2487 coaps)", draft-vanderstok-ace-coap-est-04 (work in 2488 progress), January 2018. 2490 [imprinting] 2491 Wikipedia, "Wikipedia article: Imprinting", July 2015, 2492 . 2494 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2495 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2496 December 1998, . 2498 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2499 Interface Identifiers with IPv6 Stateless Address 2500 Autoconfiguration (SLAAC)", RFC 7217, 2501 DOI 10.17487/RFC7217, April 2014, 2502 . 2504 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2505 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2506 DOI 10.17487/RFC7231, June 2014, 2507 . 2509 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2510 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2511 December 2014, . 2513 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2514 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2515 Networking: Definitions and Design Goals", RFC 7575, 2516 DOI 10.17487/RFC7575, June 2015, 2517 . 2519 [Stajano99theresurrecting] 2520 Stajano, F. and R. Anderson, "The resurrecting duckling: 2521 security issues for ad-hoc wireless networks", 1999, 2522 . 2525 Appendix A. IPv4 operations 2527 A.1. IPv4 Link Local addresses 2529 Instead of an IPv6 link-local address, an IPv4 address may be 2530 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 2531 Addresses. 2533 In the case that an IPv4 Local-Local address is formed, then the 2534 bootstrap process would continue as in the IPv6 case by looking for a 2535 (circuit) proxy. 2537 A.2. Use of DHCPv4 2539 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 2540 provided parameters for the Domain Name System can be used to perform 2541 DNS operations if all local discovery attempts fail. 2543 Appendix B. mDNS / DNSSD proxy discovery options 2545 The Pledge MAY perform DNS-based Service Discovery [RFC6763] over 2546 Multicast DNS [RFC6762] searching for the service 2547 "_bootstrapks._tcp.local.". 2549 To prevent unaccceptable levels of network traffic the congestion 2550 avoidance mechanisms specified in [RFC6762] section 7 MUST be 2551 followed. The Pledge SHOULD listen for an unsolicited broadcast 2552 response as described in [RFC6762]. This allows devices to avoid 2553 announcing their presence via mDNS broadcasts and instead silently 2554 join a network by watching for periodic unsolicited broadcast 2555 responses. 2557 Performs DNS-based Service Discovery [RFC6763] over normal DNS 2558 operations. The service searched for is 2559 "_bootstrapks._tcp.example.com". In this case the domain 2560 "example.com" is discovered as described in [RFC6763] section 11. 2561 This method is only available if the host has received a useable IPv4 2562 address via DHCPv4 as suggested in Appendix A. 2564 If no local bootstrapks service is located using the GRASP 2565 mechanisms, or the above mentioned DNS-based Service Discovery 2566 methods the Pledge MAY contact a well known vendor provided 2567 bootstrapping server by performing a DNS lookup using a well known 2568 URI such as "bootstrapks.vendor-example.com". The details of the URI 2569 are vendor specific. Vendors that leverage this method on the Pledge 2570 are responsible for providing the bootstrapks service. 2572 The current DNS services returned during each query is maintained 2573 until bootstrapping is completed. If bootstrapping fails and the 2574 Pledge returns to the Discovery state it picks up where it left off 2575 and continues attempting bootstrapping. For example if the first 2576 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 2577 second and third responses are tried. If these fail the Pledge moves 2578 on to normal DNS-based Service Discovery. 2580 Appendix C. IPIP Join Proxy mechanism 2582 The Circuit Proxy mechanism suffers from requiring a state on the 2583 Join Proxy for each connection that is relayed. The Circuit Proxy 2584 can be considered a kind of Algorithm Gateway [FIND-good-REF]. 2586 An alternative to proxying at the TCP layer is to selectively forward 2587 at the IP layer. This moves all per-connection to the Join 2588 Registrar. The IPIP tunnel statelessly forwards packets. This 2589 section provides some explanation of some of the details of the 2590 Registrar discovery procotol which are not important to Circuit 2591 Proxy, and some implementation advice. 2593 The IPIP tunnel is described in [RFC2473]. Each such tunnel is 2594 considered a unidirectional construct, but two tunnels may be 2595 associated to form a bidirectional mechanism. An IPIP tunnel is 2596 setup as follows. The outer addresses are an ACP address of the Join 2597 Proxy, and the ACP address of the Join Registrar. The inner 2598 addresses seen in the tunnel are the link-local addresses of the 2599 network on which the join activity is occuring. 2601 One way to look at this construct is to consider that the Registrar 2602 is extending attaching an interface to the network on which the Join 2603 Proxy is physically present. The Registrar then interacts as if it 2604 were present on that network using link-local (fe80::) addresses. 2606 The Join node is unaware that the traffic is being proxied through a 2607 tunnel, and does not need any special routing. 2609 There are a number of considerations with this mechanism which 2610 require cause some minor amounts of complexity. Note that due to the 2611 tunnels, the Registrar sees multiple connections to a fe80::/10 2612 network on not just physical interfaces, but on each of the virtual 2613 interfaces represending the tunnels. 2615 C.1. Multiple Join networks on the Join Proxy side 2617 The Join Proxy will in the general case be a routing device with 2618 multiple interfaces. Even a device as simple as a wifi access point 2619 may have wired, and multiple frequencies of wireless interfaces, 2620 potentially with multiple ESSIDs. 2622 Each of these interfaces on the Join Proxy may be seperate L3 routing 2623 domains, and therefore will have a unique set of link-local 2624 addresses. An IPIP packet being returned by the Registrar needs to 2625 be forwarded to the correct interface, so the Join Proxy needs an 2626 additional key to distinguish which network the packet should be 2627 returned to. 2629 The simplest way to get this additional key is to allocate an 2630 additional ACP address; one address for each network on which join 2631 traffic is occuring. The Join Proxy SHOULD do a GRASP M_NEG_SYN for 2632 each interface which they wish to relay traffic, as this allows the 2633 Registrar to do any static tunnel configuration that may be required. 2635 C.2. Automatic configuration of tunnels on Registrar 2637 The Join Proxy is expected to do a GRASP negotiation with the proxy 2638 for each Join Interface that it needs to relay traffic from. This is 2639 to permit Registrars to configure the appropriate virtual interfaces 2640 before join traffic arrives. 2642 A Registrar serving a large number of interfaces may not wish to 2643 allocate resources to every interface at all times, but can instead 2644 dynamically allocate interfaces. It can do this by monitoring IPIP 2645 traffic that arrives on it's ACP interface, and when packets arrive 2646 from new Join Proxys, it can dynamically configure virtual 2647 interfaces. 2649 A more sophisticated Registrar willing to modify the behaviour of 2650 it's TCP and UDP stack could note the IPIP traffic origination in the 2651 socket control block and make information available to the TCP layer 2652 (for HTTPS connections), or to the application (for CoAP connections) 2653 via a proprietary extension to the socket API. 2655 C.3. Proxy Neighbor Discovery by Join Proxy 2657 The Join Proxy MUST answer neighbor discovery messages for the 2658 address given by the Registrar as being it's link-local address. The 2659 Join Proxy must also advertise this address as the address to which 2660 to connect to when advertising it's existence. 2662 This proxy neighbor discovery means that the pledge will create TCP 2663 and UDP connections to the correct Registrar address. This matters 2664 as the TCP and UDP pseudo-header checksum includes the destination 2665 address, and for the proxy to remain completely stateless, it must 2666 not be necessary for the checksum to be updated. 2668 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on Registrar 2670 TCP connections on the registrar SHOULD properly capture the ifindex 2671 of the incoming connection into the socket structure. This is normal 2672 IPv6 socket API processing. The outgoing responses will go out on 2673 the same (virtual) interface by ifindex. 2675 When using UDP sockets with CoAP, the application will have to pay 2676 attention to the incoming ifindex on the socket. Access to this 2677 information is available using the IP_PKTINFO auxiliary extension 2678 which is a standard part of the IPv6 sockets API. 2680 A registrar application could, after receipt of an initial CoAP 2681 message from the Pledge, create a connected UDP socket (including the 2682 ifindex information). The kernel would then take care of accurate 2683 demultiplexing upon receive, and subsequent transmission to the 2684 correct interface. 2686 C.5. Use of socket extension rather than virtual interface 2688 Some operating systems on which a Registrar need be implemented may 2689 find need for a virtual interface per Join Proxy to be problematic. 2690 There are other mechanism which can make be done. 2692 If the IPIP decapsulator can mark the (SYN) packet inside the kernel 2693 with the address of the Join Proxy sending the traffic, then an 2694 interface per Join Proxy may not be needed. The outgoing path need 2695 just pay attention to this extra information and add an appropriate 2696 IPIP header on outgoing. A CoAP over UDP mechanism may need to 2697 expose this extra information to the application as the UDP sockets 2698 are often not connected, and the application will need to specify the 2699 outgoing path on each packet send. 2701 Such an additional socket mechanism has not been standardized. 2702 Terminating L2TP connections over IPsec transport mode suffers from 2703 the same challenges. 2705 Appendix D. MUD Extension 2707 The following extension augments the MUD model to include a single 2708 node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the 2709 following sample module that has the following tree structure: 2711 module: ietf-mud-brski-masa 2712 augment /ietf-mud:mud: 2713 +--rw masa-server? inet:uri 2715 The model is defined as follows: 2717 2718 module ietf-mud-brski-masa { 2719 yang-version 1.1; 2720 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 2721 prefix ietf-mud-brski-masa; 2722 import ietf-mud { 2723 prefix ietf-mud; 2724 } 2725 import ietf-inet-types { 2726 prefix inet; 2727 } 2729 organization 2730 "IETF ANIMA (Autonomic Networking Integrated Model and 2731 Approach) Working Group"; 2732 contact 2733 "WG Web: http://tools.ietf.org/wg/anima/ 2734 WG List: anima@ietf.org 2735 "; 2736 description 2737 "BRSKI extension to a MUD file to indicate the 2738 MASA URL."; 2740 revision 2017-10-09 { 2741 description 2742 "Initial revision."; 2743 reference 2744 "RFC XXXX: Manufacturer Usage Description 2745 Specification"; 2746 } 2748 augment "/ietf-mud:mud" { 2749 description 2750 "BRSKI extension to a MUD file to indicate the 2751 MASA URL."; 2752 leaf masa-server { 2753 type inet:uri; 2754 description 2755 "This value is the URI of the MASA server"; 2756 } 2757 } 2758 } 2759 2761 Appendix E. Example Vouchers 2763 Three entities are involved in a voucher: the MASA issues (signs) it, 2764 the registrar's public key is mentioned in the voucher, and the 2765 pledge validates it. In order to provide reproduceable examples the 2766 public and private keys for an example MASA and Registrar are first 2767 listed. 2769 E.1. Keys involved 2771 The Manufacturer has a Certificate Authority that signs the Pledge's 2772 IDevID. In addition the Manufacturer's signing authority (the MASA) 2773 signs the vouchers, and that certificate must distributed to the 2774 devices at manufacturing time so that vouchers can be validated. 2776 E.1.1. MASA key pair for voucher signatures 2778 This private key signs vouchers: 2780 -----BEGIN EC PRIVATE KEY----- 2781 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 2782 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 2783 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 2784 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 2785 -----END EC PRIVATE KEY----- 2787 This public key validates vouchers: 2789 -----BEGIN CERTIFICATE----- 2790 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 2791 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 2792 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 2793 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 2794 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 2795 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 2796 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 2797 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 2798 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 2799 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 2800 -----END CERTIFICATE----- 2802 E.1.2. Manufacturer key pair for IDevID signatures 2804 This private key signs IDevID certificates: 2806 -----BEGIN EC PRIVATE KEY----- 2807 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 2808 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 2809 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 2810 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 2811 -----END EC PRIVATE KEY----- 2813 This public key validates IDevID certificates: 2815 -----BEGIN CERTIFICATE----- 2816 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 2817 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 2818 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 2819 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 2820 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 2821 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 2822 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 2823 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 2824 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 2825 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 2826 -----END CERTIFICATE----- 2828 E.1.3. Registrar key pair 2830 The registrar key (or chain) is the representative of the domain 2831 owner. This key signs Registrar voucher-requests: 2833 -----BEGIN EC PRIVATE KEY----- 2834 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 2835 AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g 2836 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 2837 -----END EC PRIVATE KEY----- 2839 The public key is indicated in a pledge voucher-request to show 2840 proximity. 2842 -----BEGIN CERTIFICATE----- 2843 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC 2844 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n 2845 IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 2846 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw 2847 EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N 2848 w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ 2849 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 2850 /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC 2851 MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR 2852 c3o= 2853 -----END CERTIFICATE----- 2854 The registrar public certificate as decoded by openssl's x509 2855 utility. Note that the registrar certificate is marked with the 2856 cmcRA extension. 2858 Certificate: 2859 Data: 2860 Version: 3 (0x2) 2861 Serial Number: 3 (0x3) 2862 Signature Algorithm: ecdsa-with-SHA384 2863 Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount 2864 ain CA 2865 Validity 2866 Not Before: Sep 5 01:12:45 2017 GMT 2867 Not After : Sep 5 01:12:45 2019 GMT 2868 Subject: DC = ca, DC = sandelman, CN = localhost 2869 Subject Public Key Info: 2870 Public Key Algorithm: id-ecPublicKey 2871 Public-Key: (256 bit) 2872 pub: 2873 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 2874 8:17: 2875 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 2876 3:3e: 2877 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 2878 9:ba: 2879 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 2880 f:96: 2881 e9:9d:e2:bc:b2 2882 ASN1 OID: prime256v1 2883 NIST CURVE: P-256 2884 X509v3 extensions: 2885 X509v3 Basic Constraints: 2886 CA:FALSE 2887 Signature Algorithm: ecdsa-with-SHA384 2888 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 2889 5b: 2890 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 2891 b6: 2892 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 2893 02: 2894 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 2895 c3: 2896 ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: 2897 4b: 2898 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 2900 E.1.4. Pledge key pair 2902 The pledge has an IDevID key pair built in at manufacturing time: 2904 -----BEGIN EC PRIVATE KEY----- 2905 MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49 2906 AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p 2907 r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg== 2908 -----END EC PRIVATE KEY----- 2910 The public key is used by the registrar to find the MASA. The MASA 2911 URL is in an extension described in Section 2.3. RFC-EDITOR: Note 2912 that these certificates are using a Private Enterprise Number for the 2913 not-yet-assigned by IANA MASA URL, and need to be replaced before 2914 AUTH48. 2916 -----BEGIN CERTIFICATE----- 2917 MIICMjCCAbegAwIBAgIBDDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 2918 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 2919 IEhpZ2h3YXkgQ0EwIBcNMTcxMDEyMTM1MjUyWhgPMjk5OTEyMzEwMDAwMDBaMEsx 2920 EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEa 2921 MBgGA1UEAwwRMDAtRDAtRTUtRjItMDAtMDIwWTATBgcqhkjOPQIBBggqhkjOPQMB 2922 BwNCAARJp5i0dU1aUnR2u8wMRwgkNupNbNM7m1n0mj+0KJZjcPIqID+trPjTSobt 2923 uIdpRPfGZ8hU/nIUveqwyoYI8BPbo4GHMIGEMB0GA1UdDgQWBBQdMRZhthFQmzz6 2924 E7YVXzkL7XZDKjAJBgNVHRMEAjAAMCsGA1UdEQQkMCKgIAYJKwYBBAGC7lIBoBMM 2925 ETAwLUQwLUU1LUYyLTAwLTAyMCsGCSsGAQQBgu5SAgQeDBxodHRwczovL2hpZ2h3 2926 YXkuc2FuZGVsbWFuLmNhMAoGCCqGSM49BAMCA2kAMGYCMQDhJ1N+eanW1U/e5qoM 2927 SGvUvWHR7uic8cJbh7vXy580nBs8bpNn60k/+IzvEUetMzICMQCr1uxvdYeKq7mb 2928 RXCR4ZCJsw67fJ7jyXZbCUSir+3wBT2+lWggzPDRgYB5ABb7sAw= 2929 -----END CERTIFICATE----- 2931 The pledge public certificate as decoded by openssl's x509 utility so 2932 that the extensions can be seen. A second custom Extension is 2933 included to provided to contain the EUI48/EUI64 that the pledge will 2934 configure. 2936 Certificate: 2937 Data: 2938 Version: 3 (0x2) 2939 Serial Number: 12 (0xc) 2940 Signature Algorithm: ecdsa-with-SHA256 2941 Issuer: DC = ca, DC = sandelman, CN = Unstrung Highw 2942 ay CA 2943 Validity 2944 Not Before: Oct 12 13:52:52 2017 GMT 2945 Not After : Dec 31 00:00:00 2999 GMT 2946 Subject: DC = ca, DC = sandelman, CN = 00-D0-E5-F2-0 2947 0-02 2948 Subject Public Key Info: 2949 Public Key Algorithm: id-ecPublicKey 2950 Public-Key: (256 bit) 2951 pub: 2952 04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0 2953 c:47: 2954 08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 2955 4:28: 2956 96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 2957 d:b8: 2958 87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b 2959 0:ca: 2960 86:08:f0:13:db 2961 ASN1 OID: prime256v1 2962 NIST CURVE: P-256 2963 X509v3 extensions: 2964 X509v3 Subject Key Identifier: 2965 1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39 2966 :0B:ED:76:43:2A 2967 X509v3 Basic Constraints: 2968 CA:FALSE 2969 X509v3 Subject Alternative Name: 2970 othername: 2971 1.3.6.1.4.1.46930.2: 2972 ..https://highway.sandelman.ca 2973 Signature Algorithm: ecdsa-with-SHA256 2974 30:66:02:31:00:e1:27:53:7e:79:a9:d6:d5:4f:de:e6:aa: 2975 0c: 2976 48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f: 2977 34: 2978 9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32: 2979 02: 2980 31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90: 2981 89: 2982 b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d: 2983 be: 2984 95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c 2986 E.2. Example process 2988 RFC-EDITOR: these examples will need to be replaced with CMS versions 2989 once IANA has assigned the eContentType in [I-D.ietf-anima-voucher]. 2991 E.2.1. Pledge to Registrar 2993 As described in Section 5.2, the pledge will sign a pledge voucher- 2994 request containing the Registrar's public key in the proximity- 2995 registrar-cert field. The base64 has been wrapped at 60 characters 2996 for presentation reasons. 2998 MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC 2999 Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 3000 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 3001 OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw 3002 LTAyIiwibm9uY2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGlt 3003 aXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFL 3004 QmdncWhrak9QUVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH 3005 VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJB 3006 TU1GRlZ1YzNSeWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRB 3007 eE1USTBOVm9YRFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21U 3008 OGl4a0FSa1dBbU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNi 3009 V0Z1TVJJd0VBWURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BR 3010 SUJCZ2dxaGtqT1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3Ra 3011 OTR3YUFJVjBpL29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgv 3012 d2ZBcFI2c3ZsdW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdT 3013 TTQ5QkFNREEya0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FD 3014 NnFqSWVZMmprRHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjll 3015 ZmJUTGJkdERrM3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0 3016 MWx5Rk0rMGZZcFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqG 3017 SM49BAMCME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkW 3018 CXNhbmRlbG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0x 3019 NzEwMTIxMzUyNTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixk 3020 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEw 3021 MC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmn 3022 mLR1TVpSdHa7zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE 3023 98ZnyFT+chS96rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoT 3024 thVfOQvtdkMqMAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGg 3025 EwwRMDAtRDAtRTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8v 3026 aGlnaHdheS5zYW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355 3027 qdbVT97mqgxIa9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIx 3028 AKvW7G91h4qruZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkA 3029 FvuwDDGCAaUwggGhAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 3030 CZImiZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdo 3031 d2F5IENBAgEMMA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkq 3032 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjE3NTQzMFowLwYJKoZI 3033 hvcNAQkEMSIEIP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkG 3034 CSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglg 3035 hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 3036 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEYw 3037 RAIgYUy0NTdP+xTkm/Et69eI++S/2z3dQwPKOwdL0cDCSvACIAh3jJbybMnK 3038 cf7DKKnsn2G/O06HeB/8imMI+hnA7CfN 3040 file: examples/vr_00-D0-E5-F2-00-02.pkcs 3042 The ASN1 decoding of the artifact: 3044 0:d=0 hl=4 l=1820 cons: SEQUENCE 3045 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 3046 Data 3047 15:d=1 hl=4 l=1805 cons: cont [ 0 ] 3048 19:d=2 hl=4 l=1801 cons: SEQUENCE 3049 23:d=3 hl=2 l= 1 prim: INTEGER :01 3050 26:d=3 hl=2 l= 15 cons: SET 3051 28:d=4 hl=2 l= 13 cons: SEQUENCE 3052 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 3053 41:d=5 hl=2 l= 0 prim: NULL 3054 43:d=3 hl=4 l= 782 cons: SEQUENCE 3055 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 3056 58:d=4 hl=4 l= 767 cons: cont [ 0 ] 3057 62:d=5 hl=4 l= 763 prim: OCTET STRING :{"ietf-vouch 3058 er-request:voucher":{"assertion":"proximity","created-on":"2 3059 017-09-01","serial-number":"00-D0-E5-F2-00-02","nonce":"Dss9 3060 9sBr3pNMOACe-LYY7w","proximity-registrar-cert":"MIIBrjCCATOg 3061 AwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAX 3062 BgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5nIEZv 3063 dW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 3064 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFu 3065 MRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC 3066 AAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/p 3067 uhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49 3068 BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNi 3069 fVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR 3070 54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 3071 829:d=3 hl=4 l= 566 cons: cont [ 0 ] 3072 833:d=4 hl=4 l= 562 cons: SEQUENCE 3073 837:d=5 hl=4 l= 439 cons: SEQUENCE 3074 841:d=6 hl=2 l= 3 cons: cont [ 0 ] 3075 843:d=7 hl=2 l= 1 prim: INTEGER :02 3076 846:d=6 hl=2 l= 1 prim: INTEGER :0C 3077 849:d=6 hl=2 l= 10 cons: SEQUENCE 3078 851:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3079 HA256 3080 861:d=6 hl=2 l= 77 cons: SEQUENCE 3081 863:d=7 hl=2 l= 18 cons: SET 3082 865:d=8 hl=2 l= 16 cons: SEQUENCE 3083 867:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3084 ent 3085 879:d=9 hl=2 l= 2 prim: IA5STRING :ca 3086 883:d=7 hl=2 l= 25 cons: SET 3087 885:d=8 hl=2 l= 23 cons: SEQUENCE 3088 887:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3089 ent 3090 899:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3091 910:d=7 hl=2 l= 28 cons: SET 3092 912:d=8 hl=2 l= 26 cons: SEQUENCE 3093 914:d=9 hl=2 l= 3 prim: OBJECT :commonName 3094 919:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 3095 hway CA 3096 940:d=6 hl=2 l= 32 cons: SEQUENCE 3097 942:d=7 hl=2 l= 13 prim: UTCTIME :171012135252 3098 Z 3099 957:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :299912310000 3100 00Z 3101 974:d=6 hl=2 l= 75 cons: SEQUENCE 3102 976:d=7 hl=2 l= 18 cons: SET 3103 978:d=8 hl=2 l= 16 cons: SEQUENCE 3104 980:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3105 ent 3106 992:d=9 hl=2 l= 2 prim: IA5STRING :ca 3107 996:d=7 hl=2 l= 25 cons: SET 3108 998:d=8 hl=2 l= 23 cons: SEQUENCE 3109 1000:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3110 ent 3111 1012:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3112 1023:d=7 hl=2 l= 26 cons: SET 3113 1025:d=8 hl=2 l= 24 cons: SEQUENCE 3114 1027:d=9 hl=2 l= 3 prim: OBJECT :commonName 3115 1032:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2- 3116 00-02 3117 1051:d=6 hl=2 l= 89 cons: SEQUENCE 3118 1053:d=7 hl=2 l= 19 cons: SEQUENCE 3119 1055:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 3120 ey 3121 1064:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 3122 1074:d=7 hl=2 l= 66 prim: BIT STRING 3123 1142:d=6 hl=3 l= 135 cons: cont [ 3 ] 3124 1145:d=7 hl=3 l= 132 cons: SEQUENCE 3125 1148:d=8 hl=2 l= 29 cons: SEQUENCE 3126 1150:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subje 3127 ct Key Identifier 3128 1155:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04 3129 141D311661B611509B3CFA13B6155F390BED76432A 3130 1179:d=8 hl=2 l= 9 cons: SEQUENCE 3131 1181:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 3132 Constraints 3133 1186:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 3134 00 3135 1190:d=8 hl=2 l= 43 cons: SEQUENCE 3136 1192:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subje 3137 ct Alternative Name 3138 1197:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:30 3139 22A02006092B0601040182EE5201A0130C1130302D44302D45352D46322D 3140 30302D3032 3141 1235:d=8 hl=2 l= 43 cons: SEQUENCE 3142 1237:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1. 3143 46930.2 3144 1248:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C 3145 1C68747470733A2F2F686967687761792E73616E64656C6D616E2E6361 3146 1280:d=5 hl=2 l= 10 cons: SEQUENCE 3147 1282:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3148 HA256 3149 1292:d=5 hl=2 l= 105 prim: BIT STRING 3150 1399:d=3 hl=4 l= 421 cons: SET 3151 1403:d=4 hl=4 l= 417 cons: SEQUENCE 3152 1407:d=5 hl=2 l= 1 prim: INTEGER :01 3153 1410:d=5 hl=2 l= 82 cons: SEQUENCE 3154 1412:d=6 hl=2 l= 77 cons: SEQUENCE 3155 1414:d=7 hl=2 l= 18 cons: SET 3156 1416:d=8 hl=2 l= 16 cons: SEQUENCE 3157 1418:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3158 ent 3159 1430:d=9 hl=2 l= 2 prim: IA5STRING :ca 3160 1434:d=7 hl=2 l= 25 cons: SET 3161 1436:d=8 hl=2 l= 23 cons: SEQUENCE 3162 1438:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3163 ent 3164 1450:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3165 1461:d=7 hl=2 l= 28 cons: SET 3166 1463:d=8 hl=2 l= 26 cons: SEQUENCE 3167 1465:d=9 hl=2 l= 3 prim: OBJECT :commonName 3168 1470:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 3169 hway CA 3170 1491:d=6 hl=2 l= 1 prim: INTEGER :0C 3171 1494:d=5 hl=2 l= 13 cons: SEQUENCE 3172 1496:d=6 hl=2 l= 9 prim: OBJECT :sha256 3173 1507:d=6 hl=2 l= 0 prim: NULL 3174 1509:d=5 hl=3 l= 228 cons: cont [ 0 ] 3175 1512:d=6 hl=2 l= 24 cons: SEQUENCE 3176 1514:d=7 hl=2 l= 9 prim: OBJECT :contentType 3177 1525:d=7 hl=2 l= 11 cons: SET 3178 1527:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 3179 1538:d=6 hl=2 l= 28 cons: SEQUENCE 3180 1540:d=7 hl=2 l= 9 prim: OBJECT :signingTime 3181 1551:d=7 hl=2 l= 15 cons: SET 3182 1553:d=8 hl=2 l= 13 prim: UTCTIME :171012175430 3183 Z 3184 1568:d=6 hl=2 l= 47 cons: SEQUENCE 3185 1570:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 3186 t 3187 1581:d=7 hl=2 l= 34 cons: SET 3188 1583:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:FE 3189 7D72E29500F90A38E95021A215FD6D40B1629B99598177DC054AE0F9C8B6 3190 9F 3191 1617:d=6 hl=2 l= 121 cons: SEQUENCE 3192 1619:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 3193 ilities 3194 1630:d=7 hl=2 l= 108 cons: SET 3195 1632:d=8 hl=2 l= 106 cons: SEQUENCE 3196 1634:d=9 hl=2 l= 11 cons: SEQUENCE 3197 1636:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 3198 1647:d=9 hl=2 l= 11 cons: SEQUENCE 3199 1649:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 3200 1660:d=9 hl=2 l= 11 cons: SEQUENCE 3201 1662:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 3202 1673:d=9 hl=2 l= 10 cons: SEQUENCE 3203 1675:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 3204 1685:d=9 hl=2 l= 14 cons: SEQUENCE 3205 1687:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3206 1697:d=10 hl=2 l= 2 prim: INTEGER :80 3207 1701:d=9 hl=2 l= 13 cons: SEQUENCE 3208 1703:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3209 1713:d=10 hl=2 l= 1 prim: INTEGER :40 3210 1716:d=9 hl=2 l= 7 cons: SEQUENCE 3211 1718:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 3212 1725:d=9 hl=2 l= 13 cons: SEQUENCE 3213 1727:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3214 1737:d=10 hl=2 l= 1 prim: INTEGER :28 3215 1740:d=5 hl=2 l= 10 cons: SEQUENCE 3216 1742:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3217 HA256 3218 1752:d=5 hl=2 l= 70 prim: OCTET STRING [HEX DUMP]:30 3219 440220614CB435374FFB14E49BF12DEBD788FBE4BFDB3DDD4303CA3B074B 3220 D1C0C24AF0022008778C96F26CC9CA71FEC328A9EC9F61BF3B4E87781FFC 3221 8A6308FA19C0EC27CD 3223 The JSON contained in the voucher request: 3225 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr 3226 eated-on":"2017-09-01","serial-number":"00-D0-E5-F2-00-02"," 3227 nonce":"Dss99sBr3pNMOACe-LYY7w","proximity-registrar-cert":" 3228 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQB 3229 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVu 3230 c3RydW5nIEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAx 3231 MTI0NVowQzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJ 3232 c2FuZGVsbWFuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggq 3233 hkjOPQMBBwNCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6 3234 MwF5z+Dpb8/puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAA 3235 MAoGCCqGSM49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY 3236 2jkDx062nuNifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77 3237 XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 3239 E.2.2. Registrar to MASA 3241 As described in Section 5.4 the Registrar will sign a registrar 3242 voucher-request, and will include pledge's voucher request in the 3243 prior-signed-voucher-request. 3245 MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC 3246 Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 3247 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 3248 OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi 3249 SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu 3250 ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI 3251 RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT 3252 SWIzRFFFSEFhQ0NBdjhFZ2dMN2V5SnBaWFJtTFhadmRXTm9aWEl0Y21WeGRX 3253 VnpkRHAyYjNWamFHVnlJanA3SW1GemMyVnlkR2x2YmlJNkluQnliM2hwYlds 3254 MGVTSXNJbU55WldGMFpXUXRiMjRpT2lJeU1ERTNMVEE1TFRBeElpd2ljMlZ5 3255 YVdGc0xXNTFiV0psY2lJNklqQXdMVVF3TFVVMUxVWXlMVEF3TFRBeUlpd2li 3256 bTl1WTJVaU9pSkVjM001T1hOQ2NqTndUazFQUVVObExVeFpXVGQzSWl3aWNI 3257 SnZlR2x0YVhSNUxYSmxaMmx6ZEhKaGNpMWpaWEowSWpvaVRVbEpRbkpxUTBO 3258 QlZFOW5RWGRKUWtGblNVSkJla0ZMUW1kbmNXaHJhazlRVVZGRVFYcENUMDFT 3259 U1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlExa3lSWGhIVkVGWVFtZHZT 3260 bXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRGbFhOSGhJVkVGaVFt 3261 ZE9Wa0pCVFUxR1JsWjFZek5TZVdSWE5XNUpSVnAyWkZjMU1GbFhiSFZKUlU1 3262 Q1RVSTBXRVJVUlROTlJHdDNUbFJCZUUxVVNUQk9WbTlZUkZSRk5VMUVhM2RP 3263 VkVGNFRWUkpNRTVXYjNkUmVrVlRUVUpCUjBObmJWTktiMjFVT0dsNGEwRlNh 3264 MWRCYlU1b1RWSnJkMFozV1V0RFdrbHRhVnBRZVV4SFVVSkhVbGxLWXpKR2RW 3265 cEhWbk5pVjBaMVRWSkpkMFZCV1VSV1VWRkVSRUZzYzJJeVRtaGlSMmgyWXpO 3266 UmQxZFVRVlJDWjJOeGFHdHFUMUJSU1VKQ1oyZHhhR3RxVDFCUlRVSkNkMDVE 3267 UVVGUk1WcEJOMDUzTUhoVFRTOVJNblV4T1RSR2VsRk5hM1JhT1RSM1lVRkpW 3268 akJwTDI5V1ZGQm5UMG80ZWxjMlRYZEdOWG9yUkhCaU9DOXdkV2hQWWtwTldq 3269 QlZOa2d2ZDJaQmNGSTJjM1pzZFcxa05ISjVlVzkzTUhkRGVrRktRbWRPVmto 3270 U1RVVkJha0ZCVFVGdlIwTkRjVWRUVFRRNVFrRk5SRUV5YTBGTlIxbERUVkZE 3271 TXk5cFZGRktNMlYyV1ZsaloySllhR0p0ZW5Kd05qUjBNMUZETm5GcVNXVlpN 3272 bXByUkhnd05qSnVkVTVwWmxaTGRIbGhZWEpoTTBZek1FRkphMHRUUlVOTlVV 3273 UnBNamxsWm1KVVRHSmtkRVJyTTNSbFkxa3Zja1EzVmpjM1dHRktObTVaUTIx 3274 a1JFTlNOVFJVY2xOR1RreG5lSFowTVd4NVJrMHJNR1paY0ZsU1l6TnZQU0o5 3275 ZmFDQ0FqWXdnZ0l5TUlJQnQ2QURBZ0VDQWdFTU1Bb0dDQ3FHU000OUJBTUNN 3276 RTB4RWpBUUJnb0praWFKay9Jc1pBRVpGZ0pqWVRFWk1CY0dDZ21TSm9tVDhp 3277 eGtBUmtXQ1hOaGJtUmxiRzFoYmpFY01Cb0dBMVVFQXd3VFZXNXpkSEoxYm1j 3278 Z1NHbG5hSGRoZVNCRFFUQWdGdzB4TnpFd01USXhNelV5TlRKYUdBOHlPVGs1 3279 TVRJek1UQXdNREF3TUZvd1N6RVNNQkFHQ2dtU0pvbVQ4aXhrQVJrV0FtTmhN 3280 Umt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdWc2JXRnVNUm93R0FZRFZR 3281 UUREQkV3TUMxRU1DMUZOUzFHTWkwd01DMHdNakJaTUJNR0J5cUdTTTQ5QWdF 3282 R0NDcUdTTTQ5QXdFSEEwSUFCRW1ubUxSMVRWcFNkSGE3ekF4SENDUTI2azFz 3283 MHp1YldmU2FQN1FvbG1Odzhpb2dQNjJzK05OS2h1MjRoMmxFOThabnlGVCtj 3284 aFM5NnJES2hnandFOXVqZ1ljd2dZUXdIUVlEVlIwT0JCWUVGQjB4Rm1HMkVW 3285 Q2JQUG9UdGhWZk9RdnRka01xTUFrR0ExVWRFd1FDTUFBd0t3WURWUjBSQkNR 3286 d0lxQWdCZ2tyQmdFRUFZTHVVZ0dnRXd3Uk1EQXRSREF0UlRVdFJqSXRNREF0 3287 TURJd0t3WUpLd1lCQkFHQzdsSUNCQjRNSEdoMGRIQnpPaTh2YUdsbmFIZGhl 3288 UzV6WVc1a1pXeHRZVzR1WTJFd0NnWUlLb1pJemowRUF3SURhUUF3WmdJeEFP 3289 RW5VMzU1cWRiVlQ5N21xZ3hJYTlTOVlkSHU2Snp4d2x1SHU5ZkxuelNjR3p4 3290 dWsyZnJTVC80ak84UlI2MHpNZ0l4QUt2VzdHOTFoNHFydVp0RmNKSGhrSW16 3291 RHJ0OG51UEpkbHNKUktLdjdmQUZQYjZWYUNETThOR0JnSGtBRnZ1d0RER0NB 3292 YVl3Z2dHaUFnRUJNRkl3VFRFU01CQUdDZ21TSm9tVDhpeGtBUmtXQW1OaE1S 3293 a3dGd1lLQ1pJbWlaUHlMR1FCR1JZSmMyRnVaR1ZzYldGdU1Sd3dHZ1lEVlFR 3294 RERCTlZibk4wY25WdVp5QklhV2RvZDJGNUlFTkJBZ0VNTUEwR0NXQ0dTQUZs 3295 QXdRQ0FRVUFvSUhrTUJnR0NTcUdTSWIzRFFFSkF6RUxCZ2txaGtpRzl3MEJC 3296 d0V3SEFZSktvWklodmNOQVFrRk1ROFhEVEUzTVRBeE1qRXpOVGd5TTFvd0x3 3297 WUpLb1pJaHZjTkFRa0VNU0lFSVA1OWN1S1ZBUGtLT09sUUlhSVYvVzFBc1dL 3298 Ym1WbUJkOXdGU3VENXlMYWZNSGtHQ1NxR1NJYjNEUUVKRHpGc01Hb3dDd1lK 3299 WUlaSUFXVURCQUVxTUFzR0NXQ0dTQUZsQXdRQkZqQUxCZ2xnaGtnQlpRTUVB 3300 UUl3Q2dZSUtvWklodmNOQXdjd0RnWUlLb1pJaHZjTkF3SUNBZ0NBTUEwR0ND 3301 cUdTSWIzRFFNQ0FnRkFNQWNHQlNzT0F3SUhNQTBHQ0NxR1NJYjNEUU1DQWdF 3302 b01Bb0dDQ3FHU000OUJBTUNCRWN3UlFJZ0VNZzFkSkw3RmNkdHJWRHg4cUNh 3303 em9lOSsyMk56NFp3UkI5Z0FUR0w3TU1DSVFEanNzVWxaekpxcDIva0NkNFdo 3304 eFVoc2FDcFRGd1Bybk5ldzV3Q2tZVUY4UT09In19oIIBsjCCAa4wggEzoAMC 3305 AQICAQMwCgYIKoZIzj0EAwMwTjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 3306 CZImiZPyLGQBGRYJc2FuZGVsbWFuMR0wGwYDVQQDDBRVbnN0cnVuZyBGb3Vu 3307 dGFpbiBDQTAeFw0xNzA5MDUwMTEyNDVaFw0xOTA5MDUwMTEyNDVaMEMxEjAQ 3308 BgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjES 3309 MBAGA1UEAwwJbG9jYWxob3N0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 3310 NWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g6W/P6boT 3311 myTGdFOh/8HwKUerL5bpneK8sqMNMAswCQYDVR0TBAIwADAKBggqhkjOPQQD 3312 AwNpADBmAjEAt/4k0Cd3r2GHIG14W5s66euLd0AuqoyHmNo5A8dOtp7jYn1S 3313 rcmmq2txd9ACJCkhAjEA4tvXn20y23bQ5N7XnGP6w+1e+12iep2ApnQwkeeE 3314 60hTS4Mb7dZchTPtH2KWEXN6MYIBpzCCAaMCAQEwUzBOMRIwEAYKCZImiZPy 3315 LGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMM 3316 FFVuc3RydW5nIEZvdW50YWluIENBAgEDMA0GCWCGSAFlAwQCAQUAoIHkMBgG 3317 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAy 3318 NjAxMzYxOFowLwYJKoZIhvcNAQkEMSIEIEQBM73PZzPo7tE9Mj8gQvaaYeMQ 3319 OsxlACaW/HenAqNwMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG 3320 CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN 3321 AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo 3322 MAoGCCqGSM49BAMCBEcwRQIgDdp5uPUlMKp7GFQAD7ypAgqFv8q+KkJt6c3O 3323 7iVpVI8CIQCD1u8BkxipvigwvIDmWfjlYdJxcvozNjffq5j3UHg7Rg== 3325 file: examples/parboiled_vr_00-D0-E5-F2-00-02.pkcs 3327 The ASN1 decoding of the artifact: 3329 0:d=0 hl=4 l=3546 cons: SEQUENCE 3330 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 3331 Data 3332 15:d=1 hl=4 l=3531 cons: cont [ 0 ] 3333 19:d=2 hl=4 l=3527 cons: SEQUENCE 3334 23:d=3 hl=2 l= 1 prim: INTEGER :01 3335 26:d=3 hl=2 l= 15 cons: SET 3336 28:d=4 hl=2 l= 13 cons: SEQUENCE 3337 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 3338 41:d=5 hl=2 l= 0 prim: NULL 3339 43:d=3 hl=4 l=2638 cons: SEQUENCE 3340 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 3341 58:d=4 hl=4 l=2623 cons: cont [ 0 ] 3342 62:d=5 hl=4 l=2619 prim: OCTET STRING :{"ietf-vouch 3343 er-request:voucher":{"assertion":"proximity","created-on":"2 3344 017-09-15T00:00:00.000Z","serial-number":"JADA123456789","no 3345 nce":"abcd1234","prior-signed-voucher-request":"MIIHHQYJKoZI 3346 hvcNAQcCoIIHDjCCBwoCAQExDzANBglghkgBZQMEAgEFADCCAw4GCSqGSIb3 3347 DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7 3348 ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24iOiIyMDE3LTA5 3349 LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9u 3350 Y2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGltaXR5LXJlZ2lz 3351 dHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFLQmdncWhrak9Q 3352 UVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtp 3353 YUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJBTU1GRlZ1YzNS 3354 eWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRBeE1USTBOVm9Y 3355 RFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21UOGl4a0FSa1dB 3356 bU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNiV0Z1TVJJd0VB 3357 WURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtq 3358 T1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3RaOTR3YUFJVjBp 3359 L29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgvd2ZBcFI2c3Zs 3360 dW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdTTTQ5QkFNREEy 3361 a0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FDNnFqSWVZMmpr 3362 RHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjllZmJUTGJkdERr 3363 M3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0MWx5Rk0rMGZZ 3364 cFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqGSM49BAMCME0x 3365 EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1h 3366 bjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0xNzEwMTIxMzUy 3367 NTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixkARkWAmNhMRkw 3368 FwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEwMC1EMC1FNS1G 3369 Mi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmnmLR1TVpSdHa7 3370 zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE98ZnyFT+chS9 3371 6rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoTthVfOQvtdkMq 3372 MAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGgEwwRMDAtRDAt 3373 RTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8vaGlnaHdheS5z 3374 YW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355qdbVT97mqgxI 3375 a9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIxAKvW7G91h4qr 3376 uZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkAFvuwDDGCAaYw 3377 ggGiAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 3378 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBAgEM 3379 MA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw 3380 HAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjEzNTgyM1owLwYJKoZIhvcNAQkEMSIE 3381 IP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkGCSqGSIb3DQEJ 3382 DzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw 3383 CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG 3384 BSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEcwRQIgEMg1dJL7 3385 FcdtrVDx8qCazoe9+22Nz4ZwRB9gATGL7MMCIQDjssUlZzJqp2/kCd4WhxUh 3386 saCpTFwPrnNew5wCkYUF8Q=="}} 3387 2685:d=3 hl=4 l= 434 cons: cont [ 0 ] 3388 2689:d=4 hl=4 l= 430 cons: SEQUENCE 3389 2693:d=5 hl=4 l= 307 cons: SEQUENCE 3390 2697:d=6 hl=2 l= 3 cons: cont [ 0 ] 3391 2699:d=7 hl=2 l= 1 prim: INTEGER :02 3392 2702:d=6 hl=2 l= 1 prim: INTEGER :03 3393 2705:d=6 hl=2 l= 10 cons: SEQUENCE 3394 2707:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3395 HA384 3396 2717:d=6 hl=2 l= 78 cons: SEQUENCE 3397 2719:d=7 hl=2 l= 18 cons: SET 3398 2721:d=8 hl=2 l= 16 cons: SEQUENCE 3399 2723:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3400 ent 3401 2735:d=9 hl=2 l= 2 prim: IA5STRING :ca 3402 2739:d=7 hl=2 l= 25 cons: SET 3403 2741:d=8 hl=2 l= 23 cons: SEQUENCE 3404 2743:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3405 ent 3406 2755:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3407 2766:d=7 hl=2 l= 29 cons: SET 3408 2768:d=8 hl=2 l= 27 cons: SEQUENCE 3409 2770:d=9 hl=2 l= 3 prim: OBJECT :commonName 3410 2775:d=9 hl=2 l= 20 prim: UTF8STRING :Unstrung Fou 3411 ntain CA 3412 2797:d=6 hl=2 l= 30 cons: SEQUENCE 3413 2799:d=7 hl=2 l= 13 prim: UTCTIME :170905011245 3414 Z 3415 2814:d=7 hl=2 l= 13 prim: UTCTIME :190905011245 3416 Z 3417 2829:d=6 hl=2 l= 67 cons: SEQUENCE 3418 2831:d=7 hl=2 l= 18 cons: SET 3419 2833:d=8 hl=2 l= 16 cons: SEQUENCE 3420 2835:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3421 ent 3422 2847:d=9 hl=2 l= 2 prim: IA5STRING :ca 3423 2851:d=7 hl=2 l= 25 cons: SET 3424 2853:d=8 hl=2 l= 23 cons: SEQUENCE 3425 2855:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3426 ent 3427 2867:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3428 2878:d=7 hl=2 l= 18 cons: SET 3429 2880:d=8 hl=2 l= 16 cons: SEQUENCE 3430 2882:d=9 hl=2 l= 3 prim: OBJECT :commonName 3431 2887:d=9 hl=2 l= 9 prim: UTF8STRING :localhost 3432 2898:d=6 hl=2 l= 89 cons: SEQUENCE 3433 2900:d=7 hl=2 l= 19 cons: SEQUENCE 3434 2902:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 3435 ey 3436 2911:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 3437 2921:d=7 hl=2 l= 66 prim: BIT STRING 3438 2989:d=6 hl=2 l= 13 cons: cont [ 3 ] 3439 2991:d=7 hl=2 l= 11 cons: SEQUENCE 3440 2993:d=8 hl=2 l= 9 cons: SEQUENCE 3441 2995:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 3442 Constraints 3443 3000:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 3444 00 3445 3004:d=5 hl=2 l= 10 cons: SEQUENCE 3446 3006:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3447 HA384 3448 3016:d=5 hl=2 l= 105 prim: BIT STRING 3449 3123:d=3 hl=4 l= 423 cons: SET 3450 3127:d=4 hl=4 l= 419 cons: SEQUENCE 3451 3131:d=5 hl=2 l= 1 prim: INTEGER :01 3452 3134:d=5 hl=2 l= 83 cons: SEQUENCE 3453 3136:d=6 hl=2 l= 78 cons: SEQUENCE 3454 3138:d=7 hl=2 l= 18 cons: SET 3455 3140:d=8 hl=2 l= 16 cons: SEQUENCE 3456 3142:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3457 ent 3458 3154:d=9 hl=2 l= 2 prim: IA5STRING :ca 3459 3158:d=7 hl=2 l= 25 cons: SET 3460 3160:d=8 hl=2 l= 23 cons: SEQUENCE 3461 3162:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3462 ent 3463 3174:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3464 3185:d=7 hl=2 l= 29 cons: SET 3465 3187:d=8 hl=2 l= 27 cons: SEQUENCE 3466 3189:d=9 hl=2 l= 3 prim: OBJECT :commonName 3467 3194:d=9 hl=2 l= 20 prim: UTF8STRING :Unstrung Fou 3468 ntain CA 3469 3216:d=6 hl=2 l= 1 prim: INTEGER :03 3470 3219:d=5 hl=2 l= 13 cons: SEQUENCE 3471 3221:d=6 hl=2 l= 9 prim: OBJECT :sha256 3472 3232:d=6 hl=2 l= 0 prim: NULL 3473 3234:d=5 hl=3 l= 228 cons: cont [ 0 ] 3474 3237:d=6 hl=2 l= 24 cons: SEQUENCE 3475 3239:d=7 hl=2 l= 9 prim: OBJECT :contentType 3476 3250:d=7 hl=2 l= 11 cons: SET 3477 3252:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 3478 3263:d=6 hl=2 l= 28 cons: SEQUENCE 3479 3265:d=7 hl=2 l= 9 prim: OBJECT :signingTime 3480 3276:d=7 hl=2 l= 15 cons: SET 3481 3278:d=8 hl=2 l= 13 prim: UTCTIME :171026013618 3482 Z 3483 3293:d=6 hl=2 l= 47 cons: SEQUENCE 3484 3295:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 3485 t 3486 3306:d=7 hl=2 l= 34 cons: SET 3487 3308:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:44 3488 0133BDCF6733E8EED13D323F2042F69A61E3103ACC65002696FC77A702A3 3489 70 3490 3342:d=6 hl=2 l= 121 cons: SEQUENCE 3491 3344:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 3492 ilities 3493 3355:d=7 hl=2 l= 108 cons: SET 3494 3357:d=8 hl=2 l= 106 cons: SEQUENCE 3495 3359:d=9 hl=2 l= 11 cons: SEQUENCE 3496 3361:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 3497 3372:d=9 hl=2 l= 11 cons: SEQUENCE 3498 3374:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 3499 3385:d=9 hl=2 l= 11 cons: SEQUENCE 3500 3387:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 3501 3398:d=9 hl=2 l= 10 cons: SEQUENCE 3502 3400:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 3503 3410:d=9 hl=2 l= 14 cons: SEQUENCE 3504 3412:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3505 3422:d=10 hl=2 l= 2 prim: INTEGER :80 3506 3426:d=9 hl=2 l= 13 cons: SEQUENCE 3507 3428:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3508 3438:d=10 hl=2 l= 1 prim: INTEGER :40 3509 3441:d=9 hl=2 l= 7 cons: SEQUENCE 3510 3443:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 3511 3450:d=9 hl=2 l= 13 cons: SEQUENCE 3512 3452:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3513 3462:d=10 hl=2 l= 1 prim: INTEGER :28 3514 3465:d=5 hl=2 l= 10 cons: SEQUENCE 3515 3467:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3516 HA256 3517 3477:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30 3518 4502200DDA79B8F52530AA7B1854000FBCA9020A85BFCABE2A426DE9CDCE 3519 EE2569548F02210083D6EF019318A9BE2830BC80E659F8E561D27172FA33 3520 3637DFAB98F750783B46 3522 E.2.3. MASA to Registrar 3524 The MASA will return a voucher to the Registrar, to be relayed to the 3525 pledge. 3527 MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC 3528 AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6 3529 eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x 3530 MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt 3531 RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci 3532 LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6 3533 QUtCZ2dxaGtqT1BRUURBekJPTVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJF 3534 eEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eEhUQWJCZ05W 3535 QkFNTUZGVnVjM1J5ZFc1bklFWnZkVzUwWVdsdUlFTkJNQjRYRFRFM01Ea3dO 3536 VEF4TVRJME5Wb1hEVEU1TURrd05UQXhNVEkwTlZvd1F6RVNNQkFHQ2dtU0pv 3537 bVQ4aXhrQVJrV0FtTmhNUmt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdW 3538 c2JXRnVNUkl3RUFZRFZRUUREQWxzYjJOaGJHaHZjM1F3V1RBVEJnY3Foa2pP 3539 UFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVExWkE3TncweFNNL1EydTE5NEZ6UU1r 3540 dFo5NHdhQUlWMGkvb1ZUUGdPSjh6VzZNd0Y1eitEcGI4L3B1aE9iSk1aMFU2 3541 SC93ZkFwUjZzdmx1bWQ0cnl5b3cwd0N6QUpCZ05WSFJNRUFqQUFNQW9HQ0Nx 3542 R1NNNDlCQU1EQTJrQU1HWUNNUUMzL2lUUUozZXZZWWNnYlhoYm16cnA2NHQz 3543 UUM2cWpJZVkyamtEeDA2Mm51TmlmVkt0eWFhcmEzRjMwQUlrS1NFQ01RRGky 3544 OWVmYlRMYmR0RGszdGVjWS9yRDdWNzdYYUo2bllDbWREQ1I1NFRyU0ZOTGd4 3545 dnQxbHlGTSswZllwWVJjM289In19oIIB0zCCAc8wggFWoAMCAQICAQEwCgYI 3546 KoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 3547 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBMB4X 3548 DTE3MDMyNjE2MTk0MFoXDTE5MDMyNjE2MTk0MFowRzESMBAGCgmSJomT8ixk 3549 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRYwFAYDVQQDDA1V 3550 bnN0cnVuZyBNQVNBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2QB90W9hbyCT 3551 p7bPr17llt+aH8jWwh84wMzotpFmRRNQcrqyiJjXDTBRoqxp0VyFxqlgn8OS 3552 AoCfArjN71ebcvW3+ylJTpHo8077/uT1fvnpZD/R0PN76kwMLNlsFk8SoxAw 3553 DjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAMCA2cAMGQCMBm9KMjNHaD+rd/y 3554 0jy+Tg7mrRMDGIe1hjviGExwvCuxMhwTpgmEXik9vhoVfwi1swIwTculDCU7 3555 dbbMSbCanTD1CBY/uMGYNQDiG/yaAOjO6996cC0E6x0cRM1TBn1jpGFMMYIB 3556 xjCCAcICAQEwUjBNMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/Is 3557 ZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EC 3558 AQEwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH 3559 ATAcBgkqhkiG9w0BCQUxDxcNMTcxMDEyMTc1NDMxWjAvBgkqhkiG9w0BCQQx 3560 IgQgQXnG628cIW8MoYfB1ljDDlLlJQlxED2tnjcvkLEfix0weQYJKoZIhvcN 3561 AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB 3562 AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw 3563 BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIzj0EAwIEZzBlAjEAhzid 3564 /AkNjttpSP1rflNppdHsi324Z2+TXJxueewnJ8z/2NXb+Tf3DsThv7du00Oz 3565 AjBjyOnmkkSKHsPR2JluA5c6wovuPEnNKP32daGGeFKGEHMkTInbrqipC881 3566 /5K9Q+k= 3568 file: examples/voucher_00-D0-E5-F2-00-02.pkcs 3570 The ASN1 decoding of the artifact: 3572 0:d=0 hl=4 l=1756 cons: SEQUENCE 3573 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signed 3574 Data 3575 15:d=1 hl=4 l=1741 cons: cont [ 0 ] 3576 19:d=2 hl=4 l=1737 cons: SEQUENCE 3577 23:d=3 hl=2 l= 1 prim: INTEGER :01 3578 26:d=3 hl=2 l= 15 cons: SET 3579 28:d=4 hl=2 l= 13 cons: SEQUENCE 3580 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 3581 41:d=5 hl=2 l= 0 prim: NULL 3582 43:d=3 hl=4 l= 784 cons: SEQUENCE 3583 47:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 3584 58:d=4 hl=4 l= 769 cons: cont [ 0 ] 3585 62:d=5 hl=4 l= 765 prim: OCTET STRING :{"ietf-vouch 3586 er:voucher":{"assertion":"logged","created-on":"2017-10-12T1 3587 3:54:31.439-04:00","serial-number":"00-D0-E5-F2-00-02","nonc 3588 e":"Dss99sBr3pNMOACe-LYY7w","pinned-domain-cert":"MIIBrjCCAT 3589 OgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYCY2ExGT 3590 AXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5nIE 3591 ZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQz 3592 ESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbW 3593 FuMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBw 3594 NCAAQ1ZA7Nw0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8 3595 /puhObJMZ0U6H/wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM 3596 49BAMDA2kAMGYCMQC3/iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nu 3597 NifVKtyaara3F30AIkKSECMQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdD 3598 CR54TrSFNLgxvt1lyFM+0fYpYRc3o="}} 3599 831:d=3 hl=4 l= 467 cons: cont [ 0 ] 3600 835:d=4 hl=4 l= 463 cons: SEQUENCE 3601 839:d=5 hl=4 l= 342 cons: SEQUENCE 3602 843:d=6 hl=2 l= 3 cons: cont [ 0 ] 3603 845:d=7 hl=2 l= 1 prim: INTEGER :02 3604 848:d=6 hl=2 l= 1 prim: INTEGER :01 3605 851:d=6 hl=2 l= 10 cons: SEQUENCE 3606 853:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3607 HA256 3608 863:d=6 hl=2 l= 77 cons: SEQUENCE 3609 865:d=7 hl=2 l= 18 cons: SET 3610 867:d=8 hl=2 l= 16 cons: SEQUENCE 3611 869:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3612 ent 3613 881:d=9 hl=2 l= 2 prim: IA5STRING :ca 3614 885:d=7 hl=2 l= 25 cons: SET 3615 887:d=8 hl=2 l= 23 cons: SEQUENCE 3616 889:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3617 ent 3618 901:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3619 912:d=7 hl=2 l= 28 cons: SET 3620 914:d=8 hl=2 l= 26 cons: SEQUENCE 3621 916:d=9 hl=2 l= 3 prim: OBJECT :commonName 3622 921:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 3624 hway CA 3625 942:d=6 hl=2 l= 30 cons: SEQUENCE 3626 944:d=7 hl=2 l= 13 prim: UTCTIME :170326161940 3627 Z 3628 959:d=7 hl=2 l= 13 prim: UTCTIME :190326161940 3629 Z 3630 974:d=6 hl=2 l= 71 cons: SEQUENCE 3631 976:d=7 hl=2 l= 18 cons: SET 3632 978:d=8 hl=2 l= 16 cons: SEQUENCE 3633 980:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3634 ent 3635 992:d=9 hl=2 l= 2 prim: IA5STRING :ca 3636 996:d=7 hl=2 l= 25 cons: SET 3637 998:d=8 hl=2 l= 23 cons: SEQUENCE 3638 1000:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3639 ent 3640 1012:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3641 1023:d=7 hl=2 l= 22 cons: SET 3642 1025:d=8 hl=2 l= 20 cons: SEQUENCE 3643 1027:d=9 hl=2 l= 3 prim: OBJECT :commonName 3644 1032:d=9 hl=2 l= 13 prim: UTF8STRING :Unstrung MAS 3645 A 3646 1047:d=6 hl=2 l= 118 cons: SEQUENCE 3647 1049:d=7 hl=2 l= 16 cons: SEQUENCE 3648 1051:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicK 3649 ey 3650 1060:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 3651 1067:d=7 hl=2 l= 98 prim: BIT STRING 3652 1167:d=6 hl=2 l= 16 cons: cont [ 3 ] 3653 1169:d=7 hl=2 l= 14 cons: SEQUENCE 3654 1171:d=8 hl=2 l= 12 cons: SEQUENCE 3655 1173:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic 3656 Constraints 3657 1178:d=9 hl=2 l= 1 prim: BOOLEAN :255 3658 1181:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:30 3659 00 3660 1185:d=5 hl=2 l= 10 cons: SEQUENCE 3661 1187:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3662 HA256 3663 1197:d=5 hl=2 l= 103 prim: BIT STRING 3664 1302:d=3 hl=4 l= 454 cons: SET 3665 1306:d=4 hl=4 l= 450 cons: SEQUENCE 3666 1310:d=5 hl=2 l= 1 prim: INTEGER :01 3667 1313:d=5 hl=2 l= 82 cons: SEQUENCE 3668 1315:d=6 hl=2 l= 77 cons: SEQUENCE 3669 1317:d=7 hl=2 l= 18 cons: SET 3670 1319:d=8 hl=2 l= 16 cons: SEQUENCE 3671 1321:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3673 ent 3674 1333:d=9 hl=2 l= 2 prim: IA5STRING :ca 3675 1337:d=7 hl=2 l= 25 cons: SET 3676 1339:d=8 hl=2 l= 23 cons: SEQUENCE 3677 1341:d=9 hl=2 l= 10 prim: OBJECT :domainCompon 3678 ent 3679 1353:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3680 1364:d=7 hl=2 l= 28 cons: SET 3681 1366:d=8 hl=2 l= 26 cons: SEQUENCE 3682 1368:d=9 hl=2 l= 3 prim: OBJECT :commonName 3683 1373:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Hig 3684 hway CA 3685 1394:d=6 hl=2 l= 1 prim: INTEGER :01 3686 1397:d=5 hl=2 l= 13 cons: SEQUENCE 3687 1399:d=6 hl=2 l= 9 prim: OBJECT :sha256 3688 1410:d=6 hl=2 l= 0 prim: NULL 3689 1412:d=5 hl=3 l= 228 cons: cont [ 0 ] 3690 1415:d=6 hl=2 l= 24 cons: SEQUENCE 3691 1417:d=7 hl=2 l= 9 prim: OBJECT :contentType 3692 1428:d=7 hl=2 l= 11 cons: SET 3693 1430:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 3694 1441:d=6 hl=2 l= 28 cons: SEQUENCE 3695 1443:d=7 hl=2 l= 9 prim: OBJECT :signingTime 3696 1454:d=7 hl=2 l= 15 cons: SET 3697 1456:d=8 hl=2 l= 13 prim: UTCTIME :171012175431 3698 Z 3699 1471:d=6 hl=2 l= 47 cons: SEQUENCE 3700 1473:d=7 hl=2 l= 9 prim: OBJECT :messageDiges 3701 t 3702 1484:d=7 hl=2 l= 34 cons: SET 3703 1486:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:41 3704 79C6EB6F1C216F0CA187C1D658C30E52E5250971103DAD9E372F90B11F8B 3705 1D 3706 1520:d=6 hl=2 l= 121 cons: SEQUENCE 3707 1522:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capab 3708 ilities 3709 1533:d=7 hl=2 l= 108 cons: SET 3710 1535:d=8 hl=2 l= 106 cons: SEQUENCE 3711 1537:d=9 hl=2 l= 11 cons: SEQUENCE 3712 1539:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc 3713 1550:d=9 hl=2 l= 11 cons: SEQUENCE 3714 1552:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc 3715 1563:d=9 hl=2 l= 11 cons: SEQUENCE 3716 1565:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc 3717 1576:d=9 hl=2 l= 10 cons: SEQUENCE 3718 1578:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 3719 1588:d=9 hl=2 l= 14 cons: SEQUENCE 3720 1590:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3721 1600:d=10 hl=2 l= 2 prim: INTEGER :80 3722 1604:d=9 hl=2 l= 13 cons: SEQUENCE 3723 1606:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3724 1616:d=10 hl=2 l= 1 prim: INTEGER :40 3725 1619:d=9 hl=2 l= 7 cons: SEQUENCE 3726 1621:d=10 hl=2 l= 5 prim: OBJECT :des-cbc 3727 1628:d=9 hl=2 l= 13 cons: SEQUENCE 3728 1630:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc 3729 1640:d=10 hl=2 l= 1 prim: INTEGER :28 3730 1643:d=5 hl=2 l= 10 cons: SEQUENCE 3731 1645:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-S 3732 HA256 3733 1655:d=5 hl=2 l= 103 prim: OCTET STRING [HEX DUMP]:30 3734 6502310087389DFC090D8EDB6948FD6B7E5369A5D1EC8B7DB8676F935C9C 3735 6E79EC2727CCFFD8D5DBF937F70EC4E1BFB76ED343B3023063C8E9E69244 3736 8A1EC3D1D8996E03973AC28BEE3C49CD28FDF675A1867852861073244C89 3737 DBAEA8A90BCF35FF92BD43E9 3739 Authors' Addresses 3741 Max Pritikin 3742 Cisco 3744 Email: pritikin@cisco.com 3746 Michael C. Richardson 3747 Sandelman Software Works 3749 Email: mcr+ietf@sandelman.ca 3750 URI: http://www.sandelman.ca/ 3752 Michael H. Behringer 3754 Email: Michael.H.Behring@gmail.com 3756 Steinthor Bjarnason 3757 Arbor Networks 3759 Email: sbjarnason@arbor.net 3761 Kent Watsen 3762 Juniper Networks 3764 Email: kwatsen@juniper.net