doc: Add RFC documents

1 files changed, 5730 insertions, 0 deletions

diff --git a/doc/rfc/rfc8995.txt b/doc/rfc/rfc8995.txt
new file mode 100644
index 0000000..24ac99a
--- /dev/null
+++ b/doc/rfc/rfc8995.txt
@@ -0,0 +1,5730 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       M. Pritikin
+Request for Comments: 8995                                         Cisco
+Category: Standards Track                                  M. Richardson
+ISSN: 2070-1721                                 Sandelman Software Works
+                                                               T. Eckert
+                                                           Futurewei USA
+                                                            M. Behringer
+                                                                        
+                                                               K. Watsen
+                                                         Watsen Networks
+                                                                May 2021
+
+
+         Bootstrapping Remote Secure Key Infrastructure (BRSKI)
+
+Abstract
+
+   This document specifies automated bootstrapping of an Autonomic
+   Control Plane.  To do this, a Secure Key Infrastructure is
+   bootstrapped.  This is done using manufacturer-installed X.509
+   certificates, in combination with a manufacturer's authorizing
+   service, both online and offline.  We call this process the
+   Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
+   Bootstrapping a new device can occur when using a routable address
+   and a cloud service, only link-local connectivity, or limited/
+   disconnected networks.  Support for deployment models with less
+   stringent security requirements is included.  Bootstrapping is
+   complete when the cryptographic identity of the new key
+   infrastructure is successfully deployed to the device.  The
+   established secure connection can be used to deploy a locally issued
+   certificate to the device as well.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8995.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Prior Bootstrapping Approaches
+     1.2.  Terminology
+     1.3.  Scope of Solution
+       1.3.1.  Support Environment
+       1.3.2.  Constrained Environments
+       1.3.3.  Network Access Controls
+       1.3.4.  Bootstrapping is Not Booting
+     1.4.  Leveraging the New Key Infrastructure / Next Steps
+     1.5.  Requirements for Autonomic Networking Infrastructure (ANI)
+           Devices
+   2.  Architectural Overview
+     2.1.  Behavior of a Pledge
+     2.2.  Secure Imprinting Using Vouchers
+     2.3.  Initial Device Identifier
+       2.3.1.  Identification of the Pledge
+       2.3.2.  MASA URI Extension
+     2.4.  Protocol Flow
+     2.5.  Architectural Components
+       2.5.1.  Pledge
+       2.5.2.  Join Proxy
+       2.5.3.  Domain Registrar
+       2.5.4.  Manufacturer Service
+       2.5.5.  Public Key Infrastructure (PKI)
+     2.6.  Certificate Time Validation
+       2.6.1.  Lack of Real-Time Clock
+       2.6.2.  Infinite Lifetime of IDevID
+     2.7.  Cloud Registrar
+     2.8.  Determining the MASA to Contact
+   3.  Voucher-Request Artifact
+     3.1.  Nonceless Voucher-Requests
+     3.2.  Tree Diagram
+     3.3.  Examples
+     3.4.  YANG Module
+   4.  Proxying Details (Pledge -- Proxy -- Registrar)
+     4.1.  Pledge Discovery of Proxy
+       4.1.1.  Proxy GRASP Announcements
+     4.2.  CoAP Connection to Registrar
+     4.3.  Proxy Discovery and Communication of Registrar
+   5.  Protocol Details (Pledge -- Registrar -- MASA)
+     5.1.  BRSKI-EST TLS Establishment Details
+     5.2.  Pledge Requests Voucher from the Registrar
+     5.3.  Registrar Authorization of Pledge
+     5.4.  BRSKI-MASA TLS Establishment Details
+       5.4.1.  MASA Authentication of Customer Registrar
+     5.5.  Registrar Requests Voucher from MASA
+       5.5.1.  MASA Renewal of Expired Vouchers
+       5.5.2.  MASA Pinning of Registrar
+       5.5.3.  MASA Check of the Voucher-Request Signature
+       5.5.4.  MASA Verification of the Domain Registrar
+       5.5.5.  MASA Verification of the Pledge
+               'prior-signed-voucher-request'
+       5.5.6.  MASA Nonce Handling
+     5.6.  MASA and Registrar Voucher Response
+       5.6.1.  Pledge Voucher Verification
+       5.6.2.  Pledge Authentication of Provisional TLS Connection
+     5.7.  Pledge BRSKI Status Telemetry
+     5.8.  Registrar Audit-Log Request
+       5.8.1.  MASA Audit-Log Response
+       5.8.2.  Calculation of domainID
+       5.8.3.  Registrar Audit-Log Verification
+     5.9.  EST Integration for PKI Bootstrapping
+       5.9.1.  EST Distribution of CA Certificates
+       5.9.2.  EST CSR Attributes
+       5.9.3.  EST Client Certificate Request
+       5.9.4.  Enrollment Status Telemetry
+       5.9.5.  Multiple Certificates
+       5.9.6.  EST over CoAP
+   6.  Clarification of Transfer-Encoding
+   7.  Reduced Security Operational Modes
+     7.1.  Trust Model
+     7.2.  Pledge Security Reductions
+     7.3.  Registrar Security Reductions
+     7.4.  MASA Security Reductions
+       7.4.1.  Issuing Nonceless Vouchers
+       7.4.2.  Trusting Owners on First Use
+       7.4.3.  Updating or Extending Voucher Trust Anchors
+   8.  IANA Considerations
+     8.1.  The IETF XML Registry
+     8.2.  YANG Module Names Registry
+     8.3.  BRSKI Well-Known Considerations
+       8.3.1.  BRSKI .well-known Registration
+       8.3.2.  BRSKI .well-known Registry
+     8.4.  PKIX Registry
+     8.5.  Pledge BRSKI Status Telemetry
+     8.6.  DNS Service Names
+     8.7.  GRASP Objective Names
+   9.  Applicability to the Autonomic Control Plane (ACP)
+     9.1.  Operational Requirements
+       9.1.1.  MASA Operational Requirements
+       9.1.2.  Domain Owner Operational Requirements
+       9.1.3.  Device Operational Requirements
+   10. Privacy Considerations
+     10.1.  MASA Audit-Log
+     10.2.  What BRSKI-EST Reveals
+     10.3.  What BRSKI-MASA Reveals to the Manufacturer
+     10.4.  Manufacturers and Used or Stolen Equipment
+     10.5.  Manufacturers and Grey Market Equipment
+     10.6.  Some Mitigations for Meddling by Manufacturers
+     10.7.  Death of a Manufacturer
+   11. Security Considerations
+     11.1.  Denial of Service (DoS) against MASA
+     11.2.  DomainID Must Be Resistant to Second-Preimage Attacks
+     11.3.  Availability of Good Random Numbers
+     11.4.  Freshness in Voucher-Requests
+     11.5.  Trusting Manufacturers
+     11.6.  Manufacturer Maintenance of Trust Anchors
+       11.6.1.  Compromise of Manufacturer IDevID Signing Keys
+       11.6.2.  Compromise of MASA Signing Keys
+       11.6.3.  Compromise of MASA Web Service
+     11.7.  YANG Module Security Considerations
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Appendix A.  IPv4 and Non-ANI Operations
+     A.1.  IPv4 Link-Local Addresses
+     A.2.  Use of DHCPv4
+   Appendix B.  mDNS / DNS-SD Proxy Discovery Options
+   Appendix C.  Example Vouchers
+     C.1.  Keys Involved
+       C.1.1.  Manufacturer Certification Authority for IDevID
+               Signatures
+       C.1.2.  MASA Key Pair for Voucher Signatures
+       C.1.3.  Registrar Certification Authority
+       C.1.4.  Registrar Key Pair
+       C.1.5.  Pledge Key Pair
+     C.2.  Example Process
+       C.2.1.  Pledge to Registrar
+       C.2.2.  Registrar to MASA
+       C.2.3.  MASA to Registrar
+       Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
+   provides a solution for secure zero-touch (automated) bootstrap of
+   new (unconfigured) devices that are called "pledges" in this
+   document.  Pledges have an Initial Device Identifier (IDevID)
+   installed in them at the factory.
+
+   "BRSKI", pronounced like "brewski", is a colloquial term for beer in
+   Canada and parts of the Midwestern United States [brewski].
+
+   This document primarily provides for the needs of the ISP and
+   enterprise-focused Autonomic Networking Integrated Model and Approach
+   (ANIMA) Autonomic Control Plane (ACP) [RFC8994].  This bootstrap
+   process satisfies the requirement of making all operations secure by
+   default per Section 3.3 of [RFC7575].  Other users of the BRSKI
+   protocol will need to provide separate applicability statements that
+   include privacy and security considerations appropriate to that
+   deployment.  Section 9 explains the detailed applicability for this
+   ACP usage.
+
+   The BRSKI protocol requires a significant amount of communication
+   between manufacturer and owner: in its default modes, it provides a
+   cryptographic transfer of control to the initial owner.  In its
+   strongest modes, it leverages sales channel information to identify
+   the owner in advance.  Resale of devices is possible, provided that
+   the manufacturer is willing to authorize the transfer.  Mechanisms to
+   enable transfers of ownership without manufacturer authorization are
+   not included in this version of the protocol, but it could be
+   designed into future versions.
+
+   This document describes how a pledge discovers (or are discovered by)
+   an element of the network domain that it will belong to and that will
+   perform its bootstrap.  This element (device) is called the
+   "registrar".  Before any other operation, the pledge and registrar
+   need to establish mutual trust:
+
+   1.  Registrar authenticating the pledge: "Who is this device?  What
+       is its identity?"
+
+   2.  Registrar authorizing the pledge: "Is it mine?  Do I want it?
+       What are the chances it has been compromised?"
+
+   3.  Pledge authenticating the registrar: "What is this registrar's
+       identity?"
+
+   4.  Pledge authorizing the registrar: "Should I join this network?"
+
+   This document details protocols and messages to answer the above
+   questions.  It uses a TLS connection and a PKIX-shaped (X.509v3)
+   certificate (an IEEE 802.1AR IDevID [IDevID]) of the pledge to answer
+   points 1 and 2.  It uses a new artifact called a "voucher" that the
+   registrar receives from a Manufacturer Authorized Signing Authority
+   (MASA) and passes it to the pledge to answer points 3 and 4.
+
+   A proxy provides very limited connectivity between the pledge and the
+   registrar.
+
+   The syntactic details of vouchers are described in detail in
+   [RFC8366].  This document details automated protocol mechanisms to
+   obtain vouchers, including the definition of a "voucher-request"
+   message that is a minor extension to the voucher format (see
+   Section 3) as defined by [RFC8366].
+
+   BRSKI results in the pledge storing an X.509 root certificate
+   sufficient for verifying the registrar identity.  In the process, a
+   TLS connection is established that can be directly used for
+   Enrollment over Secure Transport (EST).  In effect, BRSKI provides an
+   automated mechanism for "Bootstrap Distribution of CA Certificates"
+   described in [RFC7030], Section 4.1.1, wherein the pledge "MUST [...]
+   engage a human user to authorize the CA certificate using out-of-band
+   data".  With BRSKI, the pledge now can automate this process using
+   the voucher.  Integration with a complete EST enrollment is optional
+   but trivial.
+
+   BRSKI is agile enough to support bootstrapping alternative key
+   infrastructures, such as a symmetric key solution, but no such system
+   is described in this document.
+
+1.1.  Prior Bootstrapping Approaches
+
+   To literally "pull yourself up by the bootstraps" is an impossible
+   action.  Similarly, the secure establishment of a key infrastructure
+   without external help is also an impossibility.  Today, it is
+   commonly accepted that the initial connections between nodes are
+   insecure, until key distribution is complete, or that domain-specific
+   keying material (often pre-shared keys, including mechanisms like
+   Subscriber Identification Module (SIM) cards) is pre-provisioned on
+   each new device in a costly and non-scalable manner.  Existing
+   automated mechanisms are known as non-secured "Trust on First Use
+   (TOFU)" [RFC7435], "resurrecting duckling"
+   [Stajano99theresurrecting], or "pre-staging".
+
+   Another prior approach has been to try and minimize user actions
+   during bootstrapping, but not eliminate all user actions.  The
+   original EST protocol [RFC7030] does reduce user actions during
+   bootstrapping but does not provide solutions for how the following
+   protocol steps can be made autonomic (not involving user actions):
+
+   *  using the Implicit Trust Anchor (TA) [RFC7030] database to
+      authenticate an owner-specific service (not an autonomic solution
+      because the URL must be securely distributed),
+
+   *  engaging a human user to authorize the CA certificate using out-
+      of-band data (not an autonomic solution because the human user is
+      involved),
+
+   *  using a configured Explicit TA database (not an autonomic solution
+      because the distribution of an explicit TA database is not
+      autonomic), and
+
+   *  using a certificate-less TLS mutual authentication method (not an
+      autonomic solution because the distribution of symmetric key
+      material is not autonomic).
+
+   These "touch" methods do not meet the requirements for zero-touch.
+
+   There are "call home" technologies where the pledge first establishes
+   a connection to a well-known manufacturer service using a common
+   client-server authentication model.  After mutual authentication,
+   appropriate credentials to authenticate the target domain are
+   transferred to the pledge.  This creates several problems and
+   limitations:
+
+   *  the pledge requires real-time connectivity to the manufacturer
+      service,
+
+   *  the domain identity is exposed to the manufacturer service (this
+      is a privacy concern), and
+
+   *  the manufacturer is responsible for making the authorization
+      decisions (this is a liability concern).
+
+   BRSKI addresses these issues by defining extensions to the EST
+   protocol for the automated distribution of vouchers.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   The following terms are defined for clarity:
+
+   ANI:  The Autonomic Networking Infrastructure as defined by
+      [RFC8993].  Section 9 details specific requirements for pledges,
+      proxies, and registrars when they are part of an ANI.
+
+   Circuit Proxy:  A stateful implementation of the Join Proxy.  This is
+      the assumed type of proxy.
+
+   drop-ship:  The physical distribution of equipment containing the
+      "factory default" configuration to a final destination.  In zero-
+      touch scenarios, there is no staging or preconfiguration during
+      drop-ship.
+
+   Domain:  The set of entities that share a common local trust anchor.
+      This includes the proxy, registrar, domain CA, management
+      components, and any existing entity that is already a member of
+      the domain.
+
+   Domain CA:  The domain Certification Authority (CA) provides
+      certification functionalities to the domain.  At a minimum, it
+      provides certification functionalities to a registrar and manages
+      the private key that defines the domain.  Optionally, it certifies
+      all elements.
+
+   domainID:  The domain IDentity is a unique value based upon the
+      registrar's CA certificate.  Section 5.8.2 specifies how it is
+      calculated.
+
+   enrollment:  The process where a device presents key material to a
+      network and acquires a network-specific identity.  For example,
+      when a certificate signing request is presented to a CA, and a
+      certificate is obtained in response.
+
+   IDevID:  An Initial Device Identifier X.509 certificate installed by
+      the vendor on new equipment.  This is a term from 802.1AR
+      [IDevID].
+
+   imprint:  The process where a device obtains the cryptographic key
+      material to identify and trust future interactions with a network.
+      This term is taken from Konrad Lorenz's work in biology with new
+      ducklings: during a critical period, the duckling would assume
+      that anything that looks like a mother duck is in fact their
+      mother.  An equivalent for a device is to obtain the fingerprint
+      of the network's root CA certificate.  A device that imprints on
+      an attacker suffers a similar fate to a duckling that imprints on
+      a hungry wolf.  Securely imprinting is a primary focus of this
+      document [imprinting].  The analogy to Lorenz's work was first
+      noted in [Stajano99theresurrecting].
+
+   IPIP Proxy:  A stateless proxy alternative.
+
+   Join Proxy:  A domain entity that helps the pledge join the domain.
+      A Join Proxy facilitates communication for devices that find
+      themselves in an environment where they are not provided
+      connectivity until after they are validated as members of the
+      domain.  For simplicity, this document sometimes uses the term of
+      "proxy" to indicate the Join Proxy.  The pledge is unaware that
+      they are communicating with a proxy rather than directly with a
+      registrar.
+
+   Join Registrar (and Coordinator):  A representative of the domain
+      that is configured, perhaps autonomically, to decide whether a new
+      device is allowed to join the domain.  The administrator of the
+      domain interfaces with a "Join Registrar (and Coordinator)" to
+      control this process.  Typically, a Join Registrar is "inside" its
+      domain.  For simplicity, this document often refers to this as
+      just "registrar".  Within [RFC8993], it is referred to as the
+      "Join Registrar Autonomic Service Agent (ASA)".  Other communities
+      use the abbreviation "JRC".
+
+   LDevID:  A Local Device Identifier X.509 certificate installed by the
+      owner of the equipment.  This is a term from 802.1AR [IDevID].
+
+   manufacturer:  The term manufacturer is used throughout this document
+      as the entity that created the device.  This is typically the
+      original equipment manufacturer (OEM), but in more complex
+      situations, it could be a value added retailer (VAR), or possibly
+      even a systems integrator.  In general, a goal of BRSKI is to
+      eliminate small distinctions between different sales channels.
+      The reason for this is that it permits a single device, with a
+      uniform firmware load, to be shipped directly to all customers.
+      This eliminates costs for the manufacturer.  This also reduces the
+      number of products supported in the field, increasing the chance
+      that firmware will be more up to date.
+
+   MASA Audit-Log:  An anonymized list of previous owners maintained by
+      the MASA on a per-device (per-pledge) basis, as described in
+      Section 5.8.1.
+
+   MASA Service:  A third-party MASA service on the global Internet.
+      The MASA signs vouchers.  It also provides a repository for audit-
+      log information of privacy-protected bootstrapping events.  It
+      does not track ownership.
+
+   nonced:  A voucher (or request) that contains a nonce (the normal
+      case).
+
+   nonceless:  A voucher (or request) that does not contain a nonce and
+      either relies upon accurate clocks for expiration or does not
+      expire.
+
+   offline:  When an architectural component cannot perform real-time
+      communications with a peer, due to either network connectivity or
+      the peer being turned off, the operation is said to be occurring
+      offline.
+
+   Ownership Tracker:  An Ownership Tracker service on the global
+      Internet.  The Ownership Tracker uses business processes to
+      accurately track ownership of all devices shipped against domains
+      that have purchased them.  Although optional, this component
+      allows vendors to provide additional value in cases where their
+      sales and distribution channels allow for accurate tracking of
+      such ownership.  Tracking information about ownership is indicated
+      in vouchers, as described in [RFC8366].
+
+   Pledge:  The prospective (unconfigured) device, which has an identity
+      installed at the factory.
+
+   (Public) Key Infrastructure:  The collection of systems and processes
+      that sustains the activities of a public key system.  The
+      registrar acts as a "Registration Authority"; see [RFC5280] and
+      Section 7 of [RFC5272].
+
+   TOFU:  Trust on First Use. Used similarly to how it is described in
+      [RFC7435].  This is where a pledge device makes no security
+      decisions but rather simply trusts the first registrar it is
+      contacted by.  This is also known as the "resurrecting duckling"
+      model.
+
+   Voucher:  A signed artifact from the MASA that indicates the
+      cryptographic identity of the registrar it should trust to a
+      pledge.  There are different types of vouchers depending on how
+      that trust is asserted.  Multiple voucher types are defined in
+      [RFC8366].
+
+1.3.  Scope of Solution
+
+1.3.1.  Support Environment
+
+   This solution (BRSKI) can support large router platforms with multi-
+   gigabit inter-connections, mounted in controlled access data centers.
+   But this solution is not exclusive to large equipment: it is intended
+   to scale to thousands of devices located in hostile environments,
+   such as ISP-provided Customer Premises Equipment (CPE) devices that
+   are drop-shipped to the end user.  The situation where an order is
+   fulfilled from a distributed warehouse from a common stock and
+   shipped directly to the target location at the request of a domain
+   owner is explicitly supported.  That stock ("SKU") could be provided
+   to a number of potential domain owners, and the eventual domain owner
+   will not know a priori which device will go to which location.
+
+   The bootstrapping process can take minutes to complete depending on
+   the network infrastructure and device processing speed.  The network
+   communication itself is not optimized for speed; for privacy reasons,
+   the discovery process allows for the pledge to avoid announcing its
+   presence through broadcasting.
+
+   Nomadic or mobile devices often need to acquire credentials to access
+   the network at the new location.  An example of this is mobile phone
+   roaming among network operators, or even between cell towers.  This
+   is usually called "handoff".  BRSKI does not provide a low-latency
+   handoff, which is usually a requirement in such situations.  For
+   these solutions, BRSKI can be used to create a relationship (an
+   LDevID) with the "home" domain owner.  The resulting credentials are
+   then used to provide credentials more appropriate for a low-latency
+   handoff.
+
+1.3.2.  Constrained Environments
+
+   Questions have been posed as to whether this solution is suitable in
+   general for Internet of Things (IoT) networks.  This depends on the
+   capabilities of the devices in question.  The terminology of
+   [RFC7228] is best used to describe the boundaries.
+
+   The solution described in this document is aimed in general at non-
+   constrained (i.e., Class 2+ [RFC7228]) devices operating on a non-
+   challenged network.  The entire solution as described here is not
+   intended to be usable as is by constrained devices operating on
+   challenged networks (such as 802.15.4 Low-Power and Lossy Networks
+   (LLNs)).
+
+   Specifically, there are protocol aspects described here that might
+   result in congestion collapse or energy exhaustion of intermediate
+   battery-powered routers in an LLN.  Those types of networks should
+   not use this solution.  These limitations are predominately related
+   to the large credential and key sizes required for device
+   authentication.  Defining symmetric key techniques that meet the
+   operational requirements is out of scope, but the underlying protocol
+   operations (TLS handshake and signing structures) have sufficient
+   algorithm agility to support such techniques when defined.
+
+   The imprint protocol described here could, however, be used by non-
+   energy constrained devices joining a non-constrained network (for
+   instance, smart light bulbs are usually mains powered and use 802.11
+   wireless technology).  It could also be used by non-constrained
+   devices across a non-energy constrained, but challenged, network
+   (such as 802.15.4).  The certificate contents, and the process by
+   which the four questions above are resolved, do apply to constrained
+   devices.  It is simply the actual on-the-wire imprint protocol that
+   could be inappropriate.
+
+1.3.3.  Network Access Controls
+
+   This document presumes that network access control has already
+   occurred, is not required, or is integrated by the proxy and
+   registrar in such a way that the device itself does not need to be
+   aware of the details.  Although the use of an X.509 IDevID is
+   consistent with IEEE 802.1AR [IDevID], and allows for alignment with
+   802.1X network access control methods, its use here is for pledge
+   authentication rather than network access control.  Integrating this
+   protocol with network access control, perhaps as an Extensible
+   Authentication Protocol (EAP) method (see [RFC3748]), is out of scope
+   for this document.
+
+1.3.4.  Bootstrapping is Not Booting
+
+   This document describes "bootstrapping" as the protocol used to
+   obtain a local trust anchor.  It is expected that this trust anchor,
+   along with any additional configuration information subsequently
+   installed, is persisted on the device across system restarts
+   ("booting").  Bootstrapping occurs only infrequently such as when a
+   device is transferred to a new owner or has been reset to factory
+   default settings.
+
+1.4.  Leveraging the New Key Infrastructure / Next Steps
+
+   As a result of the protocol described herein, bootstrapped devices
+   have the domain CA trust anchor in common.  An end-entity (EE)
+   certificate has optionally been issued from the domain CA.  This
+   makes it possible to securely deploy functionalities across the
+   domain; for example:
+
+   *  Device management
+
+   *  Routing authentication
+
+   *  Service discovery
+
+   The major intended benefit is the ability to use the credentials
+   deployed by this protocol to secure the Autonomic Control Plane (ACP)
+   [RFC8994].
+
+1.5.  Requirements for Autonomic Networking Infrastructure (ANI) Devices
+
+   The BRSKI protocol can be used in a number of environments.  Some of
+   the options in this document are the result of requirements that are
+   out of the ANI scope.  This section defines the base requirements for
+   ANI devices.
+
+   For devices that intend to become part of an ANI [RFC8993] that
+   includes an Autonomic Control Plane [RFC8994], the BRSKI protocol
+   MUST be implemented.
+
+   The pledge must perform discovery of the proxy as described in
+   Section 4.1 using the Discovery Unsolicited Link-Local (DULL)
+   [RFC8990] M_FLOOD announcements of the GeneRic Autonomic Signaling
+   Protocol (GRASP).
+
+   Upon successfully validating a voucher artifact, a status telemetry
+   MUST be returned; see Section 5.7.
+
+   An ANIMA ANI pledge MUST implement the EST automation extensions
+   described in Section 5.9.  They supplement the EST [RFC7030] to
+   better support automated devices that do not have an end user.
+
+   The ANI Join Registrar ASA MUST support all the BRSKI and above-
+   listed EST operations.
+
+   All ANI devices SHOULD support the BRSKI proxy function, using
+   Circuit Proxies over the Autonomic Control Plane (ACP) (see
+   Section 4.3).
+
+2.  Architectural Overview
+
+   The logical elements of the bootstrapping framework are described in
+   this section.  Figure 1 provides a simplified overview of the
+   components.
+
+                                              +------------------------+
+      +--------------Drop-Ship----------------| Vendor Service         |
+      |                                       +------------------------+
+      |                                       | M anufacturer|         |
+      |                                       | A uthorized  |Ownership|
+      |                                       | S igning     |Tracker  |
+      |                                       | A uthority   |         |
+      |                                       +--------------+---------+
+      |                                                      ^
+      |                                                      |  BRSKI-
+      V                                                      |   MASA
+   +-------+     ............................................|...
+   |       |     .                                           |  .
+   |       |     .  +------------+       +-----------+       |  .
+   |       |     .  |            |       |           |       |  .
+   |Pledge |     .  |   Join     |       | Domain    <-------+  .
+   |       |     .  |   Proxy    |       | Registrar |          .
+   |       <-------->............<-------> (PKI RA)  |          .
+   |       |        |        BRSKI-EST   |           |          .
+   |       |     .  |            |       +-----+-----+          .
+   |IDevID |     .  +------------+             | e.g., RFC 7030 .
+   |       |     .           +-----------------+----------+     .
+   |       |     .           | Key Infrastructure         |     .
+   |       |     .           | (e.g., PKI CA)             |     .
+   +-------+     .           |                            |     .
+                 .           +----------------------------+     .
+                 .                                              .
+                 ................................................
+                               "Domain" Components
+
+                      Figure 1: Architecture Overview
+
+   We assume a multivendor network.  In such an environment, there could
+   be a manufacturer service for each manufacturer that supports devices
+   following this document's specification, or an integrator could
+   provide a generic service authorized by multiple manufacturers.  It
+   is unlikely that an integrator could provide ownership tracking
+   services for multiple manufacturers due to the required sales channel
+   integrations necessary to track ownership.
+
+   The domain is the managed network infrastructure with a key
+   infrastructure that the pledge is joining.  The domain provides
+   initial device connectivity sufficient for bootstrapping through a
+   proxy.  The domain registrar authenticates the pledge, makes
+   authorization decisions, and distributes vouchers obtained from the
+   manufacturer service.  Optionally, the registrar also acts as a PKI
+   CA.
+
+2.1.  Behavior of a Pledge
+
+   The pledge goes through a series of steps, which are outlined here at
+   a high level.
+
+                  ------------
+                 /  Factory   \
+                 \  default   /
+                  -----+------
+                       |
+                +------v-------+
+                | (1) Discover |
+   +------------>              |
+   |            +------+-------+
+   |                   |
+   |            +------v-------+
+   |            | (2) Identify |
+   ^------------+              |
+   | rejected   +------+-------+
+   |                   |
+   |            +------v-------+
+   |            | (3) Request  |
+   |            |     Join     |
+   |            +------+-------+
+   |                   |
+   |            +------v-------+
+   |            | (4) Imprint  |
+   ^------------+              |
+   | Bad MASA   +------+-------+
+   | response          |  send Voucher Status Telemetry
+   |            +------v-------+
+   |            | (5) Enroll   |<---+ (non-error HTTP codes)
+   ^------------+              |\___/ (e.g., 202 "Retry-After")
+   | Enroll     +------+-------+
+   | failure           |
+   |              -----v------
+   |             /  Enrolled  \
+   ^------------+             |
+    Factory      \------------/
+    reset
+
+                       Figure 2: Pledge State Diagram
+
+   State descriptions for the pledge are as follows:
+
+   1.  Discover a communication channel to a registrar.
+
+   2.  Identify itself.  This is done by presenting an X.509 IDevID
+       credential to the discovered registrar (via the proxy) in a TLS
+       handshake.  (The registrar credentials are only provisionally
+       accepted at this time.)
+
+   3.  Request to join the discovered registrar.  A unique nonce is
+       included, ensuring that any responses can be associated with this
+       particular bootstrapping attempt.
+
+   4.  Imprint on the registrar.  This requires verification of the
+       manufacturer-service-provided voucher.  A voucher contains
+       sufficient information for the pledge to complete authentication
+       of a registrar.  This document details this step in depth.
+
+   5.  Enroll.  After imprint, an authenticated TLS (HTTPS) connection
+       exists between the pledge and registrar.  EST [RFC7030] can then
+       be used to obtain a domain certificate from a registrar.
+
+   The pledge is now a member of, and can be managed by, the domain and
+   will only repeat the discovery aspects of bootstrapping if it is
+   returned to factory default settings.
+
+   This specification details integration with EST enrollment so that
+   pledges can optionally obtain a locally issued certificate, although
+   any Representational State Transfer (REST) (see [REST]) interface
+   could be integrated in future work.
+
+2.2.  Secure Imprinting Using Vouchers
+
+   A voucher is a cryptographically protected artifact (using a digital
+   signature) to the pledge device authorizing a zero-touch imprint on
+   the registrar domain.
+
+   The format and cryptographic mechanism of vouchers is described in
+   detail in [RFC8366].
+
+   Vouchers provide a flexible mechanism to secure imprinting: the
+   pledge device only imprints when a voucher can be validated.  At the
+   lowest security levels, the MASA can indiscriminately issue vouchers
+   and log claims of ownership by domains.  At the highest security
+   levels, issuance of vouchers can be integrated with complex sales
+   channel integrations that are beyond the scope of this document.  The
+   sales channel integration would verify actual (legal) ownership of
+   the pledge by the domain.  This provides the flexibility for a number
+   of use cases via a single common protocol mechanism on the pledge and
+   registrar devices that are to be widely deployed in the field.  The
+   MASA services have the flexibility to either leverage the currently
+   defined claim mechanisms or experiment with higher or lower security
+   levels.
+
+   Vouchers provide a signed but non-encrypted communication channel
+   among the pledge, the MASA, and the registrar.  The registrar
+   maintains control over the transport and policy decisions, allowing
+   the local security policy of the domain network to be enforced.
+
+2.3.  Initial Device Identifier
+
+   Pledge authentication and pledge voucher-request signing is via a
+   PKIX-shaped certificate installed during the manufacturing process.
+   This is the 802.1AR IDevID, and it provides a basis for
+   authenticating the pledge during the protocol exchanges described
+   here.  There is no requirement for a common root PKI hierarchy.  Each
+   device manufacturer can generate its own root certificate.
+   Specifically, the IDevID enables:
+
+   *  Uniquely identifying the pledge by the Distinguished Name (DN) and
+      subjectAltName (SAN) parameters in the IDevID.  The unique
+      identification of a pledge in the voucher objects are derived from
+      those parameters as described below.  Section 10.3 discusses
+      privacy implications of the identifier.
+
+   *  Providing a cryptographic authentication of the pledge to the
+      registrar (see Section 5.3).
+
+   *  Securing auto-discovery of the pledge's MASA by the registrar (see
+      Section 2.8).
+
+   *  Signing of a voucher-request by the pledge's IDevID (see
+      Section 3).
+
+   *  Providing a cryptographic authentication of the pledge to the MASA
+      (see Section 5.5.5).
+
+   Sections 7.2.13 (2009 edition) and 8.10.3 (2018 edition) of [IDevID]
+   discuss keyUsage and extendedKeyUsage extensions in the IDevID
+   certificate.  [IDevID] acknowledges that adding restrictions in the
+   certificate limits applicability of these long-lived certificates.
+   This specification emphasizes this point and therefore RECOMMENDS
+   that no key usage restrictions be included.  This is consistent with
+   [RFC5280], Section 4.2.1.3, which does not require key usage
+   restrictions for end-entity certificates.
+
+2.3.1.  Identification of the Pledge
+
+   In the context of BRSKI, pledges have a 1:1 relationship with a
+   "serial-number".  This serial-number is used both in the serial-
+   number field of a voucher or voucher-requests (see Section 3) and in
+   local policies on the registrar or MASA (see Section 5).
+
+   There is a (certificate) serialNumber field defined in [RFC5280],
+   Section 4.1.2.2.  In ASN.1, this is referred to as the
+   CertificateSerialNumber.  This field is NOT relevant to this
+   specification.  Do not confuse this field with the serial-number
+   defined by this document, or by [IDevID] and [RFC4519], Section 2.31.
+
+   The device serial number is defined in Appendix A.1 of [RFC5280] as
+   the X520SerialNumber, with the OID tag id-at-serialNumber.
+
+   The device _serialNumber_ field (X520SerialNumber) is used as follows
+   by the pledge to build the *serial-number* that is placed in the
+   voucher-request.  In order to build it, the fields need to be
+   converted into a serial-number of "type string".
+
+   An example of a printable form of the serialNumber field is provided
+   in [RFC4519], Section 2.31 ("WI-3005").  That section further
+   provides equality and syntax attributes.
+
+   Due to the reality of existing device identity provisioning
+   processes, some manufacturers have stored serial-numbers in other
+   fields.  Registrars SHOULD be configurable, on a per-manufacturer
+   basis, to look for serial-number equivalents in other fields.
+
+   As explained in Section 5.5, the registrar MUST again extract the
+   serialNumber itself from the pledge's TLS certificate.  It can
+   consult the serial-number in the pledge request if there is any
+   possible confusion about the source of the serial-number.
+
+2.3.2.  MASA URI Extension
+
+   This document defines a new PKIX non-critical certificate extension
+   to carry the MASA URI.  This extension is intended to be used in the
+   IDevID certificate.  The URI is represented as described in
+   Section 7.4 of [RFC5280].
+
+   The URI provides the authority information.  The BRSKI "/.well-known"
+   tree [RFC8615] is described in Section 5.
+
+   A complete URI MAY be in this extension, including the "scheme",
+   "authority", and "path".  The complete URI will typically be used in
+   diagnostic or experimental situations.  Typically (and in
+   consideration to constrained systems), this SHOULD be reduced to only
+   the "authority", in which case a scheme of "https://" (see [RFC7230],
+   Section 2.7.3) and a "path" of "/.well-known/brski" is to be assumed.
+
+   The registrar can assume that only the "authority" is present in the
+   extension, if there are no slash ("/") characters in the extension.
+
+   Section 7.4 of [RFC5280] calls out various schemes that MUST be
+   supported, including the Lightweight Directory Access Protocol
+   (LDAP), HTTP, and FTP.  However, the registrar MUST use HTTPS for the
+   BRSKI-MASA connection.
+
+   The new extension is identified as follows:
+
+   <CODE BEGINS>
+   MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)
+   internet(1) security(5) mechanisms(5) pkix(7)
+   id-mod(0) id-mod-MASAURLExtn2016(96) }
+
+   DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+   EXTENSION
+   FROM PKIX-CommonTypes-2009
+     { iso(1) identified-organization(3) dod(6) internet(1)
+       security(5) mechanisms(5) pkix(7) id-mod(0)
+       id-mod-pkixCommon-02(57) }
+
+   id-pe FROM PKIX1Explicit-2009
+     { iso(1) identified-organization(3) dod(6) internet(1)
+        security(5) mechanisms(5) pkix(7) id-mod(0)
+        id-mod-pkix1-explicit-02(51) } ;
+
+   MASACertExtensions EXTENSION ::= { ext-MASAURL, ... }
+   ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax
+   IDENTIFIED BY id-pe-masa-url }
+
+   id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe 32 }
+
+   MASAURLSyntax ::= IA5String
+
+   END
+   <CODE ENDS>
+
+                       Figure 3: MASAURL ASN.1 Module
+
+   The choice of id-pe is based on guidance found in Section 4.2.2 of
+   [RFC5280]: "These extensions may be used to direct applications to
+   on-line information about the issuer or the subject".  The MASA URL
+   is precisely that: online information about the particular subject.
+
+2.4.  Protocol Flow
+
+   A representative flow is shown in Figure 4.
+
+   +--------+         +---------+    +------------+     +------------+
+   | Pledge |         | Circuit |    | Domain     |     | Vendor     |
+   |        |         | Join    |    | Registrar  |     | Service    |
+   |        |         | Proxy   |    |  (JRC)     |     | (MASA)     |
+   +--------+         +---------+    +------------+     +------------+
+     |                     |                   |           Internet |
+   [discover]              |                   |                    |
+     |<-RFC 4862 IPv6 addr |                   |                    |
+     |<-RFC 3927 IPv4 addr | Appendix A        |  Legend            |
+     |-++++++++++++++++++->|                   | C - Circuit        |
+     | optional: mDNS query| Appendix B        |     Join Proxy     |
+     | RFCs 6763/6762 (+)  |                   | P - Provisional TLS|
+     |<-++++++++++++++++++-|                   |     Connection     |
+     | GRASP M_FLOOD       |                   |                    |
+     |   periodic broadcast|                   |                    |
+   [identity]              |                   |                    |
+     |<------------------->C<----------------->|                    |
+     |         TLS via the Join Proxy          |                    |
+     |<--Registrar TLS server authentication---|                    |
+   [PROVISIONAL accept of server cert]         |                    |
+     P---X.509 client authentication---------->|                    |
+   [request join]                              |                    |
+     P---Voucher-Request(w/nonce for voucher)->|                    |
+     P                  /-------------------   |                    |
+     P                  |                 [accept device?]          |
+     P                  |                 [contact vendor]          |
+     P                  |                      |--Pledge ID-------->|
+     P                  |                      |--Domain ID-------->|
+     P                  |                      |--optional:nonce--->|
+     P              optional:                  |     [extract DomainID]
+     P        can occur in advance             |     [update audit-log]
+     P            if nonceless                 |                    |
+     P                  |                      |<- voucher ---------|
+     P                  \-------------------   | w/nonce if provided|
+     P<------voucher---------------------------|                    |
+   [imprint]                                   |                    |
+     |-------voucher status telemetry--------->|                    |
+     |                                         |<-device audit-log--|
+     |                             [verify audit-log and voucher]   |
+     |<--------------------------------------->|                    |
+   [enroll]                                    |                    |
+     | Continue with enrollment using now      |                    |
+     | bidirectionally authenticated TLS       |                    |
+     | session per RFC 7030.                   |                    |
+   [enrolled]                                  |                    |
+
+                  Figure 4: Protocol Time Sequence Diagram
+
+   On initial bootstrap, a new device (the pledge) uses a local service
+   auto-discovery (the GeneRic Autonomic Signaling Protocol (GRASP) or
+   Multicast DNS (mDNS)) to locate a Join Proxy.  The Join Proxy
+   connects the pledge to a local registrar (the JRC).
+
+   Having found a candidate registrar, the fledgling pledge sends some
+   information about itself to the registrar, including its serial
+   number in the form of a voucher-request and its IDevID certificate as
+   part of the TLS session.
+
+   The registrar can determine whether it expected such a device to
+   appear and locates a MASA.  The location of the MASA is usually found
+   in an extension in the IDevID.  Having determined that the MASA is
+   suitable, the entire information from the initial voucher-request
+   (including the device's serial number) is transmitted over the
+   Internet in a TLS-protected channel to the manufacturer, along with
+   information about the registrar/owner.
+
+   The manufacturer can then apply policy based on the provided
+   information, as well as other sources of information (such as sales
+   records), to decide whether to approve the claim by the registrar to
+   own the device; if the claim is accepted, a voucher is issued that
+   directs the device to accept its new owner.
+
+   The voucher is returned to the registrar, but not immediately to the
+   device -- the registrar has an opportunity to examine the voucher,
+   the MASA's audit-logs, and other sources of information to determine
+   whether the device has been tampered with and whether the bootstrap
+   should be accepted.
+
+   No filtering of information is possible in the signed voucher, so
+   this is a binary yes-or-no decision.  After the registrar has applied
+   any local policy to the voucher, if it accepts the voucher, then the
+   voucher is returned to the pledge for imprinting.
+
+   The voucher also includes a trust anchor that the pledge uses to
+   represent the owner.  This is used to successfully bootstrap from an
+   environment where only the manufacturer has built-in trust by the
+   device to an environment where the owner now has a PKI footprint on
+   the device.
+
+   When BRSKI is followed with EST, this single footprint is further
+   leveraged into the full owner's PKI and an LDevID for the device.
+   Subsequent reporting steps provide flows of information to indicate
+   success/failure of the process.
+
+2.5.  Architectural Components
+
+2.5.1.  Pledge
+
+   The pledge is the device that is attempting to join.  It is assumed
+   that the pledge talks to the Join Proxy using link-local network
+   connectivity.  In most cases, the pledge has no other connectivity
+   until the pledge completes the enrollment process and receives some
+   kind of network credential.
+
+2.5.2.  Join Proxy
+
+   The Join Proxy provides HTTPS connectivity between the pledge and the
+   registrar.  A Circuit Proxy mechanism is described in Section 4.
+   Additional mechanisms, including a Constrained Application Protocol
+   (CoAP) mechanism and a stateless IP in IP (IPIP) mechanism, are the
+   subject of future work.
+
+2.5.3.  Domain Registrar
+
+   The domain's registrar operates as the BRSKI-MASA client when
+   requesting vouchers from the MASA (see Section 5.4).  The registrar
+   operates as the BRSKI-EST server when pledges request vouchers (see
+   Section 5.1).  The registrar operates as the BRSKI-EST server
+   "Registration Authority" if the pledge requests an end-entity
+   certificate over the BRSKI-EST connection (see Section 5.9).
+
+   The registrar uses an Implicit Trust Anchor database for
+   authenticating the BRSKI-MASA connection's MASA TLS server
+   certificate.  Configuration or distribution of trust anchors is out
+   of scope for this specification.
+
+   The registrar uses a different Implicit Trust Anchor database for
+   authenticating the BRSKI-EST connection's pledge TLS Client
+   Certificate.  Configuration or distribution of the BRSKI-EST client
+   trust anchors is out of scope of this specification.  Note that the
+   trust anchors in / excluded from the database will affect which
+   manufacturers' devices are acceptable to the registrar as pledges,
+   and they can also be used to limit the set of MASAs that are trusted
+   for enrollment.
+
+2.5.4.  Manufacturer Service
+
+   The manufacturer service provides two logically separate functions:
+   the MASA as described in Sections 5.5 and 5.6 and an ownership
+   tracking/auditing function as described in Sections 5.7 and 5.8.
+
+2.5.5.  Public Key Infrastructure (PKI)
+
+   The Public Key Infrastructure (PKI) administers certificates for the
+   domain of concern, providing the trust anchor(s) for it and allowing
+   enrollment of pledges with domain certificates.
+
+   The voucher provides a method for the distribution of a single PKI
+   trust anchor (as the "pinned-domain-cert").  A distribution of the
+   full set of current trust anchors is possible using the optional EST
+   integration.
+
+   The domain's registrar acts as a Registration Authority [RFC5272],
+   requesting certificates for pledges from the PKI.
+
+   The expectations of the PKI are unchanged from EST [RFC7030].  This
+   document does not place any additional architectural requirements on
+   the PKI.
+
+2.6.  Certificate Time Validation
+
+2.6.1.  Lack of Real-Time Clock
+
+   When bootstrapping, many devices do not have knowledge of the current
+   time.  Mechanisms such as Network Time Protocols cannot be secured
+   until bootstrapping is complete.  Therefore, bootstrapping is defined
+   with a framework that does not require knowledge of the current time.
+   A pledge MAY ignore all time stamps in the voucher and in the
+   certificate validity periods if it does not know the current time.
+
+   The pledge is exposed to dates in the following five places:
+   registrar certificate notBefore, registrar certificate notAfter,
+   voucher created-on, and voucher expires-on.  Additionally,
+   Cryptographic Message Syntax (CMS) signatures contain a signingTime.
+
+   A pledge with a real-time clock in which it has confidence MUST check
+   the above time fields in all certificates and signatures that it
+   processes.
+
+   If the voucher contains a nonce, then the pledge MUST confirm the
+   nonce matches the original pledge voucher-request.  This ensures the
+   voucher is fresh.  See Section 5.2.
+
+2.6.2.  Infinite Lifetime of IDevID
+
+   Long-lived pledge certificates "SHOULD be assigned the
+   GeneralizedTime value of 99991231235959Z" for the notAfter field as
+   explained in [RFC5280].
+
+   Some deployed IDevID management systems are not compliant with the
+   802.1AR requirement for infinite lifetimes and are put in typical <=
+   3 year certificate lifetimes.  Registrars SHOULD be configurable on a
+   per-manufacturer basis to ignore pledge lifetimes when the pledge
+   does not follow the recommendations in [RFC5280].
+
+2.7.  Cloud Registrar
+
+   There exist operationally open networks wherein devices gain
+   unauthenticated access to the Internet at large.  In these use cases,
+   the management domain for the device needs to be discovered within
+   the larger Internet.  The case where a device can boot and get access
+   to a larger Internet is less likely within the ANIMA ACP scope but
+   may be more important in the future.  In the ANIMA ACP scope, new
+   devices will be quarantined behind a Join Proxy.
+
+   Additionally, there are some greenfield situations involving an
+   entirely new installation where a device may have some kind of
+   management uplink that it can use (such as via a 3G network, for
+   instance).  In such a future situation, the device might use this
+   management interface to learn that it should configure itself to
+   become the local registrar.
+
+   In order to support these scenarios, the pledge MAY contact a well-
+   known URI of a cloud registrar if a local registrar cannot be
+   discovered or if the pledge's target use cases do not include a local
+   registrar.
+
+   If the pledge uses a well-known URI for contacting a cloud registrar,
+   a manufacturer-assigned Implicit Trust Anchor database (see
+   [RFC7030]) MUST be used to authenticate that service as described in
+   [RFC6125].  The use of a DNS-ID for validation is appropriate, and it
+   may include wildcard components on the left-mode side.  This is
+   consistent with the human-user configuration of an EST server URI in
+   [RFC7030], which also depends on [RFC6125].
+
+2.8.  Determining the MASA to Contact
+
+   The registrar needs to be able to contact a MASA that is trusted by
+   the pledge in order to obtain vouchers.
+
+   The device's IDevID will normally contain the MASA URL as detailed in
+   Section 2.3.  This is the RECOMMENDED mechanism.
+
+   In some cases, it can be operationally difficult to ensure the
+   necessary X.509 extensions are in the pledge's IDevID due to the
+   difficulty of aligning current pledge manufacturing with software
+   releases and development; thus, as a final fallback, the registrar
+   MAY be manually configured or distributed with a MASA URL for each
+   manufacturer.  Note that the registrar can only select the configured
+   MASA URL based on the trust anchor -- so manufacturers can only
+   leverage this approach if they ensure a single MASA URL works for all
+   pledges associated with each trust anchor.
+
+3.  Voucher-Request Artifact
+
+   Voucher-requests are how vouchers are requested.  The semantics of
+   the voucher-request are described below, in the YANG module.
+
+   A pledge forms the "pledge voucher-request", signs it with its
+   IDevID, and submits it to the registrar.
+
+   In turn, the registrar forms the "registrar voucher-request", signs
+   it with its registrar key pair, and submits it to the MASA.
+
+   The "proximity-registrar-cert" leaf is used in the pledge voucher-
+   requests.  This provides a method for the pledge to assert the
+   registrar's proximity.
+
+   This network proximity results from the following properties in the
+   ACP context: the pledge is connected to the Join Proxy (Section 4)
+   using a link-local IPv6 connection.  While the Join Proxy does not
+   participate in any meaningful sense in the cryptography of the TLS
+   connection (such as via a Channel Binding), the registrar can observe
+   that the connection is via the private ACP (ULA) address of the Join
+   Proxy, and it cannot come from outside the ACP.  The pledge must
+   therefore be at most one IPv6 link-local hop away from an existing
+   node on the ACP.
+
+   Other users of BRSKI will need to define other kinds of assertions if
+   the network proximity described above does not match their needs.
+
+   The "prior-signed-voucher-request" leaf is used in registrar voucher-
+   requests.  If present, it is the signed pledge voucher-request
+   artifact.  This provides a method for the registrar to forward the
+   pledge's signed request to the MASA.  This completes transmission of
+   the signed proximity-registrar-cert leaf.
+
+   Unless otherwise signaled (outside the voucher-request artifact), the
+   signing structure is as defined for vouchers; see [RFC8366].
+
+3.1.  Nonceless Voucher-Requests
+
+   A registrar MAY also retrieve nonceless vouchers by sending nonceless
+   voucher-requests to the MASA in order to obtain vouchers for use when
+   the registrar does not have connectivity to the MASA.  No prior-
+   signed-voucher-request leaf would be included.  The registrar will
+   also need to know the serial number of the pledge.  This document
+   does not provide a mechanism for the registrar to learn that in an
+   automated fashion.  Typically, this will be done via the scanning of
+   a bar code or QR code on packaging, or via some sales channel
+   integration.
+
+3.2.  Tree Diagram
+
+   The following tree diagram illustrates a high-level view of a
+   voucher-request document.  The voucher-request builds upon the
+   voucher artifact described in [RFC8366].  The tree diagram is
+   described in [RFC8340].  Each node in the diagram is fully described
+   by the YANG module in Section 3.4.  Please review the YANG module for
+   a detailed description of the voucher-request format.
+
+   module: ietf-voucher-request
+
+    grouping voucher-request-grouping
+     +-- voucher
+        +-- created-on?                      yang:date-and-time
+        +-- expires-on?                      yang:date-and-time
+        +-- assertion?                       enumeration
+        +-- serial-number                    string
+        +-- idevid-issuer?                   binary
+        +-- pinned-domain-cert?              binary
+        +-- domain-cert-revocation-checks?   boolean
+        +-- nonce?                           binary
+        +-- last-renewal-date?               yang:date-and-time
+        +-- prior-signed-voucher-request?    binary
+        +-- proximity-registrar-cert?        binary
+
+             Figure 5: YANG Tree Diagram for a Voucher-Request
+
+3.3.  Examples
+
+   This section provides voucher-request examples for illustration
+   purposes.  These examples show JSON prior to CMS wrapping.  JSON
+   encoding rules specify that any binary content be base64 encoded
+   ([RFC4648], Section 4).  The contents of the (base64) encoded
+   certificates have been elided to save space.  For detailed examples,
+   see Appendix C.2.  These examples conform to the encoding rules
+   defined in [RFC7951].
+
+   Example (1):  The following example illustrates a pledge voucher-
+                 request.  The assertion leaf is indicated as
+                 "proximity", and the registrar's TLS server certificate
+                 is included in the proximity-registrar-cert leaf.  See
+                 Section 5.2.
+
+   {
+       "ietf-voucher-request:voucher": {
+           "assertion": "proximity",
+           "nonce": "62a2e7693d82fcda2624de58fb6722e5",
+           "serial-number" : "JADA123456789",
+           "created-on": "2017-01-01T00:00:00.000Z",
+           "proximity-registrar-cert": "base64encodedvalue=="
+       }
+   }
+
+        Figure 6: JSON Representation of an Example Voucher-Request
+
+   Example (2):  The following example illustrates a registrar voucher-
+                 request.  The prior-signed-voucher-request leaf is
+                 populated with the pledge's voucher-request (such as
+                 the prior example).  The pledge's voucher-request is a
+                 binary CMS-signed object.  In the JSON encoding used
+                 here, it must be base64 encoded.  The nonce and
+                 assertion have been carried forward from the pledge
+                 request to the registrar request.  The serial-number is
+                 extracted from the pledge's Client Certificate from the
+                 TLS connection.  See Section 5.5.
+
+   {
+       "ietf-voucher-request:voucher": {
+           "assertion" : "proximity",
+           "nonce": "62a2e7693d82fcda2624de58fb6722e5",
+           "created-on": "2017-01-01T00:00:02.000Z",
+           "idevid-issuer": "base64encodedvalue==",
+           "serial-number": "JADA123456789",
+           "prior-signed-voucher-request": "base64encodedvalue=="
+       }
+   }
+
+     Figure 7: JSON Representation of an Example Prior-Signed Voucher-
+                                  Request
+
+   Example (3):  The following example illustrates a registrar voucher-
+                 request.  The prior-signed-voucher-request leaf is not
+                 populated with the pledge's voucher-request nor is the
+                 nonce leaf.  This form might be used by a registrar
+                 requesting a voucher when the pledge cannot communicate
+                 with the registrar (such as when it is powered down or
+                 still in packaging) and therefore cannot submit a
+                 nonce.  This scenario is most useful when the registrar
+                 is aware that it will not be able to reach the MASA
+                 during deployment.  See Section 5.5.
+
+   {
+       "ietf-voucher-request:voucher": {
+           "created-on":    "2017-01-01T00:00:02.000Z",
+           "idevid-issuer": "base64encodedvalue==",
+           "serial-number": "JADA123456789"
+       }
+   }
+
+        Figure 8: JSON Representation of an Offline Voucher-Request
+
+3.4.  YANG Module
+
+   Following is a YANG module [RFC7950] that formally extends a voucher
+   [RFC8366] into a voucher-request.  This YANG module references
+   [ITU.X690].
+
+   <CODE BEGINS> file "ietf-voucher-request@2021-05-20.yang"
+   module ietf-voucher-request {
+     yang-version 1.1;
+     namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
+     prefix vcr;
+
+     import ietf-restconf {
+       prefix rc;
+       description
+         "This import statement is only present to access
+          the yang-data extension defined in RFC 8040.";
+       reference
+         "RFC 8040: RESTCONF Protocol";
+     }
+     import ietf-voucher {
+       prefix vch;
+       description
+         "This module defines the format for a voucher,
+          which is produced by a pledge's manufacturer or
+          delegate (MASA) to securely assign a pledge to
+          an 'owner', so that the pledge may establish a secure
+          connection to the owner's network infrastructure.";
+       reference
+         "RFC 8366: A Voucher Artifact for
+          Bootstrapping Protocols";
+     }
+
+     organization
+       "IETF ANIMA Working Group";
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/anima/>
+        WG List:  <mailto:anima@ietf.org>
+        Author:   Kent Watsen
+                  <mailto:kent+ietf@watsen.net>
+        Author:   Michael H. Behringer
+                  <mailto:Michael.H.Behringer@gmail.com>
+        Author:   Toerless Eckert
+                  <mailto:tte+ietf@cs.fau.de>
+        Author:   Max Pritikin
+                  <mailto:pritikin@cisco.com>
+        Author:   Michael Richardson
+                  <mailto:mcr+ietf@sandelman.ca>";
+     description
+       "This module defines the format for a voucher-request.
+        It is a superset of the voucher itself.
+        It provides content to the MASA for consideration
+        during a voucher-request.
+
+        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
+        'MAY', and 'OPTIONAL' in this document are to be interpreted as
+        described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
+        they appear in all capitals, as shown here.
+
+        Copyright (c) 2021 IETF Trust and the persons identified as
+        authors of the code. All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject
+        to the license terms contained in, the Simplified BSD License
+        set forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (https://trustee.ietf.org/license-info).
+
+        This version of this YANG module is part of RFC 8995; see the
+        RFC itself for full legal notices.";
+
+     revision 2021-05-20 {
+       description
+         "Initial version";
+       reference
+         "RFC 8995: Bootstrapping Remote Secure Key Infrastructure
+          (BRSKI)";
+     }
+
+     // Top-level statement
+     rc:yang-data voucher-request-artifact {
+       uses voucher-request-grouping;
+     }
+
+     // Grouping defined for future usage
+
+     grouping voucher-request-grouping {
+       description
+         "Grouping to allow reuse/extensions in future work.";
+       uses vch:voucher-artifact-grouping {
+         refine "voucher/created-on" {
+           mandatory false;
+         }
+         refine "voucher/pinned-domain-cert" {
+           mandatory false;
+           description
+             "A pinned-domain-cert field is not valid in a
+              voucher-request, and any occurrence MUST be ignored.";
+         }
+         refine "voucher/last-renewal-date" {
+           description
+             "A last-renewal-date field is not valid in a
+              voucher-request, and any occurrence MUST be ignored.";
+         }
+         refine "voucher/domain-cert-revocation-checks" {
+           description
+             "The domain-cert-revocation-checks field is not valid in a
+              voucher-request, and any occurrence MUST be ignored.";
+         }
+         refine "voucher/assertion" {
+           mandatory false;
+           description
+             "Any assertion included in registrar voucher-requests
+              SHOULD be ignored by the MASA.";
+         }
+         augment "voucher" {
+           description
+             "Adds leaf nodes appropriate for requesting vouchers.";
+           leaf prior-signed-voucher-request {
+             type binary;
+             description
+               "If it is necessary to change a voucher, or re-sign and
+                forward a voucher that was previously provided along a
+                protocol path, then the previously signed voucher SHOULD
+                be included in this field.
+
+                For example, a pledge might sign a voucher-request
+                with a proximity-registrar-cert, and the registrar
+                then includes it as the prior-signed-voucher-request
+                field.  This is a simple mechanism for a chain of
+                trusted parties to change a voucher-request, while
+                maintaining the prior signature information.
+
+                The registrar and MASA MAY examine the prior-signed
+                voucher information for the
+                purposes of policy decisions.  For example, this
+                information could be useful to a MASA to determine
+                that both the pledge and registrar agree on proximity
+                assertions.  The MASA SHOULD remove all
+                prior-signed-voucher-request information when
+                signing a voucher for imprinting so as to minimize
+                the final voucher size.";
+           }
+           leaf proximity-registrar-cert {
+             type binary;
+             description
+               "An X.509 v3 certificate structure, as specified by
+                RFC 5280, Section 4, encoded using the ASN.1
+                distinguished encoding rules (DER), as specified
+                in ITU X.690.
+
+                The first certificate in the registrar TLS server
+                certificate_list sequence (the end-entity TLS
+                certificate; see RFC 8446) presented by the registrar
+                to the pledge.  This MUST be populated in a pledge's
+                voucher-request when a proximity assertion is
+                requested.";
+             reference
+               "ITU X.690: Information Technology - ASN.1 encoding
+                rules: Specification of Basic Encoding Rules (BER),
+                Canonical Encoding Rules (CER) and Distinguished
+                Encoding Rules (DER)
+                RFC 5280: Internet X.509 Public Key Infrastructure
+                Certificate and Certificate Revocation List (CRL)
+                Profile
+                RFC 8446: The Transport Layer Security (TLS)
+                Protocol Version 1.3";
+           }
+         }
+       }
+     }
+   }
+   <CODE ENDS>
+
+                 Figure 9: YANG Module for Voucher-Request
+
+4.  Proxying Details (Pledge -- Proxy -- Registrar)
+
+   This section is normative for uses with an ANIMA ACP.  The use of the
+   GRASP mechanism is part of the ACP.  Other users of BRSKI will need
+   to define an equivalent proxy mechanism and an equivalent mechanism
+   to configure the proxy.
+
+   The role of the proxy is to facilitate communications.  The proxy
+   forwards packets between the pledge and a registrar that has been
+   provisioned to the proxy via full GRASP ACP discovery.
+
+   This section defines a stateful proxy mechanism that is referred to
+   as a "circuit" proxy.  This is a form of Application Level Gateway
+   (see [RFC2663], Section 2.9).
+
+   The proxy does not terminate the TLS handshake: it passes streams of
+   bytes onward without examination.  A proxy MUST NOT assume any
+   specific TLS version.  Please see [RFC8446], Section 9.3 for details
+   on TLS invariants.
+
+   A registrar can directly provide the proxy announcements described
+   below, in which case the announced port can point directly to the
+   registrar itself.  In this scenario, the pledge is unaware that there
+   is no proxying occurring.  This is useful for registrars that are
+   servicing pledges on directly connected networks.
+
+   As a result of the proxy discovery process in Section 4.1.1, the port
+   number exposed by the proxy does not need to be well known or require
+   an IANA allocation.
+
+   During the discovery of the registrar by the Join Proxy, the Join
+   Proxy will also learn which kinds of proxy mechanisms are available.
+   This will allow the Join Proxy to use the lowest impact mechanism
+   that the Join Proxy and registrar have in common.
+
+   In order to permit the proxy functionality to be implemented on the
+   maximum variety of devices, the chosen mechanism should use the
+   minimum amount of state on the proxy device.  While many devices in
+   the ANIMA target space will be rather large routers, the proxy
+   function is likely to be implemented in the control-plane CPU of such
+   a device, with available capabilities for the proxy function similar
+   to many class 2 IoT devices.
+
+   The document [ANIMA-STATE] provides a more extensive analysis and
+   background of the alternative proxy methods.
+
+4.1.  Pledge Discovery of Proxy
+
+   The result of discovery is a logical communication with a registrar,
+   through a proxy.  The proxy is transparent to the pledge.  The
+   communication between the pledge and Join Proxy is over IPv6 link-
+   local addresses.
+
+   To discover the proxy, the pledge performs the following actions:
+
+   1.  MUST: Obtain a local address using IPv6 methods as described in
+       "IPv6 Stateless Address Autoconfiguration" [RFC4862].  Use of
+       temporary addresses [RFC8981] is encouraged.  To limit pervasive
+       monitoring [RFC7258], a new temporary address MAY use a short
+       lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short).
+       Pledges will generally prefer use of IPv6 link-local addresses,
+       and discovery of the proxy will be by link-local mechanisms.
+       IPv4 methods are described in Appendix A.
+
+   2.  MUST: Listen for GRASP M_FLOOD [RFC8990] announcements of the
+       objective: "AN_Proxy".  See Section 4.1.1 for the details of the
+       objective.  The pledge MAY listen concurrently for other sources
+       of information; see Appendix B.
+
+   Once a proxy is discovered, the pledge communicates with a registrar
+   through the proxy using the bootstrapping protocol defined in
+   Section 5.
+
+   While the GRASP M_FLOOD mechanism is passive for the pledge, the non-
+   normative other methods (mDNS and IPv4 methods) described in
+   Appendix B are active.  The pledge SHOULD run those methods in
+   parallel with listening for the M_FLOOD.  The active methods SHOULD
+   back off by doubling to a maximum of one hour to avoid overloading
+   the network with discovery attempts.  Detection of physical link
+   status change (Ethernet carrier, for instance) SHOULD reset the back-
+   off timers.
+
+   The pledge could discover more than one proxy on a given physical
+   interface.  The pledge can have a multitude of physical interfaces as
+   well: a Layer 2/3 Ethernet switch may have hundreds of physical
+   ports.
+
+   Each possible proxy offer SHOULD be attempted up to the point where a
+   valid voucher is received: while there are many ways in which the
+   attempt may fail, it does not succeed until the voucher has been
+   validated.
+
+   The connection attempts via a single proxy SHOULD exponentially back
+   off to a maximum of one hour to avoid overloading the network
+   infrastructure.  The back-off timer for each MUST be independent of
+   other connection attempts.
+
+   Connection attempts SHOULD be run in parallel to avoid head-of-queue
+   problems wherein an attacker running a fake proxy or registrar could
+   intentionally perform protocol actions slowly.  Connection attempts
+   to different proxies SHOULD be sent with an interval of 3 to 5s.  The
+   pledge SHOULD continue to listen for additional GRASP M_FLOOD
+   messages during the connection attempts.
+
+   Each connection attempt through a distinct Join Proxy MUST have a
+   unique nonce in the voucher-request.
+
+   Once a connection to a registrar is established (e.g., establishment
+   of a TLS session key), there are expectations of more timely
+   responses; see Section 5.2.
+
+   Once all discovered services are attempted (assuming that none
+   succeeded), the device MUST return to listening for GRASP M_FLOOD.
+   It SHOULD periodically retry any manufacturer-specific mechanisms.
+   The pledge MAY prioritize selection order as appropriate for the
+   anticipated environment.
+
+4.1.1.  Proxy GRASP Announcements
+
+   A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself.
+   This announcement can be within the same message as the ACP
+   announcement detailed in [RFC8994].
+
+   The formal Concise Data Definition Language (CDDL) [RFC8610]
+   definition is:
+
+   <CODE BEGINS> file "proxygrasp.cddl"
+   flood-message = [M_FLOOD, session-id, initiator, ttl,
+                    +[objective, (locator-option / [])]]
+
+   objective = ["AN_Proxy", objective-flags, loop-count,
+                                          objective-value]
+
+   ttl             = 180000     ; 180,000 ms (3 minutes)
+   initiator = ACP address to contact registrar
+   objective-flags   = sync-only  ; as in the GRASP spec
+   sync-only         =  4         ; M_FLOOD only requires
+                                  ; synchronization
+   loop-count        =  1         ; one hop only
+   objective-value   =  any       ; none
+
+   locator-option    = [ O_IPv6_LOCATOR, ipv6-address,
+                       transport-proto, port-number ]
+   ipv6-address      = the v6 LL of the Proxy
+   $transport-proto /= IPPROTO_TCP   ; note that this can be any value
+                                    ; from the IANA protocol registry,
+                                    ; as per RFC 8990, Section 2.9.5.1,
+                                    ; Note 3.
+   port-number      = selected by Proxy
+   <CODE ENDS>
+
+           Figure 10: CDDL Definition of Proxy Discovery Message
+
+   Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port
+   4443.
+
+ [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
+             [["AN_Proxy", 4, 1, ""],
+              [O_IPv6_LOCATOR,
+               h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]]
+
+             Figure 11: Example of Proxy Discovery Message
+
+   On a small network, the registrar MAY include the GRASP M_FLOOD
+   announcements to locally connected networks.
+
+   The $transport-proto above indicates the method that the pledge-
+   proxy-registrar will use.  The TCP method described here is
+   mandatory, and other proxy methods, such as CoAP methods not defined
+   in this document, are optional.  Other methods MUST NOT be enabled
+   unless the Join Registrar ASA indicates support for them in its own
+   announcement.
+
+4.2.  CoAP Connection to Registrar
+
+   The use of CoAP to connect from pledge to registrar is out of scope
+   for this document and is described in future work.  See
+   [ANIMA-CONSTRAINED-VOUCHER].
+
+4.3.  Proxy Discovery and Communication of Registrar
+
+   The registrar SHOULD announce itself so that proxies can find it and
+   determine what kind of connections can be terminated.
+
+   The registrar announces itself using GRASP M_FLOOD messages, with the
+   "AN_join_registrar" objective, within the ACP instance.  A registrar
+   may announce any convenient port number, including use of stock port
+   443.  ANI proxies MUST support GRASP discovery of registrars.
+
+   The M_FLOOD is formatted as follows:
+
+ [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
+             [["AN_join_registrar", 4, 255, "EST-TLS"],
+              [O_IPv6_LOCATOR,
+               h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]]
+
+       Figure 12: An Example of a Registrar Announcement Message
+
+   The formal CDDL definition is:
+
+   <CODE BEGINS> file "jrcgrasp.cddl"
+   flood-message = [M_FLOOD, session-id, initiator, ttl,
+                    +[objective, (locator-option / [])]]
+
+   objective = ["AN_join_registrar", objective-flags, loop-count,
+                                          objective-value]
+
+   initiator = ACP address to contact registrar
+   objective-flags = sync-only  ; as in the GRASP spec
+   sync-only =  4               ; M_FLOOD only requires
+                                ; synchronization
+   loop-count      = 255        ; mandatory maximum
+   objective-value = text       ; name of the (list of) supported
+                                ; protocols: "EST-TLS" for RFC 7030.
+   <CODE ENDS>
+
+       Figure 13: CDDL Definition for Registrar Announcement Message
+
+   The M_FLOOD message MUST be sent periodically.  The default period
+   SHOULD be 60 seconds, and the value SHOULD be operator configurable
+   but SHOULD NOT be smaller than 60 seconds.  The frequency of sending
+   MUST be such that the aggregate amount of periodic M_FLOODs from all
+   flooding sources causes only negligible traffic across the ACP.
+
+   Here are some examples of locators for illustrative purposes.  Only
+   the first one ($transport-protocol = 6, TCP) is defined in this
+   document and is mandatory to implement.
+
+   locator1  = [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]
+   locator2  = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
+   locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
+
+   A protocol of 6 indicates that TCP proxying on the indicated port is
+   desired.
+
+   Registrars MUST announce the set of protocols that they support, and
+   they MUST support TCP traffic.
+
+   Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated.
+
+   Registrars MUST support the ANI TLS Circuit Proxy and therefore BRSKI
+   across HTTPS/TLS native across the ACP.
+
+   In the ANI, the ACP-secured instance of GRASP [RFC8990] MUST be used
+   for discovery of ANI registrar ACP addresses and ports by ANI
+   proxies.  Therefore, the TCP leg of the proxy connection between the
+   ANI proxy and ANI registrar also runs across the ACP.
+
+5.  Protocol Details (Pledge -- Registrar -- MASA)
+
+   The pledge MUST initiate BRSKI after boot if it is unconfigured.  The
+   pledge MUST NOT automatically initiate BRSKI if it has been
+   configured or is in the process of being configured.
+
+   BRSKI is described as extensions to EST [RFC7030].  The goal of these
+   extensions is to reduce the number of TLS connections and crypto
+   operations required on the pledge.  The registrar implements the
+   BRSKI REST interface within the "/.well-known/brski" URI tree and
+   implements the existing EST URIs as described in EST [RFC7030],
+   Section 3.2.2.  The communication channel between the pledge and the
+   registrar is referred to as "BRSKI-EST" (see Figure 1).
+
+   The communication channel between the registrar and MASA is a new
+   communication channel, similar to EST, within the newly registered
+   "/.well-known/brski" tree.  For clarity, this channel is referred to
+   as "BRSKI-MASA" (see Figure 1).
+
+   The MASA URI is "https://" authority "/.well-known/brski".
+
+   BRSKI uses existing CMS message formats for existing EST operations.
+   BRSKI uses JSON [RFC8259] for all new operations defined here and for
+   voucher formats.  In all places where a binary value must be carried
+   in a JSON string, a base64 format ([RFC4648], Section 4) is to be
+   used, as per [RFC7951], Section 6.6.
+
+   While EST ([RFC7030], Section 3.2) does not insist upon use of HTTP
+   persistent connections ([RFC7230], Section 6.3), BRSKI-EST
+   connections SHOULD use persistent connections.  The intention of this
+   guidance is to ensure the provisional TLS state occurs only once, and
+   that the subsequent resolution of the provision state is not subject
+   to a Man-in-the-Middle (MITM) attack during a critical phase.
+
+   If non-persistent connections are used, then both the pledge and the
+   registrar MUST remember the certificates that have been seen and also
+   sent for the first connection.  They MUST check each subsequent
+   connection for the same certificates, and each end MUST use the same
+   certificates as well.  This places a difficult restriction on rolling
+   certificates on the registrar.
+
+   Summarized automation extensions for the BRSKI-EST flow are:
+
+   *  The pledge either attempts concurrent connections via each
+      discovered proxy or times out quickly and tries connections in
+      series, as explained at the end of Section 5.1.
+
+   *  The pledge provisionally accepts the registrar certificate during
+      the TLS handshake as detailed in Section 5.1.
+
+   *  The pledge requests a voucher using the new REST calls described
+      below.  This voucher is then validated.
+
+   *  The pledge completes authentication of the server certificate as
+      detailed in Section 5.6.1.  This moves the BRSKI-EST TLS
+      connection out of the provisional state.
+
+   *  Mandatory bootstrap steps conclude with voucher status telemetry
+      (see Section 5.7).
+
+   The BRSKI-EST TLS connection can now be used for EST enrollment.
+
+   The extensions for a registrar (equivalent to an EST server) are:
+
+   *  Client authentication is automated using IDevID as per the EST
+      certificate-based client authentication.  The subject field's DN
+      encoding MUST include the "serialNumber" attribute with the
+      device's unique serial number as explained in Section 2.3.1.
+
+   *  The registrar requests and validates the voucher from the MASA.
+
+   *  The registrar forwards the voucher to the pledge when requested.
+
+   *  The registrar performs log verifications (described in
+      Section 5.8.3) in addition to local authorization checks before
+      accepting optional pledge device enrollment requests.
+
+5.1.  BRSKI-EST TLS Establishment Details
+
+   The pledge establishes the TLS connection with the registrar through
+   the Circuit Proxy (see Section 4), but the TLS handshake is with the
+   registrar.  The BRSKI-EST pledge is the TLS client, and the BRSKI-EST
+   registrar is the TLS server.  All security associations established
+   are between the pledge and the registrar regardless of proxy
+   operations.
+
+   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
+   REQUIRED on the pledge side.  TLS 1.3 (or newer) SHOULD be available
+   on the registrar server interface, and the registrar client
+   interface, but TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be
+   available on the MASA server interface, but TLS 1.2 MAY be used.
+
+   Establishment of the BRSKI-EST TLS connection is as specified in
+   "Bootstrap Distribution of CA Certificates" (Section 4.1.1) of
+   [RFC7030], wherein the client is authenticated with the IDevID
+   certificate, and the EST server (the registrar) is provisionally
+   authenticated with an unverified server certificate.  Configuration
+   or distribution of the trust anchor database used for validating the
+   IDevID certificate is out of scope of this specification.  Note that
+   the trust anchors in / excluded from the database will affect which
+   manufacturers' devices are acceptable to the registrar as pledges and
+   can also be used to limit the set of MASAs that are trusted for
+   enrollment.
+
+   The signature in the certificate MUST be validated even if a signing
+   key cannot (yet) be validated.  The certificate (or chain) MUST be
+   retained for later validation.
+
+   A self-signed certificate for the registrar is acceptable as the
+   voucher can validate it upon successful enrollment.
+
+   The pledge performs input validation of all data received until a
+   voucher is verified as specified in Section 5.6.1 and the TLS
+   connection leaves the provisional state.  Until these operations are
+   complete, the pledge could be communicating with an attacker.
+
+   The pledge code needs to be written with the assumption that all data
+   is being transmitted at this point to an unauthenticated peer, and
+   that received data, while inside a TLS connection, MUST be considered
+   untrusted.  This particularly applies to HTTP headers and CMS
+   structures that make up the voucher.
+
+   A pledge that can connect to multiple registrars concurrently SHOULD
+   do so.  Some devices may be unable to do so for lack of threading, or
+   resource issues.  Concurrent connections defeat attempts by a
+   malicious proxy from causing a TCP Slowloris-like attack (see
+   [slowloris]).
+
+   A pledge that cannot maintain as many connections as there are
+   eligible proxies will need to rotate among the various choices,
+   terminating connections that do not appear to be making progress.  If
+   no connection is making progress after 5 seconds, then the pledge
+   SHOULD drop the oldest connection and go on to a different proxy: the
+   proxy that has been communicated with least recently.  If there were
+   no other proxies discovered, the pledge MAY continue to wait, as long
+   as it is concurrently listening for new proxy announcements.
+
+5.2.  Pledge Requests Voucher from the Registrar
+
+   When the pledge bootstraps, it makes a request for a voucher from a
+   registrar.
+
+   This is done with an HTTPS POST using the operation path value of
+   "/.well-known/brski/requestvoucher".
+
+   The pledge voucher-request Content-Type is as follows.
+
+   application/voucher-cms+json:  [RFC8366] defines a "YANG-defined JSON
+      document that has been signed using a Cryptographic Message Syntax
+      (CMS) structure", and the voucher-request described in Section 3
+      is created in the same way.  The media type is the same as defined
+      in [RFC8366].  This is also used for the pledge voucher-request.
+      The pledge MUST sign the request using the credentials in
+      Section 2.3.
+
+   Registrar implementations SHOULD anticipate future media types but,
+   of course, will simply fail the request if those types are not yet
+   known.
+
+   The pledge SHOULD include an "Accept" header field (see [RFC7231],
+   Section 5.3.2) indicating the acceptable media type for the voucher
+   response.  The "application/voucher-cms+json" media type is defined
+   in [RFC8366], but constrained voucher formats are expected in the
+   future.  Registrars and MASA are expected to be flexible in what they
+   accept.
+
+   The pledge populates the voucher-request fields as follows:
+
+   created-on:  Pledges that have a real-time clock are RECOMMENDED to
+      populate this field with the current date and time in yang:date-
+      and-time format.  This provides additional information to the
+      MASA.  Pledges that have no real-time clocks MAY omit this field.
+
+   nonce:  The pledge voucher-request MUST contain a cryptographically
+      strong random or pseudo-random number nonce (see [RFC4086],
+      Section 6.2).  As the nonce is usually generated very early in the
+      boot sequence, there is a concern that the same nonce might be
+      generated across multiple boots, or after a factory reset.
+      Different nonces MUST be generated for each bootstrapping attempt,
+      whether in series or concurrently.  The freshness of this nonce
+      mitigates against the lack of a real-time clock as explained in
+      Section 2.6.1.
+
+   assertion:  The pledge indicates support for the mechanism described
+      in this document, by putting the value "proximity" in the voucher-
+      request, and MUST include the proximity-registrar-cert field
+      (below).
+
+   proximity-registrar-cert:  In a pledge voucher-request, this is the
+      first certificate in the TLS server "certificate_list" sequence
+      (see [RFC8446], Section 4.4.2) presented by the registrar to the
+      pledge.  That is, it is the end-entity certificate.  This MUST be
+      populated in a pledge voucher-request.
+
+   serial-number:  The serial number of the pledge is included in the
+      voucher-request from the pledge.  This value is included as a
+      sanity check only, but it is not to be forwarded by the registrar
+      as described in Section 5.5.
+
+   All other fields MAY be omitted in the pledge voucher-request.
+
+   See an example JSON payload of a pledge voucher-request in
+   Section 3.3, Example 1.
+
+   The registrar confirms that the assertion is "proximity" and that
+   pinned proximity-registrar-cert is the registrar's certificate.  If
+   this validation fails, then there is an on-path attacker (MITM), and
+   the connection MUST be closed after the returning of an HTTP 401
+   error code.
+
+5.3.  Registrar Authorization of Pledge
+
+   In a fully automated network, all devices must be securely identified
+   and authorized to join the domain.
+
+   A registrar accepts or declines a request to join the domain, based
+   on the authenticated identity presented.  For different networks,
+   examples of automated acceptance may include the allowance of:
+
+   *  any device of a specific type (as determined by the X.509 IDevID),
+
+   *  any device from a specific vendor (as determined by the X.509
+      IDevID),
+
+   *  a specific device from a vendor (as determined by the X.509
+      IDevID) against a domain acceptlist.  (The mechanism for checking
+      a shared acceptlist potentially used by multiple registrars is out
+      of scope.)
+
+   If validation fails, the registrar SHOULD respond with the HTTP 404
+   error code.  If the voucher-request is in an unknown format, then an
+   HTTP 406 error code is more appropriate.  A situation that could be
+   resolved with administrative action (such as adding a vendor to an
+   acceptlist) MAY be responded to with a 403 HTTP error code.
+
+   If authorization is successful, the registrar obtains a voucher from
+   the MASA service (see Section 5.5) and returns that MASA-signed
+   voucher to the pledge as described in Section 5.6.
+
+5.4.  BRSKI-MASA TLS Establishment Details
+
+   The BRSKI-MASA TLS connection is a "normal" TLS connection
+   appropriate for HTTPS REST interfaces.  The registrar initiates the
+   connection and uses the MASA URL that is obtained as described in
+   Section 2.8.  The mechanisms in [RFC6125] SHOULD be used in
+   authentication of the MASA using a DNS-ID that matches that which is
+   found in the IDevID.  Registrars MAY include a mechanism to override
+   the MASA URL on a manufacturer-by-manufacturer basis, and within that
+   override, it is appropriate to provide alternate anchors.  This will
+   typically be used by some vendors to establish explicit (or private)
+   trust anchors for validating their MASA that is part of a sales
+   channel integration.
+
+   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
+   REQUIRED.  TLS 1.3 (or newer) SHOULD be available.
+
+   As described in [RFC7030], the MASA and the registrars SHOULD be
+   prepared to support TLS Client Certificate authentication and/or HTTP
+   Basic, Digest, or Salted Challenge Response Authentication Mechanism
+   (SCRAM) authentication.  This connection MAY also have no client
+   authentication at all.
+
+   Registrars SHOULD permit trust anchors to be preconfigured on a per-
+   vendor (MASA) basis.  Registrars SHOULD include the ability to
+   configure a TLS Client Certificate on a per-MASA basis, or to use no
+   Client Certificate.  Registrars SHOULD also permit HTTP Basic and
+   Digest authentication to be configured.
+
+   The authentication of the BRSKI-MASA connection does not change the
+   voucher-request process, as voucher-requests are already signed by
+   the registrar.  Instead, this authentication provides access control
+   to the audit-log as described in Section 5.8.
+
+   Implementers are advised that contacting the MASA establishes a
+   secured API connection with a web service, and that there are a
+   number of authentication models being explored within the industry.
+   Registrars are RECOMMENDED to fail gracefully and generate useful
+   administrative notifications or logs in the advent of unexpected HTTP
+   401 (Unauthorized) responses from the MASA.
+
+5.4.1.  MASA Authentication of Customer Registrar
+
+   Providing per-customer options requires the customer's registrar to
+   be uniquely identified.  This can be done by any stateless method
+   that HTTPS supports such as HTTP Basic or Digest authentication (that
+   is using a password), but the use of TLS Client Certificate
+   authentication is RECOMMENDED.
+
+   Stateful methods involving API tokens, or HTTP Cookies, are not
+   recommended.
+
+   It is expected that the setup and configuration of per-customer
+   Client Certificates is done as part of a sales ordering process.
+
+   The use of public PKI (i.e., WebPKI) end-entity certificates to
+   identify the registrar is reasonable, and if done universally, this
+   would permit a MASA to identify a customer's registrar simply by a
+   Fully Qualified Domain Name (FQDN).
+
+   The use of DANE records in DNSSEC-signed zones would also permit use
+   of a FQDN to identify customer registrars.
+
+   A third (and simplest, but least flexible) mechanism would be for the
+   MASA to simply store the registrar's certificate pinned in a
+   database.
+
+   A MASA without any supply-chain integration can simply accept
+   registrars without any authentication or on a blind TOFU basis as
+   described in Section 7.4.2.
+
+   This document does not make a specific recommendation on how the MASA
+   authenticates the registrar as there are likely different tradeoffs
+   in different environments and product values.  Even within the ANIMA
+   ACP applicability, there is a significant difference between supply-
+   chain logistics for $100 CPE devices and $100,000 core routers.
+
+5.5.  Registrar Requests Voucher from MASA
+
+   When a registrar receives a pledge voucher-request, it in turn
+   submits a registrar voucher-request to the MASA service via an HTTPS
+   interface [RFC7231].
+
+   This is done with an HTTP POST using the operation path value of
+   "/.well-known/brski/requestvoucher".
+
+   The voucher media type "application/voucher-cms+json" is defined in
+   [RFC8366] and is also used for the registrar voucher-request.  It is
+   a JSON document that has been signed using a CMS structure.  The
+   registrar MUST sign the registrar voucher-request.
+
+   MASA implementations SHOULD anticipate future media ntypes but, of
+   course, will simply fail the request if those types are not yet
+   known.
+
+   The voucher-request CMS object includes some number of certificates
+   that are input to the MASA as it populates the pinned-domain-cert.
+   As [RFC8366] is quite flexible in what may be put into the pinned-
+   domain-cert, the MASA needs some signal as to what certificate would
+   be effective to populate the field with: it may range from the end-
+   entity certificate that the registrar uses to the entire private
+   Enterprise CA certificate.  More-specific certificates result in a
+   tighter binding of the voucher to the domain, while less-specific
+   certificates result in more flexibility in how the domain is
+   represented by certificates.
+
+   A registrar that is seeking a nonceless voucher for later offline use
+   benefits from a less-specific certificate, as it permits the actual
+   key pair used by a future registrar to be determined by the pinned
+   CA.
+
+   In some cases, a less-specific certificate, such as a public WebPKI
+   CA, could be too open and could permit any entity issued a
+   certificate by that authority to assume ownership of a device that
+   has a voucher pinned.  Future work may provide a solution to pin both
+   a certificate and a name that would reduce such risk of malicious
+   ownership assertions.
+
+   The registrar SHOULD request a voucher with the most specificity
+   consistent with the mode that it is operating in.  In order to do
+   this, when the registrar prepares the CMS structure for the signed
+   voucher-request, it SHOULD include only certificates that are a part
+   of the chain that it wishes the MASA to pin.  This MAY be as small as
+   only the end-entity certificate (with id-kp-cmcRA set) that it uses
+   as its TLS server certificate, or it MAY be the entire chain,
+   including the domain CA.
+
+   The registrar SHOULD include an "Accept" header field (see [RFC7231],
+   Section 5.3.2) indicating the response media types that are
+   acceptable.  This list SHOULD be the entire list presented to the
+   registrar in the pledge's original request (see Section 5.2), but it
+   MAY be a subset.  The MASA is expected to be flexible in what it
+   accepts.
+
+   The registrar populates the voucher-request fields as follows:
+
+   created-on:  The registrar SHOULD populate this field with the
+      current date and time when the voucher-request is formed.  This
+      field provides additional information to the MASA.
+
+   nonce:  This value, if present, is copied from the pledge voucher-
+      request.  The registrar voucher-request MAY omit the nonce as per
+      Section 3.1.
+
+   serial-number:  The serial number of the pledge the registrar would
+      like a voucher for.  The registrar determines this value by
+      parsing the authenticated pledge IDevID certificate; see
+      Section 2.3.  The registrar MUST verify that the serial-number
+      field it parsed matches the serial-number field the pledge
+      provided in its voucher-request.  This provides a sanity check
+      useful for detecting error conditions and logging.  The registrar
+      MUST NOT simply copy the serial-number field from a pledge
+      voucher-request as that field is claimed but not certified.
+
+   idevid-issuer:  The Issuer value from the pledge IDevID certificate
+      is included to ensure unique interpretation of the serial-number.
+      In the case of a nonceless (offline) voucher-request, an
+      appropriate value needs to be configured from the same out-of-band
+      source as the serial-number.
+
+   prior-signed-voucher-request:  The signed pledge voucher-request
+      SHOULD be included in the registrar voucher-request.  The entire
+      CMS-signed structure is to be included and base64 encoded for
+      transport in the JSON structure.
+
+   A nonceless registrar voucher-request MAY be submitted to the MASA.
+   Doing so allows the registrar to request a voucher when the pledge is
+   offline, or when the registrar anticipates not being able to connect
+   to the MASA while the pledge is being deployed.  Some use cases
+   require the registrar to learn the appropriate IDevID serialNumber
+   field and appropriate "Accept" header field values from the physical
+   device labeling or from the sales channel (which is out of scope for
+   this document).
+
+   All other fields MAY be omitted in the registrar voucher-request.
+
+   The proximity-registrar-cert field MUST NOT be present in the
+   registrar voucher-request.
+
+   See example JSON payloads of registrar voucher-requests in
+   Section 3.3, Examples 2 through 4.
+
+   The MASA verifies that the registrar voucher-request is internally
+   consistent but does not necessarily authenticate the registrar
+   certificate since the registrar MAY be unknown to the MASA in
+   advance.  The MASA performs the actions and validation checks
+   described in the following subsections before issuing a voucher.
+
+5.5.1.  MASA Renewal of Expired Vouchers
+
+   As described in [RFC8366], vouchers are normally short lived to avoid
+   revocation issues.  If the request is for a previous (expired)
+   voucher using the same registrar (that is, a registrar with the same
+   domain CA), then the request for a renewed voucher SHOULD be
+   automatically authorized.  The MASA has sufficient information to
+   determine this by examining the request, the registrar
+   authentication, and the existing audit-log.  The issuance of a
+   renewed voucher is logged as detailed in Section 5.6.
+
+   To inform the MASA that existing vouchers are not to be renewed, one
+   can update or revoke the registrar credentials used to authorize the
+   request (see Sections 5.5.4 and 5.5.3).  More flexible methods will
+   likely involve sales channel integration and authorizations (details
+   are out of scope of this document).
+
+5.5.2.  MASA Pinning of Registrar
+
+   A certificate chain is extracted from the registrar's signed CMS
+   container.  This chain may be as short as a single end-entity
+   certificate, up to the entire registrar certificate chain, including
+   the domain CA certificate, as specified in Section 5.5.
+
+   If the domain's CA is unknown to the MASA, then it is considered a
+   temporary trust anchor for the rest of the steps in this section.
+   The intention is not to authenticate the message as having come from
+   a fully validated origin but to establish the consistency of the
+   domain PKI.
+
+   The MASA MAY use the certificate in the chain that is farthest from
+   the end-entity certificate of the registrar, as determined by MASA
+   policy.  A MASA MAY have a local policy in which it only pins the
+   end-entity certificate.  This is consistent with [RFC8366].  Details
+   of the policy will typically depend upon the degree of supply-chain
+   integration and the mechanism used by the registrar to authenticate.
+   Such a policy would also determine how the MASA will respond to a
+   request for a nonceless voucher.
+
+5.5.3.  MASA Check of the Voucher-Request Signature
+
+   As described in Section 5.5.2, the MASA has extracted the registrar's
+   domain CA.  This is used to validate the CMS signature [RFC5652] on
+   the voucher-request.
+
+   Normal PKIX revocation checking is assumed during voucher-request
+   signature validation.  This CA certificate MAY have Certificate
+   Revocation List (CRL) distribution points or Online Certificate
+   Status Protocol (OCSP) information [RFC6960].  If they are present,
+   the MASA MUST be able to reach the relevant servers belonging to the
+   registrar's domain CA to perform the revocation checks.
+
+   The use of OCSP Stapling is preferred.
+
+5.5.4.  MASA Verification of the Domain Registrar
+
+   The MASA MUST verify that the registrar voucher-request is signed by
+   a registrar.  This is confirmed by verifying that the id-kp-cmcRA
+   extended key usage extension field (as detailed in EST [RFC7030],
+   Section 3.6.1) exists in the certificate of the entity that signed
+   the registrar voucher-request.  This verification is only a
+   consistency check to ensure that the unauthenticated domain CA
+   intended the voucher-request signer to be a registrar.  Performing
+   this check provides value to the domain PKI by assuring the domain
+   administrator that the MASA service will only respect claims from
+   authorized registration authorities of the domain.
+
+   Even when a domain CA is authenticated to the MASA, and there is
+   strong sales channel integration to understand who the legitimate
+   owner is, the above id-kp-cmcRA check prevents arbitrary end-entity
+   certificates (such as an LDevID certificate) from having vouchers
+   issued against them.
+
+   Other cases of inappropriate voucher issuance are detected by
+   examination of the audit-log.
+
+   If a nonceless voucher-request is submitted, the MASA MUST
+   authenticate the registrar either as described in EST (see Sections
+   3.2.3 and 3.3.2 of [RFC7030]) or by validating the registrar's
+   certificate used to sign the registrar voucher-request using a
+   configured trust anchor.  Any of these methods reduce the risk of
+   DDoS attacks and provide an authenticated identity as an input to
+   sales channel integration and authorizations (details are out of
+   scope of this document).
+
+   In the nonced case, validation of the registrar's identity (via TLS
+   Client Certificate or HTTP authentication) MAY be omitted if the MASA
+   knows that the device policy is to accept audit-only vouchers.
+
+5.5.5.  MASA Verification of the Pledge 'prior-signed-voucher-request'
+
+   The MASA MAY verify that the registrar voucher-request includes the
+   prior-signed-voucher-request field.  If so, the prior-signed-voucher-
+   request MUST include a proximity-registrar-cert that is consistent
+   with the certificate used to sign the registrar voucher-request.
+   Additionally, the voucher-request serial-number leaf MUST match the
+   pledge serial-number that the MASA extracts from the signing
+   certificate of the prior-signed-voucher-request.  The consistency
+   check described above entails checking that the proximity-registrar-
+   cert Subject Public Key Info (SPKI) Fingerprint exists within the
+   registrar voucher-request CMS signature's certificate chain.  This is
+   substantially the same as the pin validation described in [RFC7469],
+   Section 2.6.
+
+   If these checks succeed, the MASA updates the voucher and audit-log
+   assertion leafs with the "proximity" assertion, as defined by
+   [RFC8366], Section 5.3.
+
+5.5.6.  MASA Nonce Handling
+
+   The MASA does not verify the nonce itself.  If the registrar voucher-
+   request contains a nonce, and the prior-signed-voucher-request
+   exists, then the MASA MUST verify that the nonce is consistent.
+   (Recall from above that the voucher-request might not contain a
+   nonce; see Sections 5.5 and 5.5.4.)
+
+   The MASA populates the audit-log with the nonce that was verified.
+   If a nonceless voucher is issued, then the audit-log is to be
+   populated with the JSON value "null".
+
+5.6.  MASA and Registrar Voucher Response
+
+   The MASA voucher response to the registrar is forwarded without
+   changes to the pledge; therefore, this section applies to both the
+   MASA and the registrar.  The HTTP signaling described applies to both
+   the MASA and registrar responses.
+
+   When a voucher-request arrives at the registrar, if it has a cached
+   response from the MASA for the corresponding registrar voucher-
+   request, that cached response can be used according to local policy;
+   otherwise, the registrar constructs a new registrar voucher-request
+   and sends it to the MASA.
+
+   Registrar evaluation of the voucher itself is purely for transparency
+   and audit purposes to further inform log verification (see
+   Section 5.8.3); therefore, a registrar could accept future voucher
+   formats that are opaque to the registrar.
+
+   If the voucher-request is successful, the server (a MASA responding
+   to a registrar or a registrar responding to a pledge) response MUST
+   contain an HTTP 200 response code.  The server MUST answer with a
+   suitable 4xx or 5xx HTTP [RFC7230] error code when a problem occurs.
+   In this case, the response data from the MASA MUST be a plain text
+   human-readable (UTF-8) error message containing explanatory
+   information describing why the request was rejected.
+
+   The registrar MAY respond with an HTTP 202 ("the request has been
+   accepted for processing, but the processing has not been completed")
+   as described in EST [RFC7030], Section 4.2.3, wherein the client
+   "MUST wait at least the specified "retry-after" time before repeating
+   the same request" (also see [RFC7231], Section 6.6.4).  The pledge is
+   RECOMMENDED to provide local feedback (blinked LED, etc.) during this
+   wait cycle if mechanisms for this are available.  To prevent an
+   attacker registrar from significantly delaying bootstrapping, the
+   pledge MUST limit the Retry-After time to 60 seconds.  Ideally, the
+   pledge would keep track of the appropriate Retry-After header field
+   values for any number of outstanding registrars, but this would
+   involve a state table on the pledge.  Instead, the pledge MAY ignore
+   the exact Retry-After value in favor of a single hard-coded value (a
+   registrar that is unable to complete the transaction after the first
+   60 seconds has another chance a minute later).  A pledge SHOULD be
+   willing to maintain a 202 retry-state for up to 4 days, which is
+   longer than a long weekend, after which time the enrollment attempt
+   fails, and the pledge returns to Discovery state.  This allows time
+   for an alert to get from the registrar to a human operator who can
+   make a decision as to whether or not to proceed with the enrollment.
+
+   A pledge that retries a request after receiving a 202 message MUST
+   resend the same voucher-request.  It MUST NOT sign a new voucher-
+   request each time, and in particular, it MUST NOT change the nonce
+   value.
+
+   In order to avoid infinite redirect loops, which a malicious
+   registrar might do in order to keep the pledge from discovering the
+   correct registrar, the pledge MUST NOT follow more than one
+   redirection (3xx code) to another web origin.  EST supports
+   redirection but requires user input; this change allows the pledge to
+   follow a single redirection without a user interaction.
+
+   A 403 (Forbidden) response is appropriate if the voucher-request is
+   not signed correctly or is stale or if the pledge has another
+   outstanding voucher that cannot be overridden.
+
+   A 404 (Not Found) response is appropriate when the request is for a
+   device that is not known to the MASA.
+
+   A 406 (Not Acceptable) response is appropriate if a voucher of the
+   desired type or that uses the desired algorithms (as indicated by the
+   "Accept" header fields and algorithms used in the signature) cannot
+   be issued as such because the MASA knows the pledge cannot process
+   that type.  The registrar SHOULD use this response if it determines
+   the pledge is unacceptable due to inventory control, MASA audit-logs,
+   or any other reason.
+
+   A 415 (Unsupported Media Type) response is appropriate for a request
+   that has a voucher-request or "Accept" value that is not understood.
+
+   The voucher response format is as indicated in the submitted "Accept"
+   header fields or based on the MASA's prior understanding of proper
+   format for this pledge.  Only the "application/voucher-cms+json"
+   media type [RFC8366] is defined at this time.  The syntactic details
+   of vouchers are described in detail in [RFC8366].  Figure 14 shows a
+   sample of the contents of a voucher.
+
+   {
+     "ietf-voucher:voucher": {
+       "nonce": "62a2e7693d82fcda2624de58fb6722e5",
+       "assertion": "logged",
+       "pinned-domain-cert": "base64encodedvalue==",
+       "serial-number": "JADA123456789"
+     }
+   }
+
+                       Figure 14: An Example Voucher
+
+   The MASA populates the voucher fields as follows:
+
+   nonce:  The nonce from the pledge if available.  See Section 5.5.6.
+
+   assertion:  The method used to verify the relationship between the
+      pledge and registrar.  See Section 5.5.5.
+
+   pinned-domain-cert:  A certificate; see Section 5.5.2.  This figure
+      is illustrative; for an example, see Appendix C.2 where an end-
+      entity certificate is used.
+
+   serial-number:  The serial-number as provided in the voucher-request.
+      Also see Section 5.5.5.
+
+   domain-cert-revocation-checks:  Set as appropriate for the pledge's
+      capabilities and as documented in [RFC8366].  The MASA MAY set
+      this field to "false" since setting it to "true" would require
+      that revocation information be available to the pledge, and this
+      document does not make normative requirements for [RFC6961],
+      Section 4.4.2.1 of [RFC8446], or equivalent integrations.
+
+   expires-on:  This is set for nonceless vouchers.  The MASA ensures
+      the voucher lifetime is consistent with any revocation or pinned-
+      domain-cert consistency checks the pledge might perform.  See
+      Section 2.6.1.  There are three times to consider: (a) a
+      configured voucher lifetime in the MASA, (b) the expiry time for
+      the registrar's certificate, and (c) any CRL lifetime.  The
+      expires-on field SHOULD be before the earliest of these three
+      values.  Typically, (b) will be some significant time in the
+      future, but (c) will typically be short (on the order of a week or
+      less).  The RECOMMENDED period for (a) is on the order of 20
+      minutes, so it will typically determine the life span of the
+      resulting voucher.  20 minutes is sufficient time to reach the
+      post-provisional state in the pledge, at which point there is an
+      established trust relationship between the pledge and registrar.
+      The subsequent operations can take as long as required from that
+      point onwards.  The lifetime of the voucher has no impact on the
+      life span of the ownership relationship.
+
+   Whenever a voucher is issued, the MASA MUST update the audit-log
+   sufficiently to generate the response as described in Section 5.8.1.
+   The internal state requirements to maintain the audit-log are out of
+   scope.
+
+5.6.1.  Pledge Voucher Verification
+
+   The pledge MUST verify the voucher signature using the manufacturer-
+   installed trust anchor(s) associated with the manufacturer's MASA
+   (this is likely included in the pledge's firmware).  Management of
+   the manufacturer-installed trust anchor(s) is out of scope of this
+   document; this protocol does not update this trust anchor(s).
+
+   The pledge MUST verify that the serial-number field of the signed
+   voucher matches the pledge's own serial-number.
+
+   The pledge MUST verify the nonce information in the voucher.  If
+   present, the nonce in the voucher must match the nonce the pledge
+   submitted to the registrar; vouchers with no nonce can also be
+   accepted (according to local policy; see Section 7.2).
+
+   The pledge MUST be prepared to parse and fail gracefully from a
+   voucher response that does not contain a pinned-domain-cert field.
+   Such a thing indicates a failure to enroll in this domain, and the
+   pledge MUST attempt joining with other available Join Proxies.
+
+   The pledge MUST be prepared to ignore additional fields that it does
+   not recognize.
+
+5.6.2.  Pledge Authentication of Provisional TLS Connection
+
+   Following the process described in [RFC8366], the pledge should
+   consider the public key from the pinned-domain-cert as the sole
+   temporary trust anchor.
+
+   The pledge then evaluates the TLS server certificate chain that it
+   received when the TLS connection was formed using this trust anchor.
+   It is possible that the public key in the pinned-domain-cert directly
+   matches the public key in the end-entity certificate provided by the
+   TLS server.
+
+   If a registrar's credentials cannot be verified using the pinned-
+   domain-cert trust anchor from the voucher, then the TLS connection is
+   discarded, and the pledge abandons attempts to bootstrap with this
+   discovered registrar.  The pledge SHOULD send voucher status
+   telemetry (described below) before closing the TLS connection.  The
+   pledge MUST attempt to enroll using any other proxies it has found.
+   It SHOULD return to the same proxy again after unsuccessful attempts
+   with other proxies.  Attempts should be made at repeated intervals
+   according to the back-off timer described earlier.  Attempts SHOULD
+   be repeated as failure may be the result of a temporary inconsistency
+   (an inconsistently rolled registrar key, or some other
+   misconfiguration).  The inconsistency could also be the result of an
+   active MITM attack on the EST connection.
+
+   The registrar MUST use a certificate that chains to the pinned-
+   domain-cert as its TLS server certificate.
+
+   The pledge's PKIX path validation of a registrar certificate's
+   validity period information is as described in Section 2.6.1.  Once
+   the PKIX path validation is successful, the TLS connection is no
+   longer provisional.
+
+   The pinned-domain-cert MAY be installed as a trust anchor for future
+   operations such as enrollment (e.g., as recommended per [RFC7030]) or
+   trust anchor management or raw protocols that do not need full PKI-
+   based key management.  It can be used to authenticate any dynamically
+   discovered EST server that contains the id-kp-cmcRA extended key
+   usage extension as detailed in EST (see [RFC7030], Section 3.6.1);
+   but to reduce system complexity, the pledge SHOULD avoid additional
+   discovery operations.  Instead, the pledge SHOULD communicate
+   directly with the registrar as the EST server.  The pinned-domain-
+   cert is not a complete distribution of the CA certificate response,
+   as described in [RFC7030], Section 4.1.3, which is an additional
+   justification for the recommendation to proceed with EST key
+   management operations.  Once a full CA certificate response is
+   obtained, it is more authoritative for the domain than the limited
+   pinned-domain-cert response.
+
+5.7.  Pledge BRSKI Status Telemetry
+
+   The domain is expected to provide indications to the system
+   administrators concerning device life-cycle status.  To facilitate
+   this, it needs telemetry information concerning the device's status.
+
+   The pledge MUST indicate its pledge status regarding the voucher.  It
+   does this by sending a status message to the registrar.
+
+   The posted data media type: application/json
+
+   The client sends an HTTP POST to the server at the URI ".well-
+   known/brski/voucher_status".
+
+   The format and semantics described below are for version 1.  A
+   version field is included to permit significant changes to this
+   feedback in the future.  A registrar that receives a status message
+   with a version larger than it knows about SHOULD log the contents and
+   alert a human.
+
+   The status field indicates if the voucher was acceptable.  Boolean
+   values are acceptable, where "true" indicates the voucher was
+   acceptable.
+
+   If the voucher was not acceptable, the Reason string indicates why.
+   In a failure case, this message may be sent to an unauthenticated,
+   potentially malicious registrar; therefore, the Reason string SHOULD
+   NOT provide information beneficial to an attacker.  The operational
+   benefit of this telemetry information is balanced against the
+   operational costs of not recording that a voucher was ignored by a
+   client that the registrar expected was going to continue joining the
+   domain.
+
+   The reason-context attribute is an arbitrary JSON object (literal
+   value or hash of values) that provides additional information
+   specific to this pledge.  The contents of this field are not subject
+   to standardization.
+
+   The version and status fields MUST be present.  The Reason field
+   SHOULD be present whenever the status field is false.  The Reason-
+   Context field is optional.  In the case of a SUCCESS, the Reason
+   string MAY be omitted.
+
+   The keys to this JSON object are case sensitive and MUST be
+   lowercase.  Figure 16 shows an example JSON.
+
+   <CODE BEGINS> file "voucherstatus.cddl"
+   voucherstatus-post = {
+       "version": uint,
+       "status": bool,
+       ? "reason": text,
+       ? "reason-context" : { $$arbitrary-map }
+     }
+   }
+   <CODE ENDS>
+
+                  Figure 15: CDDL for Voucher Status POST
+
+   {
+       "version": 1,
+       "status":false,
+       "reason":"Informative human-readable message",
+       "reason-context": { "additional" : "JSON" }
+   }
+
+                    Figure 16: Example Status Telemetry
+
+   The server SHOULD respond with an HTTP 200 but MAY simply fail with
+   an HTTP 404 error.  The client ignores any response.  The server
+   SHOULD capture this telemetry information within the server logs.
+
+   Additional standard JSON fields in this POST MAY be added; see
+   Section 8.5.  A server that sees unknown fields should log them, but
+   otherwise ignore them.
+
+5.8.  Registrar Audit-Log Request
+
+   After receiving the pledge status telemetry (see Section 5.7), the
+   registrar SHOULD request the MASA audit-log from the MASA service.
+
+   This is done with an HTTP POST using the operation path value of
+   "/.well-known/brski/requestauditlog".
+
+   The registrar SHOULD HTTP POST the same registrar voucher-request as
+   it did when requesting a voucher (using the same Content-Type).  It
+   is posted to the /requestauditlog URI instead.  The idevid-issuer and
+   serial-number informs the MASA which log is requested, so the
+   appropriate log can be prepared for the response.  Using the same
+   media type and message minimizes cryptographic and message
+   operations, although it results in additional network traffic.  The
+   relying MASA implementation MAY leverage internal state to associate
+   this request with the original, and by now already validated,
+   voucher-request so as to avoid an extra crypto validation.
+
+   A registrar MAY request logs at future times.  If the registrar
+   generates a new request, then the MASA is forced to perform the
+   additional cryptographic operations to verify the new request.
+
+   A MASA that receives a request for a device that does not exist, or
+   for which the requesting owner was never an owner, returns an HTTP
+   404 ("Not found") code.
+
+   It is reasonable for a registrar, that the MASA does not believe to
+   be the current owner, to request the audit-log.  There are probably
+   reasons for this, which are hard to predict in advance.  For
+   instance, such a registrar may not be aware that the device has been
+   resold; it may be that the device has been resold inappropriately,
+   and this is how the original owner will learn of the occurrence.  It
+   is also possible that the device legitimately spends time in two
+   different networks.
+
+   Rather than returning the audit-log as a response to the POST (with a
+   return code 200), the MASA MAY instead return a 201 ("Created")
+   response ([RFC7231], Sections 6.3.2 and 7.1), with the URL to the
+   prepared (and idempotent, therefore cachable) audit response in the
+   "Location" header field.
+
+   In order to avoid enumeration of device audit-logs, a MASA that
+   returns URLs SHOULD take care to make the returned URL unguessable.
+   [W3C.capability-urls] provides very good additional guidance.  For
+   instance, rather than returning URLs containing a database number
+   such as https://example.com/auditlog/1234 or the Extended Unique
+   Identifier (EUI) of the device such https://example.com/
+   auditlog/10-00-00-11-22-33, the MASA SHOULD return a randomly
+   generated value (a "slug" in web parlance).  The value is used to
+   find the relevant database entry.
+
+   A MASA that returns a code 200 MAY also include a "Location" header
+   for future reference by the registrar.
+
+5.8.1.  MASA Audit-Log Response
+
+   A log data file is returned consisting of all log entries associated
+   with the device selected by the IDevID presented in the request.  The
+   audit-log may be abridged by removal of old or repeated values as
+   explained below.  The returned data is in JSON format [RFC8259], and
+   the Content-Type SHOULD be "application/json".
+
+   The following CDDL [RFC8610] explains the structure of the JSON
+   format audit-log response:
+
+   <CODE BEGINS> file "auditlog.cddl"
+   audit-log-response = {
+     "version": uint,
+     "events": [ + event ]
+     "truncation": {
+       ? "nonced duplicates": uint,
+       ? "nonceless duplicates": uint,
+       ? "arbitrary": uint,
+     }
+   }
+
+   event = {
+     "date": text,
+     "domainID": text,
+     "nonce": text / null,
+     "assertion": "verified" / "logged" / "proximity",
+     ? "truncated": uint,
+   }
+   <CODE ENDS>
+
+                   Figure 17: CDDL for Audit-Log Response
+
+   An example:
+
+   {
+     "version":"1",
+     "events":[
+       {
+           "date":"2019-05-15T17:25:55.644-04:00",
+           "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
+           "nonce":"VOUFT-WwrEv0NuAQEHoV7Q",
+           "assertion":"proximity",
+           "truncated":"0"
+       },
+       {
+           "date":"2017-05-15T17:25:55.644-04:00",
+           "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
+           "nonce":"f4G6Vi1t8nKo/FieCVgpBg==",
+           "assertion":"proximity"
+       }
+     ],
+       "truncation": {
+           "nonced duplicates": "0",
+           "nonceless duplicates": "1",
+           "arbitrary": "2"
+        }
+   }
+
+                Figure 18: Example of an Audit-Log Response
+
+   The domainID is a binary SubjectKeyIdentifier value calculated
+   according to Section 5.8.2.  It is encoded once in base64 in order to
+   be transported in this JSON container.
+
+   The date is formatted per [RFC3339], which is consistent with typical
+   JavaScript usage of JSON.
+
+   The truncation structure MAY be omitted if all values are zero.  Any
+   counter missing from the truncation structure is assumed to be zero.
+
+   The nonce is a string, as provided in the voucher-request, and is
+   used in the voucher.  If no nonce was placed in the resulting
+   voucher, then a value of null SHOULD be used in preference to
+   omitting the entry.  While the nonce is often created as a
+   base64-encoded random series of bytes, this should not be assumed.
+
+   Distribution of a large log is less than ideal.  This structure can
+   be optimized as follows: nonced or nonceless entries for the same
+   domainID MAY be abridged from the log leaving only the single most
+   recent nonced or nonceless entry for that domainID.  In the case of
+   truncation, the "event" truncation value SHOULD contain a count of
+   the number of events for this domainID that were omitted.  The log
+   SHOULD NOT be further reduced, but an operational situation could
+   exist where maintaining the full log is not possible.  In such
+   situations, the log MAY be arbitrarily abridged for length, with the
+   number of removed entries indicated as "arbitrary".
+
+   If the truncation count exceeds 1024, then the MASA MAY use this
+   value without further incrementing it.
+
+   A log where duplicate entries for the same domain have been omitted
+   ("nonced duplicates" and/or "nonceless duplicates") could still be
+   acceptable for informed decisions.  A log that has had "arbitrary"
+   truncations is less acceptable, but manufacturer transparency is
+   better than hidden truncations.
+
+   A registrar that sees a version value greater than 1 indicates an
+   audit-log format that has been enhanced with additional information.
+   No information will be removed in future versions; should an
+   incompatible change be desired in the future, then a new HTTP
+   endpoint will be used.
+
+   This document specifies a simple log format as provided by the MASA
+   service to the registrar.  This format could be improved by
+   distributed consensus technologies that integrate vouchers with
+   technologies such as block-chain or hash trees or optimized logging
+   approaches.  Doing so is out of the scope of this document but is an
+   anticipated improvement for future work.  As such, the registrar
+   SHOULD anticipate new kinds of responses and SHOULD provide operator
+   controls to indicate how to process unknown responses.
+
+5.8.2.  Calculation of domainID
+
+   The domainID is a binary value (a BIT STRING) that uniquely
+   identifies a registrar by the pinned-domain-cert.
+
+   If the pinned-domain-cert certificate includes the
+   SubjectKeyIdentifier ([RFC5280], Section 4.2.1.2), then it is used as
+   the domainID.  If not, the SPKI Fingerprint as described in
+   [RFC7469], Section 2.4 is used.  This value needs to be calculated by
+   both the MASA (to populate the audit-log) and the registrar (to
+   recognize itself in the audit-log).
+
+   [RFC5280], Section 4.2.1.2 does not mandate that the
+   SubjectKeyIdentifier extension be present in non-CA certificates.  It
+   is RECOMMENDED that registrar certificates (even if self-signed)
+   always include the SubjectKeyIdentifier to be used as a domainID.
+
+   The domainID is determined from the certificate chain associated with
+   the pinned-domain-cert and is used to update the audit-log.
+
+5.8.3.  Registrar Audit-Log Verification
+
+   Each time the MASA issues a voucher, it appends details of the
+   assignment to an internal audit-log for that device.  The internal
+   audit-log is processed when responding to requests for details as
+   described in Section 5.8.  The contents of the audit-log can express
+   a variety of trust levels, and this section explains what kind of
+   trust a registrar can derive from the entries.
+
+   While the audit-log provides a list of vouchers that were issued by
+   the MASA, the vouchers are issued in response to voucher-requests,
+   and it is the content of the voucher-requests that determines how
+   meaningful the audit-log entries are.
+
+   A registrar SHOULD use the log information to make an informed
+   decision regarding the continued bootstrapping of the pledge.  The
+   exact policy is out of scope of this document as it depends on the
+   security requirements within the registrar domain.  Equipment that is
+   purchased preowned can be expected to have an extensive history.  The
+   following discussion is provided to help explain the value of each
+   log element:
+
+   date:  The date field provides the registrar an opportunity to divide
+      the log around known events such as the purchase date.  Depending
+      on the context known to the registrar or administrator, events
+      before/after certain dates can have different levels of
+      importance.  For example, for equipment that is expected to be
+      new, and thus has no history, it would be a surprise to find prior
+      entries.
+
+   domainID:  If the log includes an unexpected domainID, then the
+      pledge could have imprinted on an unexpected domain.  The
+      registrar can be expected to use a variety of techniques to define
+      "unexpected" ranging from acceptlists of prior domains to anomaly
+      detection (e.g., "this device was previously bound to a different
+      domain than any other device deployed").  Log entries can also be
+      compared against local history logs in search of discrepancies
+      (e.g., "this device was re-deployed some number of times
+      internally, but the external audit-log shows additional re-
+      deployments our internal logs are unaware of").
+
+   nonce:  Nonceless entries mean the logged domainID could
+      theoretically trigger a reset of the pledge and then take over
+      management by using the existing nonceless voucher.
+
+   assertion:  The assertion leaf in the voucher and audit-log indicates
+      why the MASA issued the voucher.  A "verified" entry means that
+      the MASA issued the associated voucher as a result of positive
+      verification of ownership.  However, this entry does not indicate
+      whether or not the pledge was actually deployed in the prior
+      domain.  A "logged" assertion informs the registrar that the prior
+      vouchers were issued with minimal verification.  A "proximity"
+      assertion assures the registrar that the pledge was truly
+      communicating with the prior domain and thus provides assurance
+      that the prior domain really has deployed the pledge.
+
+   A relatively simple policy is to acceptlist known (internal or
+   external) domainIDs and require all vouchers to have a nonce.  An
+   alternative is to require that all nonceless vouchers be from a
+   subset (e.g., only internal) of domainIDs.  If the policy is
+   violated, a simple action is to revoke any locally issued credentials
+   for the pledge in question or to refuse to forward the voucher.  The
+   registrar MUST then refuse any EST actions and SHOULD inform a human
+   via a log.  A registrar MAY be configured to ignore (i.e., override
+   the above policy) the history of the device, but it is RECOMMENDED
+   that this only be configured if hardware-assisted (i.e., Transport
+   Performance Metrics (TPM) anchored) Network Endpoint Assessment (NEA)
+   [RFC5209] is supported.
+
+5.9.  EST Integration for PKI Bootstrapping
+
+   The pledge SHOULD follow the BRSKI operations with EST enrollment
+   operations including "CA Certificates Request", "CSR Attributes
+   Request", and "Client Certificate Request" or "Server-Side Key
+   Generation", etc.  This is a relatively seamless integration since
+   BRSKI API calls provide an automated alternative to the manual
+   bootstrapping method described in [RFC7030].  As noted above, use of
+   HTTP-persistent connections simplifies the pledge state machine.
+
+   Although EST allows clients to obtain multiple certificates by
+   sending multiple Certificate Signing Requests (CSRs), BRSKI does not
+   support this mechanism directly.  This is because BRSKI pledges MUST
+   use the CSR Attributes request ([RFC7030], Section 4.5).  The
+   registrar MUST validate the CSR against the expected attributes.
+   This implies that client requests will "look the same" and therefore
+   result in a single logical certificate being issued even if the
+   client were to make multiple requests.  Registrars MAY contain more
+   complex logic, but doing so is out of scope of this specification.
+   BRSKI does not signal any enhancement or restriction to this
+   capability.
+
+5.9.1.  EST Distribution of CA Certificates
+
+   The pledge SHOULD request the full EST Distribution of CA certificate
+   messages; see [RFC7030], Section 4.1.
+
+   This ensures that the pledge has the complete set of current CA
+   certificates beyond the pinned-domain-cert (see Section 5.6.2 for a
+   discussion of the limitations inherent in having a single certificate
+   instead of a full CA certificate response).  Although these
+   limitations are acceptable during initial bootstrapping, they are not
+   appropriate for ongoing PKIX end-entity certificate validation.
+
+5.9.2.  EST CSR Attributes
+
+   Automated bootstrapping occurs without local administrative
+   configuration of the pledge.  In some deployments, it is plausible
+   that the pledge generates a certificate request containing only
+   identity information known to the pledge (essentially the X.509
+   IDevID information) and ultimately receives a certificate containing
+   domain-specific identity information.  Conceptually, the CA has
+   complete control over all fields issued in the end-entity
+   certificate.  Realistically, this is operationally difficult with the
+   current status of PKI CA deployments, where the CSR is submitted to
+   the CA via a number of non-standard protocols.  Even with all
+   standardized protocols used, it could operationally be problematic to
+   expect that service-specific certificate fields can be created by a
+   CA that is likely operated by a group that has no insight into
+   different network services/protocols used.  For example, the CA could
+   even be outsourced.
+
+   To alleviate these operational difficulties, the pledge MUST request
+   the EST "CSR Attributes" from the EST server, and the EST server
+   needs to be able to reply with the attributes necessary for use of
+   the certificate in its intended protocols/services.  This approach
+   allows for minimal CA integrations, and instead, the local
+   infrastructure (EST server) informs the pledge of the proper fields
+   to include in the generated CSR (such as rfc822Name).  This approach
+   is beneficial to automated bootstrapping in the widest number of
+   environments.
+
+   In networks using the BRSKI enrolled certificate to authenticate the
+   ACP, the EST CSR Attributes MUST include the ACP domain information
+   fields defined in [RFC8994], Section 6.2.2.
+
+   The registrar MUST also confirm that the resulting CSR is formatted
+   as indicated before forwarding the request to a CA.  If the registrar
+   is communicating with the CA using a protocol such as full
+   Certificate Management over CMS (CMC), which provides mechanisms to
+   override the CSR Attributes, then these mechanisms MAY be used even
+   if the client ignores the guidance for the CSR Attributes.
+
+5.9.3.  EST Client Certificate Request
+
+   The pledge MUST request a new Client Certificate; see [RFC7030],
+   Section 4.2.
+
+5.9.4.  Enrollment Status Telemetry
+
+   For automated bootstrapping of devices, the administrative elements
+   that provide bootstrapping also provide indications to the system
+   administrators concerning device life-cycle status.  This might
+   include information concerning attempted bootstrapping messages seen
+   by the client.  The MASA provides logs and the status of credential
+   enrollment.  Since an end user is assumed per [RFC7030], a final
+   success indication back to the server is not included.  This is
+   insufficient for automated use cases.
+
+   The client MUST send an indicator to the registrar about its
+   enrollment status.  It does this by using an HTTP POST of a JSON
+   dictionary with the attributes described below to the new EST
+   endpoint at "/.well-known/brski/enrollstatus".
+
+   When indicating a successful enrollment, the client SHOULD first re-
+   establish the EST TLS session using the newly obtained credentials.
+   TLS 1.3 supports doing this in-band, but TLS 1.2 does not.  The
+   client SHOULD therefore always close the existing TLS connection and
+   start a new one, using the same Join Proxy.
+
+   In the case of a failed enrollment, the client MUST send the
+   telemetry information over the same TLS connection that was used for
+   the enrollment attempt, with a Reason string indicating why the most
+   recent enrollment failed.  (For failed attempts, the TLS connection
+   is the most reliable way to correlate server-side information with
+   what the client provides.)
+
+   The version and status fields MUST be present.  The Reason field
+   SHOULD be present whenever the status field is false.  In the case of
+   a SUCCESS, the Reason string MAY be omitted.
+
+   The reason-context attribute is an arbitrary JSON object (literal
+   value or hash of values) that provides additional information
+   specific to the failure to unroll from this pledge.  The contents of
+   this field are not subject to standardization.  This is represented
+   by the group-socket "$$arbitrary-map" in the CDDL.
+
+   <CODE BEGINS> file "enrollstatus.cddl"
+   enrollstatus-post = {
+       "version": uint,
+       "status": bool,
+       ? "reason": text,
+       ? "reason-context" : { $$arbitrary-map }
+     }
+   }
+   <CODE ENDS>
+
+                 Figure 19: CDDL for Enrollment Status POST
+
+   An example status report can be seen below.  It is sent with the
+   media type: application/json
+
+   {
+       "version": 1,
+       "status":true,
+       "reason":"Informative human readable message",
+       "reason-context": { "additional" : "JSON" }
+   }
+
+                Figure 20: Example of Enrollment Status POST
+
+   The server SHOULD respond with an HTTP 200 but MAY simply fail with
+   an HTTP 404 error.
+
+   Within the server logs, the server MUST capture if this message was
+   received over a TLS session with a matching Client Certificate.
+
+5.9.5.  Multiple Certificates
+
+   Pledges that require multiple certificates could establish direct EST
+   connections to the registrar.
+
+5.9.6.  EST over CoAP
+
+   This document describes extensions to EST for the purpose of
+   bootstrapping remote key infrastructures.  Bootstrapping is relevant
+   for CoAP enrollment discussions as well.  The definition of EST and
+   BRSKI over CoAP is not discussed within this document beyond ensuring
+   proxy support for CoAP operations.  Instead, it is anticipated that a
+   definition of CoAP mappings will occur in subsequent documents such
+   as [ACE-COAP-EST] and that CoAP mappings for BRSKI will be discussed
+   either there or in future work.
+
+6.  Clarification of Transfer-Encoding
+
+   [RFC7030] defines endpoints to include a "Content-Transfer-Encoding"
+   heading and payloads to be base64-encoded DER [RFC4648].
+
+   When used within BRSKI, the original EST endpoints remain base64
+   encoded [RFC7030] (as clarified by [RFC8951]), but the new BRSKI
+   endpoints that send and receive binary artifacts (specifically,
+   "/.well-known/brski/requestvoucher") are binary.  That is, no
+   encoding is used.
+
+   In the BRSKI context, the EST "Content-Transfer-Encoding" header
+   field SHOULD be ignored if present.  This header field does not need
+   to be included.
+
+7.  Reduced Security Operational Modes
+
+   A common requirement of bootstrapping is to support less secure
+   operational modes for support-specific use cases.  This section
+   suggests a range of mechanisms that would alter the security
+   assurance of BRSKI to accommodate alternative deployment
+   architectures and mitigate life-cycle management issues identified in
+   Section 10.  They are presented here as informative (non-normative)
+   design guidance for future standardization activities.  Section 9
+   provides standardization applicability statements for the ANIMA ACP.
+   Other users would expect that subsets of these mechanisms could be
+   profiled with accompanying applicability statements similar to the
+   one described in Section 9.
+
+   This section is considered non-normative in the generality of the
+   protocol.  Use of the suggested mechanisms here MUST be detailed in
+   specific profiles of BRSKI, such as in Section 9.
+
+7.1.  Trust Model
+
+   This section explains the trust relationships detailed in
+   Section 2.4:
+
+   +--------+         +---------+    +------------+     +------------+
+   | Pledge |         | Join    |    | Domain     |     |Manufacturer|
+   |        |         | Proxy   |    | Registrar  |     | Service    |
+   |        |         |         |    |            |     | (Internet) |
+   +--------+         +---------+    +------------+     +------------+
+
+                  Figure 21: Elements of BRSKI Trust Model
+
+   Pledge:  The pledge could be compromised and provide an attack vector
+      for malware.  The entity is trusted to only imprint using secure
+      methods described in this document.  Additional endpoint
+      assessment techniques are RECOMMENDED but are out of scope of this
+      document.
+
+   Join Proxy:  Provides proxy functionalities but is not involved in
+      security considerations.
+
+   Registrar:  When interacting with a MASA, a registrar makes all
+      decisions.  For Ownership Audit Vouchers (see [RFC8366]), the
+      registrar is provided an opportunity to accept MASA decisions.
+
+   Vendor Service, MASA:  This form of manufacturer service is trusted
+      to accurately log all claim attempts and to provide authoritative
+      log information to registrars.  The MASA does not know which
+      devices are associated with which domains.  These claims could be
+      strengthened by using cryptographic log techniques to provide
+      append only, cryptographic assured, publicly auditable logs.
+
+   Vendor Service, Ownership Validation:  This form of manufacturer
+      service is trusted to accurately know which device is owned by
+      which domain.
+
+7.2.  Pledge Security Reductions
+
+   The following is a list of alternative behaviors that the pledge can
+   be programmed to implement.  These behaviors are not mutually
+   exclusive, nor are they dependent upon each other.  Some of these
+   methods enable offline and emergency (touch-based) deployment use
+   cases.  Normative language is used as these behaviors are referenced
+   in later sections in a normative fashion.
+
+   1.  The pledge MUST accept nonceless vouchers.  This allows for a use
+       case where the registrar cannot connect to the MASA at the
+       deployment time.  Logging and validity periods address the
+       security considerations of supporting these use cases.
+
+   2.  Many devices already support "trust on first use" for physical
+       interfaces such as console ports.  This document does not change
+       that reality.  Devices supporting this protocol MUST NOT support
+       "trust on first use" on network interfaces.  This is because
+       "trust on first use" over network interfaces would undermine the
+       logging based security protections provided by this
+       specification.
+
+   3.  The pledge MAY have an operational mode where it skips voucher
+       validation one time, for example, if a physical button is
+       depressed during the bootstrapping operation.  This can be useful
+       if the manufacturer service is unavailable.  This behavior SHOULD
+       be available via local configuration or physical presence methods
+       (such as use of a serial/craft console) to ensure new entities
+       can always be deployed even when autonomic methods fail.  This
+       allows for unsecured imprint.
+
+   4.  A craft/serial console could include a command such as "est-
+       enroll [2001:db8:0:1]:443" that begins the EST process from the
+       point after the voucher is validated.  This process SHOULD
+       include server certificate verification using an on-screen
+       fingerprint.
+
+   It is RECOMMENDED that "trust on first use" or any method of skipping
+   voucher validation (including use of a craft serial console) only be
+   available if hardware-assisted Network Endpoint Assessment (NEA)
+   [RFC5209] is supported.  This recommendation ensures that domain
+   network monitoring can detect inappropriate use of offline or
+   emergency deployment procedures when voucher-based bootstrapping is
+   not used.
+
+7.3.  Registrar Security Reductions
+
+   A registrar can choose to accept devices using less secure methods.
+   They MUST NOT be the default behavior.  These methods may be
+   acceptable in situations where threat models indicate that low
+   security is adequate.  This includes situations where security
+   decisions are being made by the local administrator:
+
+   1.  A registrar MAY choose to accept all devices, or all devices of a
+       particular type.  The administrator could make this choice in
+       cases where it is operationally difficult to configure the
+       registrar with the unique identifier of each new device expected.
+
+   2.  A registrar MAY choose to accept devices that claim a unique
+       identity without the benefit of authenticating that claimed
+       identity.  This could occur when the pledge does not include an
+       X.509 IDevID factory-installed credential.  New entities without
+       an X.509 IDevID credential MAY form the request per Section 5.2
+       using the format per Section 5.5 to ensure the pledge's serial
+       number information is provided to the registrar (this includes
+       the IDevID AuthorityKeyIdentifier value, which would be
+       statically configured on the pledge).  The pledge MAY refuse to
+       provide a TLS Client Certificate (as one is not available).  The
+       pledge SHOULD support HTTP-based or certificate-less TLS
+       authentication as described in EST [RFC7030], Section 3.3.2.  A
+       registrar MUST NOT accept unauthenticated new entities unless it
+       has been configured to do so by an administrator that has
+       verified that only expected new entities can communicate with a
+       registrar (presumably via a physically secured perimeter.)
+
+   3.  A registrar MAY submit a nonceless voucher-request to the MASA
+       service (by not including a nonce in the voucher-request).  The
+       resulting vouchers can then be stored by the registrar until they
+       are needed during bootstrapping operations.  This is for use
+       cases where the target network is protected by an air gap and
+       therefore cannot contact the MASA service during pledge
+       deployment.
+
+   4.  A registrar MAY ignore unrecognized nonceless log entries.  This
+       could occur when used equipment is purchased with a valid history
+       of being deployed in air gap networks that required offline
+       vouchers.
+
+   5.  A registrar MAY accept voucher formats of future types that
+       cannot be parsed by the registrar.  This reduces the registrar's
+       visibility into the exact voucher contents but does not change
+       the protocol operations.
+
+7.4.  MASA Security Reductions
+
+   Lower security modes chosen by the MASA service affect all device
+   deployments unless the lower security behavior is tied to specific
+   device identities.  The modes described below can be applied to
+   specific devices via knowledge of what devices were sold.  They can
+   also be bound to specific customers (independent of the device
+   identity) by authenticating the customer's registrar.
+
+7.4.1.  Issuing Nonceless Vouchers
+
+   A MASA has the option of not including a nonce in the voucher and/or
+   not requiring one to be present in the voucher-request.  This results
+   in distribution of a voucher that may never expire and, in effect,
+   makes the specified domain an always trusted entity to the pledge
+   during any subsequent bootstrapping attempts.  The log information
+   captures when a nonceless voucher is issued so that the registrar can
+   make appropriate security decisions when a pledge joins the domain.
+   Nonceless vouchers are useful to support use cases where registrars
+   might not be online during actual device deployment.
+
+   While a nonceless voucher may include an expiry date, a typical use
+   for a nonceless voucher is for it to be long lived.  If the device
+   can be trusted to have an accurate clock (the MASA will know), then a
+   nonceless voucher CAN be issued with a limited lifetime.
+
+   A more typical case for a nonceless voucher is for use with offline
+   onboarding scenarios where it is not possible to pass a fresh
+   voucher-request to the MASA.  The use of a long-lived voucher also
+   eliminates concern about the availability of the MASA many years in
+   the future.  Thus, many nonceless vouchers will have no expiry dates.
+
+   Thus, the long-lived nonceless voucher does not require proof that
+   the device is online.  Issuing such a thing is only accepted when the
+   registrar is authenticated by the MASA and the MASA is authorized to
+   provide this functionality to this customer.  The MASA is RECOMMENDED
+   to use this functionality only in concert with an enhanced level of
+   ownership tracking, the details of which are out of scope for this
+   document.
+
+   If the pledge device is known to have a real-time clock that is set
+   from the factory, use of a voucher validity period is RECOMMENDED.
+
+7.4.2.  Trusting Owners on First Use
+
+   A MASA has the option of not verifying ownership before responding
+   with a voucher.  This is expected to be a common operational model
+   because doing so relieves the manufacturer providing MASA services
+   from having to track ownership during shipping and throughout the
+   supply chain, and it allows for a very low overhead MASA service.  A
+   registrar uses the audit-log information as an in-depth defense
+   strategy to ensure that this does not occur unexpectedly (for
+   example, when purchasing new equipment, the registrar would throw an
+   error if any audit-log information is reported).  The MASA SHOULD
+   verify the prior-signed-voucher-request information for pledges that
+   support that functionality.  This provides a proof-of-proximity check
+   that reduces the need for ownership verification.  The proof-of-
+   proximity comes from the assumption that the pledge and Join Proxy
+   are on the same link-local connection.
+
+   A MASA that practices TOFU for registrar identity may wish to
+   annotate the origin of the connection by IP address or netblock and
+   restrict future use of that identity from other locations.  A MASA
+   that does this SHOULD take care to not create nuisance situations for
+   itself when a customer has multiple registrars or uses outgoing IPv4-
+   to-IPv4 NAT (NAT44) connections that change frequently.
+
+7.4.3.  Updating or Extending Voucher Trust Anchors
+
+   This section deals with two problems: A MASA that is no longer
+   available due to a failed business and a MASA that is uncooperative
+   to a secondary sale.
+
+   A manufacturer could offer a management mechanism that allows the
+   list of voucher verification trust anchors to be extended.
+   [YANG-KEYSTORE] describes one such interface that could be
+   implemented using YANG.  Pretty much any configuration mechanism used
+   today could be extended to provide the needed additional update.  A
+   manufacturer could even decide to install the domain CA trust anchors
+   received during the EST "cacerts" step as voucher verification
+   anchors.  Some additional signals will be needed to clearly identify
+   which keys have voucher validation authority from among those signed
+   by the domain CA.  This is future work.
+
+   With the above change to the list of anchors, vouchers can be issued
+   by an alternate MASA.  This could be the previous owner (the seller)
+   or some other trusted third party who is mediating the sale.  If it
+   is a third party, the seller would need to take steps to introduce
+   the third-party configuration to the device prior to disconnection.
+   The third party (e.g., a wholesaler of used equipment) could,
+   however, use a mechanism described in Section 7.2 to take control of
+   the device after receiving it physically.  This would permit the
+   third party to act as the MASA for future onboarding actions.  As the
+   IDevID certificate probably cannot be replaced, the new owner's
+   registrar would have to support an override of the MASA URL.
+
+   To be useful for resale or other transfers of ownership, one of two
+   situations will need to occur.  The simplest is that the device is
+   not put through any kind of factory default/reset before going
+   through onboarding again.  Some other secure, physical signal would
+   be needed to initiate it.  This is most suitable for redeploying a
+   device within the same enterprise.  This would entail having previous
+   configuration in the system until entirely replaced by the new owner,
+   and it represents some level of risk.
+
+   For the second scenario, there would need to be two levels of factory
+   reset.  One would take the system back entirely to manufacturer
+   state, including removing any added trust anchors, and the other
+   (more commonly used) one would just restore the configuration back to
+   a known default without erasing trust anchors.  This weaker factory
+   reset might leave valuable credentials on the device, and this may be
+   unacceptable to some owners.
+
+   As a third option, the manufacturer's trust anchors could be entirely
+   overwritten with local trust anchors.  A factory default would never
+   restore those anchors.  This option comes with a lot of power but is
+   also a lot of responsibility: if access to the private part of the
+   new anchors are lost, the manufacturer may be unable to help.
+
+8.  IANA Considerations
+
+   Per this document, IANA has completed the following actions.
+
+8.1.  The IETF XML Registry
+
+   This document registers a URI in the "IETF XML Registry" [RFC3688].
+   IANA has registered the following:
+
+   URI:  urn:ietf:params:xml:ns:yang:ietf-voucher-request
+   Registrant Contact:  The ANIMA WG of the IETF.
+   XML:  N/A; the requested URI is an XML namespace.
+
+8.2.  YANG Module Names Registry
+
+   This document registers a YANG module in the "YANG Module Names"
+   registry [RFC6020].  IANA has registered the following:
+
+   Name:  ietf-voucher-request
+   Namespace:  urn:ietf:params:xml:ns:yang:ietf-voucher-request
+   Prefix:  vch
+   Reference:  RFC 8995
+
+8.3.  BRSKI Well-Known Considerations
+
+8.3.1.  BRSKI .well-known Registration
+
+   To the "Well-Known URIs" registry at
+   https://www.iana.org/assignments/well-known-uris/, this document
+   registers the well-known name "brski" with the following filled-in
+   template from [RFC8615]:
+
+   URI Suffix:  brski
+   Change Controller:  IETF
+
+   IANA has changed the registration of "est" to now only include
+   [RFC7030] and no longer this document.  Earlier draft versions of
+   this document used "/.well-known/est" rather than "/.well-known/
+   brski".
+
+8.3.2.  BRSKI .well-known Registry
+
+   IANA has created a new registry entitled: "BRSKI Well-Known URIs".
+   The registry has three columns: URI, Description, and Reference.  New
+   items can be added using the Specification Required [RFC8126]
+   process.  The initial contents of this registry are:
+
+        +=================+==========================+===========+
+        | URI             | Description              | Reference |
+        +=================+==========================+===========+
+        | requestvoucher  | pledge to registrar, and | RFC 8995  |
+        |                 | from registrar to MASA   |           |
+        +-----------------+--------------------------+-----------+
+        | voucher_status  | pledge to registrar      | RFC 8995  |
+        +-----------------+--------------------------+-----------+
+        | requestauditlog | registrar to MASA        | RFC 8995  |
+        +-----------------+--------------------------+-----------+
+        | enrollstatus    | pledge to registrar      | RFC 8995  |
+        +-----------------+--------------------------+-----------+
+
+                      Table 1: BRSKI Well-Known URIs
+
+8.4.  PKIX Registry
+
+   IANA has registered the following:
+
+   a number for id-mod-MASAURLExtn2016(96) from the pkix(7) id-mod(0)
+   Registry.
+
+   IANA has assigned a number from the id-pe registry (Structure of
+   Management Information (SMI) Security for PKIX Certificate Extension)
+   for id-pe-masa-url with the value 32, resulting in an OID of
+   1.3.6.1.5.5.7.1.32.
+
+8.5.  Pledge BRSKI Status Telemetry
+
+   IANA has created a new registry entitled "BRSKI Parameters" and has
+   created, within that registry, a table called: "Pledge BRSKI Status
+   Telemetry Attributes".  New items can be added using the
+   Specification Required process.  The following items are in the
+   initial registration, with this document (see Section 5.7) as the
+   reference:
+
+   *  version
+
+   *  Status
+
+   *  Reason
+
+   *  reason-context
+
+8.6.  DNS Service Names
+
+   IANA has registered the following service names:
+
+   Service Name:  brski-proxy
+   Transport Protocol(s):  tcp
+   Assignee:  IESG <iesg@ietf.org>
+   Contact:  IESG <iesg@ietf.org>
+   Description:  The Bootstrapping Remote Secure Key Infrastructure
+      Proxy
+   Reference:  RFC 8995
+
+   Service Name:  brski-registrar
+   Transport Protocol(s):  tcp
+   Assignee:  IESG <iesg@ietf.org>
+   Contact:  IESG <iesg@ietf.org>
+   Description:  The Bootstrapping Remote Secure Key Infrastructure
+      Registrar
+   Reference:  RFC 8995
+
+8.7.  GRASP Objective Names
+
+   IANA has registered the following GRASP Objective Names:
+
+   IANA has registered the value "AN_Proxy" (without quotes) to the
+   "GRASP Objective Names" table in the GRASP Parameter registry.  The
+   specification for this value is Section 4.1.1 of this document.
+
+   The IANA has registered the value "AN_join_registrar" (without
+   quotes) to the "GRASP Objective Names" table in the GRASP Parameter
+   registry.  The specification for this value is Section 4.3 of this
+   document.
+
+9.  Applicability to the Autonomic Control Plane (ACP)
+
+   This document provides a solution to the requirements for secure
+   bootstrapping as defined in "Using an Autonomic Control Plane for
+   Stable Connectivity of Network Operations, Administration, and
+   Maintenance (OAM)" [RFC8368], "A Reference Model for Autonomic
+   Networking" [RFC8993], and specifically "An Autonomic Control Plane
+   (ACP)" [RFC8994]; see Sections 3.2 ("Secure Bootstrap over an
+   Unconfigured Network") and 6.2 ("ACP Domain, Certificate, and
+   Network").
+
+   The protocol described in this document has appeal in a number of
+   other non-ANIMA use cases.  Such uses of the protocol will be
+   deployed into other environments with different tradeoffs of privacy,
+   security, reliability, and autonomy from manufacturers.  As such,
+   those use cases will need to provide their own applicability
+   statements and will need to address unique privacy and security
+   considerations for the environments in which they are used.
+
+   The ACP that is bootstrapped by the BRSKI protocol is typically used
+   in medium to large Internet service provider organizations.
+   Equivalent enterprises that have significant Layer 3 router
+   connectivity also will find significant benefit, particularly if the
+   enterprise has many sites.  (A network consisting of primarily Layer
+   2 is not excluded, but the adjacencies that the ACP will create and
+   maintain will not reflect the topology until all devices participate
+   in the ACP.)
+
+   In the ACP, the Join Proxy is found to be proximal because
+   communication between the pledge and the Join Proxy is exclusively on
+   IPv6 link-local addresses.  The proximity of the Join Proxy to the
+   registrar is validated by the registrar using ANI ACP IPv6 ULAs.
+   ULAs are not routable over the Internet, so as long as the Join Proxy
+   is operating correctly, the proximity assertion is satisfied.  Other
+   uses of BRSKI will need similar analysis if they use proximity
+   assertions.
+
+   As specified in the ANIMA charter, this work "focuses on
+   professionally-managed networks."  Such a network has an operator and
+   can do things like install, configure, and operate the registrar
+   function.  The operator makes purchasing decisions and is aware of
+   what manufacturers it expects to see on its network.
+
+   Such an operator is also capable of performing bootstrapping of a
+   device using a serial console (craft console).  The zero-touch
+   mechanism presented in this and the ACP document [RFC8994] represents
+   a significant efficiency: in particular, it reduces the need to put
+   senior experts on airplanes to configure devices in person.
+
+   As the technology evolves, there is recognition that not every
+   situation may work out, and occasionally a human may still have to
+   visit.  Given this, some mechanisms are presented in Section 7.2.
+   The manufacturer MUST provide at least one of the one-touch
+   mechanisms described that permit enrollment to proceed without the
+   availability of any manufacturer server (such as the MASA).
+
+   The BRSKI protocol is going into environments where there have
+   already been quite a number of vendor proprietary management systems.
+   Those are not expected to go away quickly but rather to leverage the
+   secure credentials that are provisioned by BRSKI.  The connectivity
+   requirements of the said management systems are provided by the ACP.
+
+9.1.  Operational Requirements
+
+   This section collects operational requirements based upon the three
+   roles involved in BRSKI: the MASA, the (domain) owner, and the
+   device.  It should be recognized that the manufacturer may be
+   involved in two roles, as it creates the software/firmware for the
+   device and may also be the operator of the MASA.
+
+   The requirements in this section are presented using BCP 14 language
+   [RFC2119] [RFC8174].  These do not represent new normative
+   statements, just a review of a few such things in one place by role.
+   They also apply specifically to the ANIMA ACP use case.  Other use
+   cases likely have similar, but MAY have different, requirements.
+
+9.1.1.  MASA Operational Requirements
+
+   The manufacturer MUST arrange for an online service called the MASA
+   to be available.  It MUST be available at the URL that is encoded in
+   the IDevID certificate extensions described in Section 2.3.2.
+
+   The online service MUST have access to a private key with which to
+   sign voucher artifacts [RFC8366].  The public key, certificate, or
+   certificate chain MUST be built into the device as part of the
+   firmware.
+
+   It is RECOMMENDED that the manufacturer arrange for this signing key
+   (or keys) to be escrowed according to typical software source code
+   escrow practices [softwareescrow].
+
+   The MASA accepts voucher-requests from domain owners according to an
+   operational practice appropriate for the device.  This can range from
+   any domain owner (first-come first-served, on a TOFU-like basis), to
+   full sales channel integration where domain owners need to be
+   positively identified by TLS pinned Client Certificates or an HTTP
+   authentication process.  The MASA creates signed voucher artifacts
+   according to its internally defined policies.
+
+   The MASA MUST operate an audit-log for devices that is accessible.
+   The audit-log is designed to be easily cacheable, and the MASA MAY
+   find it useful to put this content on a Content Delivery Network
+   (CDN).
+
+9.1.2.  Domain Owner Operational Requirements
+
+   The domain owner MUST operate an EST [RFC7030] server with the
+   extensions described in this document.  This is the JRC or registrar.
+   This JRC/EST server MUST announce itself using GRASP within the ACP.
+   This EST server will typically reside with the Network Operations
+   Center for the organization.
+
+   The domain owner MAY operate an internal CA that is separate from the
+   EST server, or it MAY combine all activities into a single device.
+   The determination of the architecture depends upon the scale and
+   resiliency requirements of the organization.  Multiple JRC instances
+   MAY be announced into the ACP from multiple locations to achieve an
+   appropriate level of redundancy.
+
+   In order to recognize which devices and which manufacturers are
+   welcome on the domain owner's network, the domain owner SHOULD
+   maintain an acceptlist of manufacturers.  This MAY extend to
+   integration with purchasing departments to know the serial numbers of
+   devices.
+
+   The domain owner SHOULD use the resulting overlay ACP network to
+   manage devices, replacing legacy out-of-band mechanisms.
+
+   The domain owner SHOULD operate one or more EST servers that can be
+   used to renew the domain certificates (LDevIDs), which are deployed
+   to devices.  These servers MAY be the same as the JRC or MAY be a
+   distinct set of devices, as appropriate for resiliency.
+
+   The organization MUST take appropriate precautions against loss of
+   access to the CA private key.  Hardware security modules and/or
+   secret splitting are appropriate.
+
+9.1.3.  Device Operational Requirements
+
+   Devices MUST come with built-in trust anchors that permit the device
+   to validate vouchers from the MASA.
+
+   Devices MUST come with (unique, per-device) IDevID certificates that
+   include their serial numbers and the MASA URL extension.
+
+   Devices are expected to find Join Proxies using GRASP, and then
+   connect to the JRC using the protocol described in this document.
+
+   Once a domain owner has been validated with the voucher, devices are
+   expected to enroll into the domain using EST.  Devices are then
+   expected to form ACPs using IPsec over IPv6 link-local addresses as
+   described in [RFC8994].
+
+   Once a device has been enrolled, it SHOULD listen for the address of
+   the JRC using GRASP, and it SHOULD enable itself as a Join Proxy and
+   announce itself on all links/interfaces using GRASP DULL.
+
+   Devices are expected to renew their certificates before they expire.
+
+10.  Privacy Considerations
+
+10.1.  MASA Audit-Log
+
+   The MASA audit-log includes the domainID for each domain a voucher
+   has been issued to.  This information is closely related to the
+   actual domain identity.  A MASA may need additional defenses against
+   Denial-of-Service attacks (Section 11.1), and this may involve
+   collecting additional (unspecified here) information.  This could
+   provide sufficient information for the MASA service to build a
+   detailed understanding of the devices that have been provisioned
+   within a domain.
+
+   There are a number of design choices that mitigate this risk.  The
+   domain can maintain some privacy since it has not necessarily been
+   authenticated and is not authoritatively bound to the supply chain.
+
+   Additionally, the domainID captures only the unauthenticated subject
+   key identifier of the domain.  A privacy-sensitive domain could
+   theoretically generate a new domainID for each device being deployed.
+   Similarly, a privacy-sensitive domain would likely purchase devices
+   that support proximity assertions from a manufacturer that does not
+   require sales channel integrations.  This would result in a
+   significant level of privacy while maintaining the security
+   characteristics provided by the registrar-based audit-log inspection.
+
+10.2.  What BRSKI-EST Reveals
+
+   During the provisional phase of the BRSKI-EST connection between the
+   pledge and the registrar, each party reveals its certificates to each
+   other.  For the pledge, this includes the serialNumber attribute, the
+   MASA URL, and the identity that signed the IDevID certificate.
+
+   TLS 1.2 reveals the certificate identities to on-path observers,
+   including the Join Proxy.
+
+   TLS 1.3 reveals the certificate identities only to the end parties,
+   but as the connection is provisional; an on-path attacker (MITM) can
+   see the certificates.  This includes not just malicious attackers but
+   also registrars that are visible to the pledge but are not part of
+   the intended domain.
+
+   The certificate of the registrar is rather arbitrary from the point
+   of view of the BRSKI protocol.  As no validations [RFC6125] are
+   expected to be done, the contents could be easily pseudonymized.  Any
+   device that can see a Join Proxy would be able to connect to the
+   registrar and learn the identity of the network in question.  Even if
+   the contents of the certificate are pseudonymized, it would be
+   possible to correlate different connections in different locations
+   that belong to the same entity.  This is unlikely to present a
+   significant privacy concern to ANIMA ACP uses of BRSKI, but it may be
+   a concern to other users of BRSKI.
+
+   The certificate of the pledge could be revealed by a malicious Join
+   Proxy that performed a MITM attack on the provisional TLS connection.
+   Such an attacker would be able to reveal the identity of the pledge
+   to third parties if it chose to do so.
+
+   Research into a mechanism to do multistep, multiparty authenticated
+   key agreement, incorporating some kind of zero-knowledge proof, would
+   be valuable.  Such a mechanism would ideally avoid disclosing
+   identities until the pledge, registrar, and MASA agree to the
+   transaction.  Such a mechanism would need to discover the location of
+   the MASA without knowing the identity of the pledge or the identity
+   of the MASA.  This part of the problem may be unsolvable.
+
+10.3.  What BRSKI-MASA Reveals to the Manufacturer
+
+   With consumer-oriented devices, the "call-home" mechanism in IoT
+   devices raises significant privacy concerns.  See [livingwithIoT] and
+   [IoTstrangeThings] for exemplars.  The ACP usage of BRSKI is not
+   targeted at individual usage of IoT devices but rather at the
+   enterprise and ISP creation of networks in a zero-touch fashion where
+   the "call-home" represents a different class of privacy and life-
+   cycle management concerns.
+
+   It needs to be reiterated that the BRSKI-MASA mechanism only occurs
+   once during the commissioning of the device.  It is well defined, and
+   although encrypted with TLS, it could in theory be made auditable as
+   the contents are well defined.  This connection does not occur when
+   the device powers on or is restarted for normal routines.  (It is
+   conceivable, but remarkably unusual, that a device could be forced to
+   go through a full factory reset during an exceptional firmware update
+   situation, after which enrollment would have to be repeated, and a
+   new connection would occur.)
+
+   The BRSKI call-home mechanism is mediated via the owner's registrar,
+   and the information that is transmitted is directly auditable by the
+   device owner.  This is in stark contrast to many "call-home"
+   protocols where the device autonomously calls home and uses an
+   undocumented protocol.
+
+   While the contents of the signed part of the pledge voucher-request
+   cannot be changed, they are not encrypted at the registrar.  The
+   ability to audit the messages by the owner of the network is a
+   mechanism to defend against exfiltration of data by a nefarious
+   pledge.  Both are, to reiterate, encrypted by TLS while in transit.
+
+   The BRSKI-MASA exchange reveals the following information to the
+   manufacturer:
+
+   *  the identity of the device being enrolled.  This is revealed by
+      transmission of a signed voucher-request containing the serial-
+      number.  The manufacturer can usually link the serial number to a
+      device model.
+
+   *  an identity of the domain owner in the form of the domain trust
+      anchor.  However, this is not a global PKI-anchored name within
+      the WebPKI, so this identity could be pseudonymous.  If there is
+      sales channel integration, then the MASA will have authenticated
+      the domain owner, via either a pinned certificate or perhaps
+      another HTTP authentication method, as per Section 5.5.4.
+
+   *  the time the device is activated.
+
+   *  the IP address of the domain owner's registrar.  For ISPs and
+      enterprises, the IP address provides very clear geolocation of the
+      owner.  No amount of IP address privacy extensions [RFC8981] can
+      do anything about this, as a simple whois lookup likely identifies
+      the ISP or enterprise from the upper bits anyway.  A passive
+      attacker who observes the connection definitely may conclude that
+      the given enterprise/ISP is a customer of the particular equipment
+      vendor.  The precise model that is being enrolled will remain
+      private.
+
+   Based upon the above information, the manufacturer is able to track a
+   specific device from pseudonymous domain identity to the next
+   pseudonymous domain identity.  If there is sales-channel integration,
+   then the identities are not pseudonymous.
+
+   The manufacturer knows the IP address of the registrar, but it cannot
+   see the IP address of the device itself.  The manufacturer cannot
+   track the device to a detailed physical or network location, only to
+   the location of the registrar.  That is likely to be at the
+   enterprise or ISP's headquarters.
+
+   The above situation is to be distinguished from a residential/
+   individual person who registers a device from a manufacturer.
+   Individuals do not tend to have multiple offices, and their registrar
+   is likely on the same network as the device.  A manufacturer that
+   sells switching/routing products to enterprises should hardly be
+   surprised if additional purchases of switching/routing products are
+   made.  Deviations from a historical trend or an established baseline
+   would, however, be notable.
+
+   The situation is not improved by the enterprise/ISP using
+   anonymization services such as Tor [Dingledine], as a TLS 1.2
+   connection will reveal the ClientCertificate used, clearly
+   identifying the enterprise/ISP involved.  TLS 1.3 is better in this
+   regard, but an active attacker can still discover the parties
+   involved by performing a MITM attack on the first attempt (breaking/
+   killing it with a TCP reset (RST)), and then letting subsequent
+   connection pass through.
+
+   A manufacturer could attempt to mix the BRSKI-MASA traffic in with
+   general traffic on their site by hosting the MASA behind the same
+   (set) of load balancers that the company's normal marketing site is
+   hosted behind.  This makes a lot of sense from a straight capacity
+   planning point of view as the same set of services (and the same set
+   of Distributed Denial-of-Service mitigations) may be used.
+   Unfortunately, as the BRSKI-MASA connections include TLS
+   ClientCertificate exchanges, this may easily be observed in TLS 1.2,
+   and a traffic analysis may reveal it even in TLS 1.3.  This does not
+   make such a plan irrelevant.  There may be other organizational
+   reasons to keep the marketing site (which is often subject to
+   frequent redesigns, outsourcing, etc.) separate from the MASA, which
+   may need to operate reliably for decades.
+
+10.4.  Manufacturers and Used or Stolen Equipment
+
+   As explained above, the manufacturer receives information each time a
+   device that is in factory-default mode does a zero-touch bootstrap
+   and attempts to enroll into a domain owner's registrar.
+
+   The manufacturer is therefore in a position to decline to issue a
+   voucher if it detects that the new owner is not the same as the
+   previous owner.
+
+   1.  This can be seen as a feature if the equipment is believed to
+       have been stolen.  If the legitimate owner notifies the
+       manufacturer of the theft, then when the new owner brings the
+       device up, if they use the zero-touch mechanism, the new
+       (illegitimate) owner reveals their location and identity.
+
+   2.  In the case of used equipment, the initial owner could inform the
+       manufacturer of the sale, or the manufacturer may just permit
+       resales unless told otherwise.  In which case, the transfer of
+       ownership simply occurs.
+
+   3.  A manufacturer could, however, decide not to issue a new voucher
+       in response to a transfer of ownership.  This is essentially the
+       same as the stolen case, with the manufacturer having decided
+       that the sale was not legitimate.
+
+   4.  There is a fourth case, if the manufacturer is providing
+       protection against stolen devices.  The manufacturer then has a
+       responsibility to protect the legitimate owner against fraudulent
+       claims that the equipment was stolen.  In the absence of such
+       manufacturer protection, such a claim would cause the
+       manufacturer to refuse to issue a new voucher.  Should the device
+       go through a deep factory reset (for instance, replacement of a
+       damaged main board component), the device would not bootstrap.
+
+   5.  Finally, there is a fifth case: the manufacturer has decided to
+       end-of-line the device, or the owner has not paid a yearly
+       support amount, and the manufacturer refuses to issue new
+       vouchers at that point.  This last case is not new to the
+       industry: many license systems are already deployed that have a
+       significantly worse effect.
+
+   This section has outlined five situations in which a manufacturer
+   could use the voucher system to enforce what are clearly license
+   terms.  A manufacturer that attempted to enforce license terms via
+   vouchers would find it rather ineffective as the terms would only be
+   enforced when the device is enrolled, and this is not (to repeat) a
+   daily or even monthly occurrence.
+
+10.5.  Manufacturers and Grey Market Equipment
+
+   Manufacturers of devices often sell different products into different
+   regional markets.  Which product is available in which market can be
+   driven by price differentials, support issues (some markets may
+   require manuals and tech support to be done in the local language),
+   and government export regulation (such as whether strong crypto is
+   permitted to be exported or permitted to be used in a particular
+   market).  When a domain owner obtains a device from a different
+   market (they can be new) and transfers it to a different location,
+   this is called a Grey Market.
+
+   A manufacturer could decide not to issue a voucher to an enterprise/
+   ISP based upon their location.  There are a number of ways that this
+   could be determined: from the geolocation of the registrar, from
+   sales channel knowledge about the customer, and from what products
+   are available or unavailable in that market.  If the device has a
+   GPS, the coordinates of the device could even be placed into an
+   extension of the voucher.
+
+   The above actions are not illegal, and not new.  Many manufacturers
+   have shipped crypto-weak (exportable) versions of firmware as the
+   default on equipment for decades.  The first task of an enterprise/
+   ISP has always been to login to a manufacturer system, show one's
+   "entitlement" (country information, proof that support payments have
+   been made), and receive either a new updated firmware or a license
+   key that will activate the correct firmware.
+
+   BRSKI permits the above process to be automated (in an autonomic
+   fashion) and therefore perhaps encourages this kind of
+   differentiation by reducing the cost of doing it.
+
+   An issue that manufacturers will need to deal with in the above
+   automated process is when a device is shipped to one country with one
+   set of rules (or laws or entitlements), but the domain registry is in
+   another one.  Which rules apply is something that will have to be
+   worked out: the manufacturer could believe they are dealing with Grey
+   Market equipment when they are simply dealing with a global
+   enterprise.
+
+10.6.  Some Mitigations for Meddling by Manufacturers
+
+   The most obvious mitigation is not to buy the product.  Pick
+   manufacturers that are up front about their policies and who do not
+   change them gratuitously.
+
+   Section 7.4.3 describes some ways in which a manufacturer could
+   provide a mechanism to manage the trust anchors and built-in
+   certificates (IDevID) as an extension.  There are a variety of
+   mechanisms, and some may take a substantial amount of work to get
+   exactly correct.  These mechanisms do not change the flow of the
+   protocol described here but rather allow the starting trust
+   assumptions to be changed.  This is an area for future
+   standardization work.
+
+   Replacement of the voucher validation anchors (usually pointing to
+   the original manufacturer's MASA) with those of the new owner permits
+   the new owner to issue vouchers to subsequent owners.  This would be
+   done by having the selling (old) owner run a MASA.
+
+   The BRSKI protocol depends upon a trust anchor and an identity on the
+   device.  Management of these entities facilitates a few new
+   operational modes without making any changes to the BRSKI protocol.
+   Those modes include: offline modes where the domain owner operates an
+   internal MASA for all devices, resell modes where the first domain
+   owner becomes the MASA for the next (resold-to) domain owner, and
+   services where an aggregator acquires a large variety of devices and
+   then acts as a pseudonymized MASA for a variety of devices from a
+   variety of manufacturers.
+
+   Although replacement of the IDevID is not required for all modes
+   described above, a manufacturer could support such a thing.  Some may
+   wish to consider replacement of the IDevID as an indication that the
+   device's warranty is terminated.  For others, the privacy
+   requirements of some deployments might consider this a standard
+   operating practice.
+
+   As discussed at the end of Section 5.8.1, new work could be done to
+   use a distributed consensus technology for the audit-log.  This would
+   permit the audit-log to continue to be useful, even when there is a
+   chain of MASA due to changes of ownership.
+
+10.7.  Death of a Manufacturer
+
+   A common concern has been that a manufacturer could go out of
+   business, leaving owners of devices unable to get new vouchers for
+   existing products.  Said products might have been previously deployed
+   but need to be reinitialized, used, or kept in a warehouse as long-
+   term spares.
+
+   The MASA was named the Manufacturer *Authorized* Signing Authority to
+   emphasize that it need not be the manufacturer itself that performs
+   this.  It is anticipated that specialist service providers will come
+   to exist that deal with the creation of vouchers in much the same way
+   that many companies have outsourced email, advertising, and
+   janitorial services.
+
+   Further, it is expected that as part of any service agreement, the
+   manufacturer would arrange to escrow appropriate private keys such
+   that a MASA service could be provided by a third party.  This has
+   routinely been done for source code for decades.
+
+11.  Security Considerations
+
+   This document details a protocol for bootstrapping that balances
+   operational concerns against security concerns.  As detailed in the
+   introduction, and touched on again in Section 7, the protocol allows
+   for reduced security modes.  These attempt to deliver additional
+   control to the local administrator and owner in cases where less
+   security provides operational benefits.  This section goes into more
+   detail about a variety of specific considerations.
+
+   To facilitate logging and administrative oversight, in addition to
+   triggering registrar verification of MASA logs, the pledge reports on
+   the voucher parsing status to the registrar.  In the case of a
+   failure, this information is informative to a potentially malicious
+   registrar.  This is mandated anyway because of the operational
+   benefits of an informed administrator in cases where the failure is
+   indicative of a problem.  The registrar is RECOMMENDED to verify MASA
+   logs if voucher status telemetry is not received.
+
+   To facilitate truly limited clients, EST requires that the client
+   MUST support a client authentication model (see [RFC7030],
+   Section 3.3.2); Section 7 updates these requirements by stating that
+   the registrar MAY choose to accept devices that fail cryptographic
+   authentication.  This reflects current (poor) practices in shipping
+   devices without a cryptographic identity that are NOT RECOMMENDED.
+
+   During the provisional period of the connection, the pledge MUST
+   treat all HTTP header and content data as untrusted data.  HTTP
+   libraries are regularly exposed to non-secured HTTP traffic: mature
+   libraries should not have any problems.
+
+   Pledges might chose to engage in protocol operations with multiple
+   discovered registrars in parallel.  As noted above, they will only do
+   so with distinct nonce values, but the end result could be multiple
+   vouchers issued from the MASA if all registrars attempt to claim the
+   device.  This is not a failure, and the pledge chooses whichever
+   voucher to accept based on internal logic.  The registrars verifying
+   log information will see multiple entries and take this into account
+   for their analytic purposes.
+
+11.1.  Denial of Service (DoS) against MASA
+
+   There are use cases where the MASA could be unavailable or
+   uncooperative to the registrar.  They include active DoS attacks,
+   planned and unplanned network partitions, changes to MASA policy, or
+   other instances where MASA policy rejects a claim.  These introduce
+   an operational risk to the registrar owner in that MASA behavior
+   might limit the ability to bootstrap a pledge device.  For example,
+   this might be an issue during disaster recovery.  This risk can be
+   mitigated by registrars that request and maintain long-term copies of
+   "nonceless" vouchers.  In that way, they are guaranteed to be able to
+   bootstrap their devices.
+
+   The issuance of nonceless vouchers themselves creates a security
+   concern.  If the registrar of a previous domain can intercept
+   protocol communications, then it can use a previously issued
+   nonceless voucher to establish management control of a pledge device
+   even after having sold it.  This risk is mitigated by recording the
+   issuance of such vouchers in the MASA audit-log that is verified by
+   the subsequent registrar and by pledges only bootstrapping when in a
+   factory default state.  This reflects a balance between enabling MASA
+   independence during future bootstrapping and the security of
+   bootstrapping itself.  Registrar control over requesting and auditing
+   nonceless vouchers allows device owners to choose an appropriate
+   balance.
+
+   The MASA is exposed to DoS attacks wherein attackers claim an
+   unbounded number of devices.  Ensuring a registrar is representative
+   of a valid manufacturer customer, even without validating ownership
+   of specific pledge devices, helps to mitigate this.  Pledge
+   signatures on the pledge voucher-request, as forwarded by the
+   registrar in the prior-signed-voucher-request field of the registrar
+   voucher-request, significantly reduce this risk by ensuring the MASA
+   can confirm proximity between the pledge and the registrar making the
+   request.  Supply-chain integration ("know your customer") is an
+   additional step that MASA providers and device vendors can explore.
+
+11.2.  DomainID Must Be Resistant to Second-Preimage Attacks
+
+   The domainID is used as the reference in the audit-log to the domain.
+   The domainID is expected to be calculated by a hash that is resistant
+   to a second-preimage attack.  Such an attack would allow a second
+   registrar to create audit-log entries that are fake.
+
+11.3.  Availability of Good Random Numbers
+
+   The nonce used by the pledge in the voucher-request SHOULD be
+   generated by a Strong Cryptographic Sequence ([RFC4086],
+   Section 6.2).  TLS has a similar requirement.
+
+   In particular, implementations should pay attention to the advance in
+   [RFC4086]; see Sections 3 and, in particular, 3.4.  The random seed
+   used by a device at boot MUST be unique across all devices and all
+   bootstraps.  Resetting a device to factory default state does not
+   obviate this requirement.
+
+11.4.  Freshness in Voucher-Requests
+
+   A concern has been raised that the pledge voucher-request should
+   contain some content (a nonce) provided by the registrar and/or MASA
+   in order for those actors to verify that the pledge voucher-request
+   is fresh.
+
+   There are a number of operational problems with getting a nonce from
+   the MASA to the pledge.  It is somewhat easier to collect a random
+   value from the registrar, but as the registrar is not yet vouched
+   for, such a registrar nonce has little value.  There are privacy and
+   logistical challenges to addressing these operational issues, so if
+   such a thing were to be considered, it would have to provide some
+   clear value.  This section examines the impacts of not having a fresh
+   pledge voucher-request.
+
+   Because the registrar authenticates the pledge, a full MITM attack is
+   not possible, despite the provisional TLS authentication by the
+   pledge (see Section 5.)  Instead, we examine the case of a fake
+   registrar (Rm) that communicates with the pledge in parallel or in
+   close-time proximity with the intended registrar.  (This scenario is
+   intentionally supported as described in Section 4.1.)
+
+   The fake registrar (Rm) can obtain a voucher signed by the MASA
+   either directly or through arbitrary intermediaries.  Assuming that
+   the MASA accepts the registrar voucher-request (because either the Rm
+   is collaborating with a legitimate registrar according to supply-
+   chain information or the MASA is in audit-log only mode), then a
+   voucher linking the pledge to the registrar Rm is issued.
+
+   Such a voucher, when passed back to the pledge, would link the pledge
+   to registrar Rm and permit the pledge to end the provisional state.
+   It now trusts the Rm and, if it has any security vulnerabilities
+   leverageable by an Rm with full administrative control, can be
+   assumed to be a threat against the intended registrar.
+
+   This flow is mitigated by the intended registrar verifying the audit-
+   logs available from the MASA as described in Section 5.8.  The Rm
+   might chose to collect a voucher-request but wait until after the
+   intended registrar completes the authorization process before
+   submitting it.  This pledge voucher-request would be "stale" in that
+   it has a nonce that no longer matches the internal state of the
+   pledge.  In order to successfully use any resulting voucher, the Rm
+   would need to remove the stale nonce or anticipate the pledge's
+   future nonce state.  Reducing the possibility of this is why the
+   pledge is mandated to generate a strong random or pseudo-random
+   number nonce.
+
+   Additionally, in order to successfully use the resulting voucher, the
+   Rm would have to attack the pledge and return it to a bootstrapping-
+   enabled state.  This would require wiping the pledge of current
+   configuration and triggering a rebootstrapping of the pledge.  This
+   is no more likely than simply taking control of the pledge directly,
+   but if this is a consideration, it is RECOMMENDED that the target
+   network take the following steps:
+
+   *  Ongoing network monitoring for unexpected bootstrapping attempts
+      by pledges.
+
+   *  Retrieval and examination of MASA log information upon the
+      occurrence of any such unexpected events.  The Rm will be listed
+      in the logs along with nonce information for analysis.
+
+11.5.  Trusting Manufacturers
+
+   The BRSKI extensions to EST permit a new pledge to be completely
+   configured with domain-specific trust anchors.  The link from built-
+   in manufacturer-provided trust anchors to domain-specific trust
+   anchors is mediated by the signed voucher artifact.
+
+   If the manufacturer's IDevID signing key is not properly validated,
+   then there is a risk that the network will accept a pledge that
+   should not be a member of the network.  As the address of the
+   manufacturer's MASA is provided in the IDevID using the extension
+   from Section 2.3, the malicious pledge will have no problem
+   collaborating with its MASA to produce a completely valid voucher.
+
+   BRSKI does not, however, fundamentally change the trust model from
+   domain owner to manufacturer.  Assuming that the pledge used its
+   IDevID with EST [RFC7030] and BRSKI, the domain (registrar) still
+   needs to trust the manufacturer.
+
+   Establishing this trust between domain and manufacturer is outside
+   the scope of BRSKI.  There are a number of mechanisms that can be
+   adopted including:
+
+   *  Manually configuring each manufacturer's trust anchor.
+
+   *  A TOFU mechanism.  A human would be queried upon seeing a
+      manufacturer's trust anchor for the first time, and then the trust
+      anchor would be installed to the trusted store.  There are risks
+      with this; even if the key to name mapping is validated using
+      something like the WebPKI, there remains the possibility that the
+      name is a look alike: e.g., dem0.example. vs.  demO.example.
+
+   *  scanning the trust anchor from a QR code that came with the
+      packaging (this is really a manual TOFU mechanism).
+
+   *  some sales integration processing where trust anchors are provided
+      as part of the sales process, probably included in a digital
+      packing "slip", or a sales invoice.
+
+   *  consortium membership, where all manufacturers of a particular
+      device category (e.g, a light bulb or a cable modem) are signed by
+      a CA specifically for this.  This is done by CableLabs today.  It
+      is used for authentication and authorization as part of
+      [docsisroot] and [TR069].
+
+   The existing WebPKI provides a reasonable anchor between manufacturer
+   name and public key.  It authenticates the key.  It does not provide
+   a reasonable authorization for the manufacturer, so it is not
+   directly usable on its own.
+
+11.6.  Manufacturer Maintenance of Trust Anchors
+
+   BRSKI depends upon the manufacturer building in trust anchors to the
+   pledge device.  The voucher artifact that is signed by the MASA will
+   be validated by the pledge using that anchor.  This implies that the
+   manufacturer needs to maintain access to a signing key that the
+   pledge can validate.
+
+   The manufacturer will need to maintain the ability to make signatures
+   that can be validated for the lifetime that the device could be
+   onboarded.  Whether this onboarding lifetime is less than the device
+   lifetime depends upon how the device is used.  An inventory of
+   devices kept in a warehouse as spares might not be onboarded for many
+   decades.
+
+   There are good cryptographic hygiene reasons why a manufacturer would
+   not want to maintain access to a private key for many decades.  A
+   manufacturer in that situation can leverage a long-term CA anchor,
+   built-in to the pledge, and then a certificate chain may be
+   incorporated using the normal CMS certificate set.  This may increase
+   the size of the voucher artifacts, but that is not a significant
+   issue in non-constrained environments.
+
+   There are a few other operational variations that manufacturers could
+   consider.  For instance, there is no reason that every device need
+   have the same set of trust anchors preinstalled.  Devices built in
+   different factories, or on different days, or in any other
+   consideration, could have different trust anchors built in, and the
+   record of which batch the device is in would be recorded in the asset
+   database.  The manufacturer would then know which anchor to sign an
+   artifact against.
+
+   Aside from the concern about long-term access to private keys, a
+   major limiting factor for the shelf life of many devices will be the
+   age of the cryptographic algorithms included.  A device produced in
+   2019 will have hardware and software capable of validating algorithms
+   common in 2019 and will have no defense against attacks (both quantum
+   and von Neumann brute-force attacks) that have not yet been invented.
+   This concern is orthogonal to the concern about access to private
+   keys, but this concern likely dominates and limits the life span of a
+   device in a warehouse.  If any update to the firmware to support new
+   cryptographic mechanisms were possible (while the device was in a
+   warehouse), updates to trust anchors would also be done at the same
+   time.
+
+   The set of standard operating procedures for maintaining high-value
+   private keys is well documented.  For instance, the WebPKI provides a
+   number of options for audits in [cabforumaudit], and the DNSSEC root
+   operations are well documented in [dnssecroot].
+
+   It is not clear if manufacturers will take this level of precaution,
+   or how strong the economic incentives are to maintain an appropriate
+   level of security.
+
+   The next section examines the risk due to a compromised manufacturer
+   IDevID signing key.  This is followed by examination of the risk due
+   to a compromised MASA key.  The third section below examines the
+   situation where a MASA web server itself is under attacker control,
+   but the MASA signing key itself is safe in a not-directly connected
+   hardware module.
+
+11.6.1.  Compromise of Manufacturer IDevID Signing Keys
+
+   An attacker that has access to the key that the manufacturer uses to
+   sign IDevID certificates can create counterfeit devices.  Such
+   devices can claim to be from a particular manufacturer but can be
+   entirely different devices: Trojan horses in effect.
+
+   As the attacker controls the MASA URL in the certificate, the
+   registrar can be convinced to talk to the attacker's MASA.  The
+   registrar does not need to be in any kind of promiscuous mode to be
+   vulnerable.
+
+   In addition to creating fake devices, the attacker may also be able
+   to issue revocations for existing certificates if the IDevID
+   certificate process relies upon CRL lists that are distributed.
+
+   There does not otherwise seem to be any risk from this compromise to
+   devices that are already deployed or that are sitting locally in
+   boxes waiting for deployment (local spares).  The issue is that
+   operators will be unable to trust devices that have been in an
+   uncontrolled warehouse as they do not know if those are real devices.
+
+11.6.2.  Compromise of MASA Signing Keys
+
+   There are two periods of time in which to consider: when the MASA key
+   has fallen into the hands of an attacker and after the MASA
+   recognizes that the key has been compromised.
+
+11.6.2.1.  Attacker Opportunities with a Compromised MASA Key
+
+   An attacker that has access to the MASA signing key could create
+   vouchers.  These vouchers could be for existing deployed devices or
+   for devices that are still in a warehouse.  In order to exploit these
+   vouchers, two things need to occur: the device has to go through a
+   factory default boot cycle, and the registrar has to be convinced to
+   contact the attacker's MASA.
+
+   If the attacker controls a registrar that is visible to the device,
+   then there is no difficulty in delivery of the false voucher.  A
+   possible practical example of an attack like this would be in a data
+   center, at an ISP peering point (whether a public IX or a private
+   peering point).  In such a situation, there are already cables
+   attached to the equipment that lead to other devices (the peers at
+   the IX), and through those links, the false voucher could be
+   delivered.  The difficult part would be to put the device through a
+   factory reset.  This might be accomplished through social engineering
+   of data center staff.  Most locked cages have ventilation holes, and
+   possibly a long "paperclip" could reach through to depress a factory
+   reset button.  Once such a piece of ISP equipment has been
+   compromised, it could be used to compromise equipment that it was
+   connected to (through long haul links even), assuming that those
+   pieces of equipment could also be forced through a factory reset.
+
+   The above scenario seems rather unlikely as it requires some element
+   of physical access; but if there was a remote exploit that did not
+   cause a direct breach, but rather a fault that resulted in a factory
+   reset, this could provide a reasonable path.
+
+   The above deals with ANI uses of BRSKI.  For cases where IEEE 802.11
+   or 802.15.4 is involved, the need to connect directly to the device
+   is eliminated, but the need to do a factory reset is not.  Physical
+   possession of the device is not required as above, provided that
+   there is some way to force a factory reset.  With some consumer
+   devices that have low overall implementation quality, end users might
+   be familiar with the need to reset the device regularly.
+
+   The authors are unable to come up with an attack scenario where a
+   compromised voucher signature enables an attacker to introduce a
+   compromised pledge into an existing operator's network.  This is the
+   case because the operator controls the communication between
+   registrar and MASA, and there is no opportunity to introduce the fake
+   voucher through that conduit.
+
+11.6.2.2.  Risks after Key Compromise is Known
+
+   Once the operator of the MASA realizes that the voucher signing key
+   has been compromised, it has to do a few things.
+
+   First, it MUST issue a firmware update to all devices that had that
+   key as a trust anchor, such that they will no longer trust vouchers
+   from that key.  This will affect devices in the field that are
+   operating, but those devices, being in operation, are not performing
+   onboarding operations, so this is not a critical patch.
+
+   Devices in boxes (in warehouses) are vulnerable and remain vulnerable
+   until patched.  An operator would be prudent to unbox the devices,
+   onboard them in a safe environment, and then perform firmware
+   updates.  This does not have to be done by the end-operator; it could
+   be done by a distributor that stores the spares.  A recommended
+   practice for high-value devices (which typically have a <4hr service
+   window) may be to validate the device operation on a regular basis
+   anyway.
+
+   If the onboarding process includes attestations about firmware
+   versions, then through that process, the operator would be advised to
+   upgrade the firmware before going into production.  Unfortunately,
+   this does not help against situations where the attacker operates
+   their own registrar (as listed above).
+
+   The need for short-lived vouchers is explained in [RFC8366],
+   Section 6.1.  The nonce guarantees freshness, and the short-lived
+   nature of the voucher means that the window to deliver a fake voucher
+   is very short.  A nonceless, long-lived voucher would be the only
+   option for the attacker, and devices in the warehouse would be
+   vulnerable to such a thing.
+
+   A key operational recommendation is for manufacturers to sign
+   nonceless, long-lived vouchers with a different key than what is used
+   to sign short-lived vouchers.  That key needs significantly better
+   protection.  If both keys come from a common trust-anchor (the
+   manufacturer's CA), then a compromise of the manufacturer's CA would
+   compromise both keys.  Such a compromise of the manufacturer's CA
+   likely compromises all keys outlined in this section.
+
+11.6.3.  Compromise of MASA Web Service
+
+   An attacker that takes over the MASA web service can inflict a number
+   of attacks.  The most obvious one is simply to take the database
+   listing of customers and devices and sell the data to other attackers
+   who will now know where to find potentially vulnerable devices.
+
+   The second most obvious thing that the attacker can do is to kill the
+   service, or make it operate unreliably, making customers frustrated.
+   This could have a serious effect on the ability to deploy new
+   services by customers and would be a significant issue during
+   disaster recovery.
+
+   While the compromise of the MASA web service may lead to the
+   compromise of the MASA voucher signing key, if the signing occurs
+   offboard (such as in a hardware signing module (HSM)), then the key
+   may well be safe, but control over it resides with the attacker.
+
+   Such an attacker can issue vouchers for any device presently in
+   service.  Said device still needs to be convinced to go through a
+   factory reset process before an attack.
+
+   If the attacker has access to a key that is trusted for long-lived
+   nonceless vouchers, then they could issue vouchers for devices that
+   are not yet in service.  This attack may be very hard to verify as it
+   would involve doing firmware updates on every device in warehouses (a
+   potentially ruinously expensive process); a manufacturer might be
+   reluctant to admit this possibility.
+
+11.7.  YANG Module Security Considerations
+
+   As described in Section 7.4 (Security Considerations) of [RFC8366],
+   the YANG module specified in this document defines the schema for
+   data that is subsequently encapsulated by a CMS signed-data content
+   type, as described in Section 5 of [RFC5652].  As such, all of the
+   YANG-modeled data is protected from modification.
+
+   The use of YANG to define data structures, via the "yang-data"
+   statement, is relatively new and distinct from the traditional use of
+   YANG to define an API accessed by network management protocols such
+   as NETCONF [RFC6241] and RESTCONF [RFC8040].  For this reason, these
+   guidelines do not follow the template described by Section 3.7 of
+   [RFC8407].
+
+12.  References
+
+12.1.  Normative References
+
+   [IDevID]   IEEE, "IEEE Standard for Local and metropolitan area
+              networks - Secure Device Identity", IEEE 802.1AR,
+              <https://1.ieee802.org/security/802-1ar>.
+
+   [ITU.X690] ITU-T, "Information Technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2015,
+              August 2015, <https://www.itu.int/rec/T-REC-X.690>.
+
+   [REST]     Fielding, R.F., "Architectural Styles and the Design of
+              Network-based Software Architectures", 2000,
+              <http://www.ics.uci.edu/~fielding/pubs/dissertation/
+              fielding_dissertation.pdf>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
+              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
+              <https://www.rfc-editor.org/info/rfc3339>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
+              <https://www.rfc-editor.org/info/rfc3748>.
+
+   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+              Configuration of IPv4 Link-Local Addresses", RFC 3927,
+              DOI 10.17487/RFC3927, May 2005,
+              <https://www.rfc-editor.org/info/rfc3927>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC4519]  Sciberras, A., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Schema for User Applications", RFC 4519,
+              DOI 10.17487/RFC4519, June 2006,
+              <https://www.rfc-editor.org/info/rfc4519>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <https://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <https://www.rfc-editor.org/info/rfc4862>.
+
+   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
+              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
+              <https://www.rfc-editor.org/info/rfc5272>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <https://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <https://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+              2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+              DOI 10.17487/RFC6762, February 2013,
+              <https://www.rfc-editor.org/info/rfc6762>.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
+              <https://www.rfc-editor.org/info/rfc6763>.
+
+   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
+              "Enrollment over Secure Transport", RFC 7030,
+              DOI 10.17487/RFC7030, October 2013,
+              <https://www.rfc-editor.org/info/rfc7030>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <https://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+              DOI 10.17487/RFC7231, June 2014,
+              <https://www.rfc-editor.org/info/rfc7231>.
+
+   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
+              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
+              2015, <https://www.rfc-editor.org/info/rfc7469>.
+
+   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+              RFC 7950, DOI 10.17487/RFC7950, August 2016,
+              <https://www.rfc-editor.org/info/rfc7950>.
+
+   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
+              RFC 7951, DOI 10.17487/RFC7951, August 2016,
+              <https://www.rfc-editor.org/info/rfc7951>.
+
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
+              "A Voucher Artifact for Bootstrapping Protocols",
+              RFC 8366, DOI 10.17487/RFC8366, May 2018,
+              <https://www.rfc-editor.org/info/rfc8366>.
+
+   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
+              Control Plane for Stable Connectivity of Network
+              Operations, Administration, and Maintenance (OAM)",
+              RFC 8368, DOI 10.17487/RFC8368, May 2018,
+              <https://www.rfc-editor.org/info/rfc8368>.
+
+   [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
+              Documents Containing YANG Data Models", BCP 216, RFC 8407,
+              DOI 10.17487/RFC8407, October 2018,
+              <https://www.rfc-editor.org/info/rfc8407>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
+              Definition Language (CDDL): A Notational Convention to
+              Express Concise Binary Object Representation (CBOR) and
+              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
+              June 2019, <https://www.rfc-editor.org/info/rfc8610>.
+
+   [RFC8951]  Richardson, M., Werner, T., and W. Pan, "Clarification of
+              Enrollment over Secure Transport (EST): Transfer Encodings
+              and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020,
+              <https://www.rfc-editor.org/info/rfc8951>.
+
+   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
+              "Temporary Address Extensions for Stateless Address
+              Autoconfiguration in IPv6", RFC 8981,
+              DOI 10.17487/RFC8981, February 2021,
+              <https://www.rfc-editor.org/info/rfc8981>.
+
+   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
+              Autonomic Signaling Protocol (GRASP)", RFC 8990,
+              DOI 10.17487/RFC8990, May 2021,
+              <https://www.rfc-editor.org/rfc/rfc8990>.
+
+   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
+              Autonomic Control Plane (ACP)", RFC 8994,
+              DOI 10.17487/RFC8994, May 2021,
+              <https://www.rfc-editor.org/rfc/rfc8994>.
+
+12.2.  Informative References
+
+   [ACE-COAP-EST]
+              van der Stok, P., Kampanakis, P., Richardson, M., and S.
+              Raza, "EST over secure CoAP (EST-coaps)", Work in
+              Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
+              January 2020,
+              <https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.
+
+   [ANIMA-CONSTRAINED-VOUCHER]
+              Richardson, M., van der Stok, P., Kampanakis, P., and E.
+              Dijk, "Constrained Voucher Artifacts for Bootstrapping
+              Protocols", Work in Progress, Internet-Draft, draft-ietf-
+              anima-constrained-voucher-10, 21 February 2021,
+              <https://tools.ietf.org/html/draft-ietf-anima-constrained-
+              voucher-10>.
+
+   [ANIMA-STATE]
+              Richardson, M., "Considerations for stateful vs stateless
+              join router in ANIMA bootstrap", Work in Progress,
+              Internet-Draft, draft-richardson-anima-state-for-
+              joinrouter-03, 22 September 2020,
+              <https://tools.ietf.org/html/draft-richardson-anima-state-
+              for-joinrouter-03>.
+
+   [brewski]  Urban Dictionary, "brewski", March 2003,
+              <https://www.urbandictionary.com/define.php?term=brewski>.
+
+   [cabforumaudit]
+              CA/Browser Forum, "Information for Auditors and
+              Assessors", August 2019, <https://cabforum.org/
+              information-for-auditors-and-assessors/>.
+
+   [Dingledine]
+              Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
+              Second-Generation Onion Router", August 2004,
+              <https://svn-archive.torproject.org/svn/projects/design-
+              paper/tor-design.pdf>.
+
+   [dnssecroot]
+              "DNSSEC Practice Statement for the Root Zone ZSK
+              Operator", December 2017,
+              <https://www.iana.org/dnssec/procedures/zsk-operator/dps-
+              zsk-operator-v2.1.pdf>.
+
+   [docsisroot]
+              "CableLabs Digital Certificate Issuance Service", February
+              2018, <https://www.cablelabs.com/resources/digital-
+              certificate-issuance-service/>.
+
+   [imprinting]
+              Wikipedia, "Imprinting (psychology)", January 2021,
+              <https://en.wikipedia.org/w/
+              index.php?title=Imprinting_(psychology)&=999211441>.
+
+   [IoTstrangeThings]
+              ESET, "IoT of toys stranger than fiction: Cybersecurity
+              and data privacy update", March 2017,
+              <https://www.welivesecurity.com/2017/03/03/internet-of-
+              things-security-privacy-iot-update/>.
+
+   [livingwithIoT]
+              Silicon Republic, "What is it actually like to live in a
+              house filled with IoT devices?", February 2018,
+              <https://www.siliconrepublic.com/machines/iot-smart-
+              devices-reality>.
+
+   [minerva]  Richardson, M., "Minerva reference implementation for
+              BRSKI", 2020, <https://minerva.sandelman.ca/>.
+
+   [minervagithub]
+              "ANIMA Minerva toolkit",
+              <https://github.com/ANIMAgus-minerva>.
+
+   [openssl]  OpenSSL, "OpenSSL X509 Utility", September 2019,
+              <https://www.openssl.org/docs/man1.1.1/man1/openssl-
+              x509.html/>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <https://www.rfc-editor.org/info/rfc2131>.
+
+   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations",
+              RFC 2663, DOI 10.17487/RFC2663, August 1999,
+              <https://www.rfc-editor.org/info/rfc2663>.
+
+   [RFC5209]  Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
+              Tardo, "Network Endpoint Assessment (NEA): Overview and
+              Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
+              <https://www.rfc-editor.org/info/rfc5209>.
+
+   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
+              Galperin, S., and C. Adams, "X.509 Internet Public Key
+              Infrastructure Online Certificate Status Protocol - OCSP",
+              RFC 6960, DOI 10.17487/RFC6960, June 2013,
+              <https://www.rfc-editor.org/info/rfc6960>.
+
+   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
+              Multiple Certificate Status Request Extension", RFC 6961,
+              DOI 10.17487/RFC6961, June 2013,
+              <https://www.rfc-editor.org/info/rfc6961>.
+
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <https://www.rfc-editor.org/info/rfc7228>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <https://www.rfc-editor.org/info/rfc7258>.
+
+   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
+              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
+              December 2014, <https://www.rfc-editor.org/info/rfc7435>.
+
+   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
+              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
+              Networking: Definitions and Design Goals", RFC 7575,
+              DOI 10.17487/RFC7575, June 2015,
+              <https://www.rfc-editor.org/info/rfc7575>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+              <https://www.rfc-editor.org/info/rfc8340>.
+
+   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
+              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
+              <https://www.rfc-editor.org/info/rfc8615>.
+
+   [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
+              L., and J. Nobre, "A Reference Model for Autonomic
+              Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
+              <https://www.rfc-editor.org/info/rfc8993>.
+
+   [slowloris]
+              Wikipedia, "Slowloris (computer security)", January 2021,
+              <https://en.wikipedia.org/w/index.php?title=Slowloris_(com
+              puter_security)&oldid=1001473290/>.
+
+   [softwareescrow]
+              Wikipedia, "Source code escrow", March 2020,
+              <https://en.wikipedia.org/w/
+              index.php?title=Source_code_escrow&oldid=948073074>.
+
+   [Stajano99theresurrecting]
+              Stajano, F. and R. Anderson, "The Resurrecting Duckling:
+              Security Issues for Ad-hoc Wireless Networks", 1999,
+              <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
+              duckling.pdf>.
+
+   [TR069]    Broadband Forum, "CPE WAN Management Protocol", TR-069,
+              Issue 1, Amendment 6, March 2018, <https://www.broadband-
+              forum.org/download/TR-069_Amendment-6.pdf>.
+
+   [W3C.capability-urls]
+              Tennison, J., "Good Practices for Capability URLs", W3C
+              First Public Working Draft, World Wide Web Consortium WD 
+              WD-capability-urls-20140218, February 2014,
+              <https://www.w3.org/TR/2014/WD-capability-urls>.
+
+   [YANG-KEYSTORE]
+              Watsen, K., "A YANG Data Model for a Keystore", Work in
+              Progress, Internet-Draft, draft-ietf-netconf-keystore-22,
+              18 May 2021, <https://tools.ietf.org/html/draft-ietf-
+              netconf-keystore-22>.
+
+Appendix A.  IPv4 and Non-ANI Operations
+
+   The specification of BRSKI in Section 4 intentionally covers only the
+   mechanisms for an IPv6 pledge using link-local addresses.  This
+   section describes non-normative extensions that can be used in other
+   environments.
+
+A.1.  IPv4 Link-Local Addresses
+
+   Instead of an IPv6 link-local address, an IPv4 address may be
+   generated using "Dynamic Configuration of IPv4 Link-Local Addresses"
+   [RFC3927].
+
+   In the case where an IPv4 link-local address is formed, the bootstrap
+   process would continue, as in an IPv6 case, by looking for a
+   (circuit) proxy.
+
+A.2.  Use of DHCPv4
+
+   The pledge MAY obtain an IP address via DHCP ([RFC2131].  The DHCP-
+   provided parameters for the Domain Name System can be used to perform
+   DNS operations if all local discovery attempts fail.
+
+Appendix B.  mDNS / DNS-SD Proxy Discovery Options
+
+   Pledge discovery of the proxy (Section 4.1) MAY be performed with
+   DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to
+   discover the proxy at "_brski-proxy._tcp.local.".
+
+   Proxy discovery of the registrar (Section 4.3) MAY be performed with
+   DNS-based Service Discovery over Multicast DNS to discover registrars
+   by searching for the service "_brski-registrar._tcp.local.".
+
+   To prevent unacceptable levels of network traffic, when using mDNS,
+   the congestion avoidance mechanisms specified in [RFC6762], Section 7
+   MUST be followed.  The pledge SHOULD listen for an unsolicited
+   broadcast response as described in [RFC6762].  This allows devices to
+   avoid announcing their presence via mDNS broadcasts and instead
+   silently join a network by watching for periodic unsolicited
+   broadcast responses.
+
+   Discovery of the registrar MAY also be performed with DNS-based
+   Service Discovery by searching for the service "_brski-
+   registrar._tcp.example.com".  In this case, the domain "example.com"
+   is discovered as described in [RFC6763], Section 11 (Appendix A.2 of
+   this document suggests the use of DHCP parameters).
+
+   If no local proxy or registrar service is located using the GRASP
+   mechanisms or the above-mentioned DNS-based Service Discovery
+   methods, the pledge MAY contact a well-known manufacturer-provided
+   bootstrapping server by performing a DNS lookup using a well-known
+   URI such as "brski-registrar.manufacturer.example.com".  The details
+   of the URI are manufacturer specific.  Manufacturers that leverage
+   this method on the pledge are responsible for providing the registrar
+   service.  Also see Section 2.7.
+
+   The current DNS services returned during each query are maintained
+   until bootstrapping is completed.  If bootstrapping fails and the
+   pledge returns to the Discovery state, it picks up where it left off
+   and continues attempting bootstrapping.  For example, if the first
+   Multicast DNS _bootstrapks._tcp.local response doesn't work, then the
+   second and third responses are tried.  If these fail, the pledge
+   moves on to normal DNS-based Service Discovery.
+
+Appendix C.  Example Vouchers
+
+   Three entities are involved in a voucher: the MASA issues (signs) it,
+   the registrar's public key is mentioned in it, and the pledge
+   validates it.  In order to provide reproducible examples, the public
+   and private keys for an example MASA and registrar are listed first.
+
+   The keys come from an open source reference implementation of BRSKI,
+   called "Minerva" [minerva].  It is available on GitHub
+   [minervagithub].  The keys presented here are used in the unit and
+   integration tests.  The MASA code is called "highway", the registrar
+   code is called "fountain", and the example client is called "reach".
+
+   The public key components of each are presented as base64
+   certificates and are decoded by openssl's x509 utility so that the
+   extensions can be seen.  This was version 1.1.1c of the library and
+   utility of [openssl].
+
+C.1.  Keys Involved
+
+   The manufacturer has a CA that signs the pledge's IDevID.  In
+   addition, the Manufacturer's signing authority (the MASA) signs the
+   vouchers, and that certificate must distributed to the devices at
+   manufacturing time so that vouchers can be validated.
+
+C.1.1.  Manufacturer Certification Authority for IDevID Signatures
+
+   This private key is the CA that signs IDevID certificates:
+
+   <CODE BEGINS> file "vendor.key"
+   -----BEGIN EC PRIVATE KEY-----
+   MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G
+   8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
+   L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
+   juF8QkoAbT8pMrY83MS8y76wZ7AalNQ=
+   -----END EC PRIVATE KEY-----
+   <CODE ENDS>
+
+   This public key validates IDevID certificates:
+
+   file: examples/vendor.key
+
+   <CODE BEGINS> file "vendor.cert"
+   Certificate:
+       Data:
+           Version: 3 (0x2)
+           Serial Number: 1216069925 (0x487bc125)
+           Signature Algorithm: ecdsa-with-SHA256
+           Issuer: CN = highway-test.example.com CA
+           Validity
+               Not Before: Apr 13 20:34:24 2021 GMT
+               Not After : Apr 13 20:34:24 2023 GMT
+           Subject: CN = highway-test.example.com CA
+           Subject Public Key Info:
+               Public Key Algorithm: id-ecPublicKey
+                   Public-Key: (384 bit)
+                   pub:
+                       04:2e:e7:fc:a4:b4:96:c5:2e:33:02:f3:b8:7b:6f:
+                       ec:93:ad:e1:6e:17:c1:b0:7b:02:87:2f:89:92:d2:
+                       bd:1d:54:04:2e:6e:a0:d4:41:c4:eb:8e:fa:57:ad:
+                       70:a9:4e:88:e2:2c:2c:e0:a7:c7:f3:91:c5:03:91:
+                       9f:4b:0f:f3:3d:d0:b0:e2:a6:22:cd:20:e9:0f:8e:
+                       e1:7c:42:4a:00:6d:3f:29:32:b6:3c:dc:c4:bc:cb:
+                       be:b0:67:b0:1a:94:d4
+                   ASN1 OID: secp384r1
+                   NIST CURVE: P-384
+           X509v3 extensions:
+               X509v3 Basic Constraints: critical
+                   CA:TRUE
+               X509v3 Key Usage: critical
+                   Certificate Sign, CRL Sign
+               X509v3 Subject Key Identifier:
+                   5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76:
+                   8C:53:8A:08
+               X509v3 Authority Key Identifier:
+                   keyid:5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:
+                   80:76:8C:53:8A:08
+
+       Signature Algorithm: ecdsa-with-SHA256
+            30:64:02:30:60:37:a0:66:89:80:27:e1:0d:e5:43:9a:62:f1:
+            02:bc:0f:72:6d:a9:e9:cb:84:a5:c6:44:d3:41:9e:5d:ce:7d:
+            46:16:6e:15:de:f7:cc:e8:3e:61:f9:03:7c:20:c4:b7:02:30:
+            7f:e9:f3:12:bb:06:c6:24:00:2b:41:aa:21:6b:d8:25:ed:81:
+            07:11:ef:66:8f:06:bf:c8:be:f0:58:74:24:45:39:4d:04:fc:
+            31:69:6f:cf:db:fe:61:7b:c3:24:31:ff
+   -----BEGIN CERTIFICATE-----
+   MIIB3TCCAWSgAwIBAgIESHvBJTAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo
+   d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjAzNDI0WhcNMjMwNDEz
+   MjAzNDI0WjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0Ew
+   djAQBgcqhkjOPQIBBgUrgQQAIgNiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
+   L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
+   juF8QkoAbT8pMrY83MS8y76wZ7AalNSjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYD
+   VR0PAQH/BAQDAgEGMB0GA1UdDgQWBBReDKlSWozfqQ8DFOmW8YB2jFOKCDAfBgNV
+   HSMEGDAWgBReDKlSWozfqQ8DFOmW8YB2jFOKCDAKBggqhkjOPQQDAgNnADBkAjBg
+   N6BmiYAn4Q3lQ5pi8QK8D3JtqenLhKXGRNNBnl3OfUYWbhXe98zoPmH5A3wgxLcC
+   MH/p8xK7BsYkACtBqiFr2CXtgQcR72aPBr/IvvBYdCRFOU0E/DFpb8/b/mF7wyQx
+   /w==
+   -----END CERTIFICATE-----
+   <CODE ENDS>
+
+C.1.2.  MASA Key Pair for Voucher Signatures
+
+   The MASA is the Manufacturer Authorized Signing Authority.  This key
+   pair signs vouchers.  An example TLS certificate (see Section 5.4)
+   HTTP authentication is not provided as it is a common form.
+
+   This private key signs the vouchers that are presented below:
+
+   <CODE BEGINS> file "masa.key"
+   -----BEGIN EC PRIVATE KEY-----
+   MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49
+   AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+
+   gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ==
+   -----END EC PRIVATE KEY-----
+   <CODE ENDS>
+
+   This public key validates vouchers, and it has been signed by the CA
+   above:
+
+   file: examples/masa.key
+
+   <CODE BEGINS> file "masa.cert"
+   Certificate:
+       Data:
+           Version: 3 (0x2)
+           Serial Number: 193399345 (0xb870a31)
+           Signature Algorithm: ecdsa-with-SHA256
+           Issuer: CN = highway-test.example.com CA
+           Validity
+               Not Before: Apr 13 21:40:16 2021 GMT
+               Not After : Apr 13 21:40:16 2023 GMT
+           Subject: CN = highway-test.example.com MASA
+           Subject Public Key Info:
+               Public Key Algorithm: id-ecPublicKey
+                   Public-Key: (256 bit)
+                   pub:
+                       04:aa:04:15:a3:44:b9:e2:44:f8:c9:f9:1b:07:1b:
+                       a6:74:73:9c:1e:ba:6c:a9:b3:a9:30:a9:a2:32:59:
+                       f7:a0:1d:47:01:6d:b9:30:95:7e:82:a8:b8:b4:c1:
+                       5f:48:9d:22:13:0b:7c:92:cc:df:59:72:b8:ac:b8:
+                       09:4b:69:a7:a5
+                   ASN1 OID: prime256v1
+                   NIST CURVE: P-256
+           X509v3 extensions:
+               X509v3 Basic Constraints: critical
+                   CA:FALSE
+       Signature Algorithm: ecdsa-with-SHA256
+            30:66:02:31:00:ae:cb:61:2d:d4:5c:8d:6e:86:aa:0b:06:1d:
+            c6:d3:60:ba:32:73:36:25:d3:23:85:49:87:1c:ce:94:23:79:
+            1a:9e:41:55:24:1d:15:22:a1:48:bb:0a:c0:ab:3c:13:73:02:
+            31:00:86:3c:67:b3:95:a2:e2:e5:f9:ad:f9:1d:9c:c1:34:32:
+            78:f5:cf:ea:d5:47:03:9f:00:bf:d0:59:cb:51:c2:98:04:81:
+            24:8a:51:13:50:b1:75:b2:2f:9d:a8:b4:f4:b9
+   -----BEGIN CERTIFICATE-----
+   MIIBcDCB9qADAgECAgQLhwoxMAoGCCqGSM49BAMCMCYxJDAiBgNVBAMMG2hpZ2h3
+   YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0yMTA0MTMyMTQwMTZaFw0yMzA0MTMy
+   MTQwMTZaMCgxJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBNQVNB
+   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S54kT4yfkbBxumdHOcHrps
+   qbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpaMQMA4w
+   DAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEArsthLdRcjW6GqgsGHcbT
+   YLoyczYl0yOFSYcczpQjeRqeQVUkHRUioUi7CsCrPBNzAjEAhjxns5Wi4uX5rfkd
+   nME0Mnj1z+rVRwOfAL/QWctRwpgEgSSKURNQsXWyL52otPS5
+   -----END CERTIFICATE-----
+   <CODE ENDS>
+
+C.1.3.  Registrar Certification Authority
+
+   This CA enrolls the pledge once it is authorized, and it also signs
+   the registrar's certificate.
+
+   <CODE BEGINS> file "ownerca_secp384r1.key"
+   -----BEGIN EC PRIVATE KEY-----
+   MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R
+   EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW
+   gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd
+   0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ=
+   -----END EC PRIVATE KEY-----
+   <CODE ENDS>
+
+   The public key is indicated in a pledge voucher-request to show
+   proximity.
+
+   file: examples/ownerca_secp384r1.key
+
+   <CODE BEGINS> file "ownerca_secp384r1.cert"
+   Certificate:
+       Data:
+           Version: 3 (0x2)
+           Serial Number: 694879833 (0x296b0659)
+           Signature Algorithm: ecdsa-with-SHA256
+           Issuer: DC = ca, DC = sandelman,
+            CN = fountain-test.example.com Unstrung Fountain Root CA
+           Validity
+               Not Before: Feb 25 21:31:45 2020 GMT
+               Not After : Feb 24 21:31:45 2022 GMT
+           Subject: DC = ca, DC = sandelman,
+            CN = fountain-test.example.com Unstrung Fountain Root CA
+           Subject Public Key Info:
+               Public Key Algorithm: id-ecPublicKey
+                   Public-Key: (384 bit)
+                   pub:
+                       04:1b:7f:59:ba:17:c3:1a:bc:66:8d:8c:6c:e0:c3:
+                       fa:31:71:0f:65:f6:22:91:bd:b7:56:80:07:db:df:
+                       b8:7a:a5:45:4d:79:8a:46:97:19:59:96:31:b1:8f:
+                       69:7d:32:be:3c:c8:3e:5b:63:b5:46:f6:a8:d5:6f:
+                       9b:f9:c0:f3:d3:b9:14:3f:72:47:51:a4:76:dd:d2:
+                       f0:bf:f5:ca:8f:30:01:7f:f8:c2:5f:d3:f5:20:03:
+                       44:8b:8b:f2:07:6c:b4
+                   ASN1 OID: secp384r1
+                   NIST CURVE: P-384
+           X509v3 extensions:
+               X509v3 Basic Constraints: critical
+                   CA:TRUE
+               X509v3 Key Usage: critical
+                   Certificate Sign, CRL Sign
+               X509v3 Subject Key Identifier:
+                   B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC:
+                   87:B3:74:26
+               X509v3 Authority Key Identifier:
+                   keyid:B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:
+                   10:BC:87:B3:74:26
+
+       Signature Algorithm: ecdsa-with-SHA256
+            30:64:02:30:20:83:06:ce:8d:98:a4:54:7a:66:4c:4a:3a:70:
+            c2:52:36:5a:52:8d:59:7d:20:9b:2a:69:14:58:87:38:d8:55:
+            79:dd:fd:29:38:95:1e:91:93:76:b4:f5:66:29:44:b4:02:30:
+            6f:38:f9:af:12:ed:30:d5:85:29:7c:b1:16:58:bd:67:91:43:
+            c4:0d:30:f9:d8:1c:ac:2f:06:dd:bc:d5:06:42:2c:84:a2:04:
+            ea:02:a4:5f:17:51:26:fb:d9:2f:d2:5c
+   -----BEGIN CERTIFICATE-----
+   MIICazCCAfKgAwIBAgIEKWsGWTAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB
+   GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50
+   YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe
+   Fw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0xEjAQBgoJkiaJk/IsZAEZ
+   FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRh
+   aW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMHYw
+   EAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYikb23VoAH
+   29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR23dLw
+   v/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud
+   DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0j
+   BBgwFoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMG
+   zo2YpFR6ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBv
+   OPmvEu0w1YUpfLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lw=
+   -----END CERTIFICATE-----
+   <CODE ENDS>
+
+C.1.4.  Registrar Key Pair
+
+   The registrar is the representative of the domain owner.  This key
+   signs registrar voucher-requests and terminates the TLS connection
+   from the pledge.
+
+   <CODE BEGINS> file "jrc_prime256v1.key"
+   -----BEGIN EC PRIVATE KEY-----
+   MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49
+   AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E
+   jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg==
+   -----END EC PRIVATE KEY-----
+   <CODE ENDS>
+
+   The public key is indicated in a pledge voucher-request to show
+   proximity.
+
+   <CODE BEGINS> file "jrc_prime256v1.cert"
+   Certificate:
+       Data:
+           Version: 3 (0x2)
+           Serial Number: 1066965842 (0x3f989b52)
+           Signature Algorithm: ecdsa-with-SHA256
+           Issuer: DC = ca, DC = sandelman,
+            CN = fountain-test.example.com Unstrung Fountain Root CA
+           Validity
+               Not Before: Feb 25 21:31:54 2020 GMT
+               Not After : Feb 24 21:31:54 2022 GMT
+           Subject: DC = ca, DC = sandelman,
+            CN = fountain-test.example.com
+           Subject Public Key Info:
+               Public Key Algorithm: id-ecPublicKey
+                   Public-Key: (256 bit)
+                   pub:
+                       04:96:65:50:72:34:ba:9f:e5:dd:e6:5f:f6:f0:81:
+                       6f:e9:48:9e:81:0c:12:07:3b:46:8f:97:64:2b:63:
+                       00:8d:02:0f:57:c9:7c:94:7f:84:8c:b2:0e:61:d6:
+                       c9:88:8d:15:b4:42:1f:d7:f2:6a:b7:e4:ce:05:f8:
+                       a7:4c:d3:8b:3a
+                   ASN1 OID: prime256v1
+                   NIST CURVE: P-256
+           X509v3 extensions:
+               X509v3 Extended Key Usage: critical
+                   CMC Registration Authority
+               X509v3 Key Usage: critical
+                   Digital Signature
+       Signature Algorithm: ecdsa-with-SHA256
+            30:65:02:30:66:4f:60:4c:55:48:1e:96:07:f8:dd:1f:b9:c8:
+            12:8d:45:36:87:9b:23:c0:bc:bb:f1:cb:3d:26:15:56:6f:5f:
+            1f:bf:d5:1c:0e:6a:09:af:1b:76:97:99:19:23:fd:7e:02:31:
+            00:bc:ac:c3:41:b0:ba:0d:af:52:f9:9c:6e:7a:7f:00:1d:23:
+            c8:62:01:61:bc:4b:c5:c0:47:99:35:0a:0c:77:61:44:01:4a:
+            07:52:70:57:00:75:ff:be:07:0e:98:cb:e5
+   -----BEGIN CERTIFICATE-----
+   MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB
+   GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50
+   YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe
+   Fw0yMDAyMjUyMTMxNTRaFw0yMjAyMjQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZ
+   FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRh
+   aW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZl
+   UHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRC
+   H9fyarfkzgX4p0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1Ud
+   DwEB/wQEAwIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaH
+   myPAvLvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAd
+   I8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U=
+   -----END CERTIFICATE-----
+   <CODE ENDS>
+
+C.1.5.  Pledge Key Pair
+
+   The pledge has an IDevID key pair built in at manufacturing time:
+
+   <CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.key"
+   -----BEGIN EC PRIVATE KEY-----
+   MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49
+   AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx
+   FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw==
+   -----END EC PRIVATE KEY-----
+   <CODE ENDS>
+
+   The certificate is used by the registrar to find the MASA.
+
+   <CODE BEGINS> file "idevid_00-D0-E5-F2-00-02.cert"
+   Certificate:
+       Data:
+           Version: 3 (0x2)
+           Serial Number: 521731815 (0x1f18fee7)
+           Signature Algorithm: ecdsa-with-SHA256
+           Issuer: CN = highway-test.example.com CA
+           Validity
+               Not Before: Apr 27 18:29:30 2021 GMT
+               Not After : Dec 31 00:00:00 2999 GMT
+           Subject: serialNumber = 00-D0-E5-F2-00-02
+           Subject Public Key Info:
+               Public Key Algorithm: id-ecPublicKey
+                   Public-Key: (256 bit)
+                   pub:
+                       04:03:a3:75:43:87:b3:7c:c0:0a:9a:87:9c:ad:f6:
+                       f4:38:13:1c:d4:0c:84:1f:e0:40:4e:41:79:f0:5b:
+                       13:4b:20:71:b3:44:9b:49:62:f1:16:30:ce:bb:00:
+                       7d:80:b1:a7:d9:3b:13:50:9b:a6:27:a5:4f:c3:96:
+                       7f:4c:fe:21:27
+                   ASN1 OID: prime256v1
+                   NIST CURVE: P-256
+           X509v3 extensions:
+               X509v3 Subject Key Identifier:
+                   45:88:CC:96:96:00:64:37:B0:BA:23:65:64:64:54:08:
+                   06:6C:56:AD
+               X509v3 Basic Constraints:
+                   CA:FALSE
+               1.3.6.1.5.5.7.1.32:
+                   ..highway-test.example.com:9443
+       Signature Algorithm: ecdsa-with-SHA256
+            30:65:02:30:62:2a:db:be:34:f7:1b:cb:85:de:26:8e:43:00:
+            f9:0d:88:c8:77:a8:dd:3c:08:40:54:bc:ec:3d:b6:dc:70:2b:
+            c3:7f:ca:19:21:9a:a0:ab:c5:51:8e:aa:df:36:de:8b:02:31:
+            00:b2:5d:59:f8:47:c7:ed:03:97:a8:c0:c7:a8:81:fa:a8:86:
+            ed:67:64:37:51:7a:6e:9c:a3:82:4d:6d:ad:bc:f3:35:9e:9d:
+            6a:a2:6d:7f:7f:25:1c:03:ef:f0:ba:9b:71
+   -----BEGIN CERTIFICATE-----
+   MIIBrzCCATWgAwIBAgIEHxj+5zAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo
+   d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwIBcNMjEwNDI3MTgyOTMwWhgPMjk5OTEy
+   MzEwMDAwMDBaMBwxGjAYBgNVBAUTETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZI
+   zj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsT
+   SyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYE
+   FEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYd
+   aGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDaAAwZQIw
+   YirbvjT3G8uF3iaOQwD5DYjId6jdPAhAVLzsPbbccCvDf8oZIZqgq8VRjqrfNt6L
+   AjEAsl1Z+EfH7QOXqMDHqIH6qIbtZ2Q3UXpunKOCTW2tvPM1np1qom1/fyUcA+/w
+   uptx
+   -----END CERTIFICATE-----
+   <CODE ENDS>
+
+C.2.  Example Process
+
+   The JSON examples below are wrapped at 60 columns.  This results in
+   strings that have newlines in them, which makes them invalid JSON as
+   is.  The strings would otherwise be too long, so they need to be
+   unwrapped before processing.
+
+   For readability, the output of the asn1parse has been truncated at 68
+   columns rather than wrapped.
+
+C.2.1.  Pledge to Registrar
+
+   As described in Section 5.2, the pledge will sign a pledge voucher-
+   request containing the registrar's public key in the proximity-
+   registrar-cert field.  The base64 has been wrapped at 60 characters
+   for presentation reasons.
+
+   <CODE BEGINS> file "vr_00-D0-E5-F2-00-02.b64"
+   MIIGcAYJKoZIhvcNAQcCoIIGYTCCBl0CAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG
+   9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3Nl
+   cnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0Mzoy
+   My43NDctMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJu
+   b25jZSI6Ii1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFy
+   LWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUVFEQWpC
+   dE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFFWkZn
+   bHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJsYzNRdVpYaGhi
+   WEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5
+   TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lh
+   SmsvSXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJq
+   RWlNQ0FHQTFVRUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpN
+   Qk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNC
+   YitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlm
+   eWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3
+   TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtqT1BRUURBZ05vQURCbEFqQm1U
+   MkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212
+   RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVr
+   MUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggGyMIIBrjCCATWgAwIBAgIE
+   DYOv2TAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5j
+   b20gQ0EwIBcNMjEwNDEzMjAzNzM5WhgPMjk5OTEyMzEwMDAwMDBaMBwxGjAYBgNVBAUM
+   ETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ez
+   fMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VP
+   w5Z/TP4hJ6NZMFcwHQYDVR0OBBYEFEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQC
+   MAAwKwYIKwYBBQUHASAEHxYdaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYI
+   KoZIzj0EAwIDZwAwZAIwTmlG8sXkKGNbwbKQcYMapFbmSbnHHURFUoFuRqvbgYX7FlXp
+   BczfwF2kllNuujigAjAow1kc4r55EmiH+OMEXjBNlWlBSZC5QuJjEf0Jsmxssc+pucjO
+   J4ShqnexMEy7bjAxggEEMIIBAAIBATAuMCYxJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l
+   eGFtcGxlLmNvbSBDQQIEDYOv2TALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJ
+   KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MTMyMTQzMjNaMC8GCSqGSIb3DQEJ
+   BDEiBCBJwhyYibIjeqeR3bOaLURzMlGrc3F2X+kvJ1errtoCtTAKBggqhkjOPQQDAgRH
+   MEUCIQCmYuCE61HFQXH/E16GDOCsVquDtgr+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2
+   vZFQAKXUbimkiHKzXBA8md0VHbU=
+   <CODE ENDS>
+
+   The ASN1 decoding of the artifact:
+
+   file: examples/vr_00-D0-E5-F2-00-02.b64
+
+    0:d=0  hl=4 l=1648 cons: SEQUENCE
+    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
+   15:d=1  hl=4 l=1633 cons: cont [ 0 ]
+   19:d=2  hl=4 l=1629 cons: SEQUENCE
+   23:d=3  hl=2 l=   1 prim: INTEGER           :01
+   26:d=3  hl=2 l=  13 cons: SET
+   28:d=4  hl=2 l=  11 cons: SEQUENCE
+   30:d=5  hl=2 l=   9 prim: OBJECT            :sha256
+   41:d=3  hl=4 l= 905 cons: SEQUENCE
+   45:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
+   56:d=4  hl=4 l= 890 cons: cont [ 0 ]
+   60:d=5  hl=4 l= 886 prim: OCTET STRING      :{"ietf-voucher-request:v
+  950:d=3  hl=4 l= 434 cons: cont [ 0 ]
+  954:d=4  hl=4 l= 430 cons: SEQUENCE
+  958:d=5  hl=4 l= 309 cons: SEQUENCE
+  962:d=6  hl=2 l=   3 cons: cont [ 0 ]
+  964:d=7  hl=2 l=   1 prim: INTEGER           :02
+  967:d=6  hl=2 l=   4 prim: INTEGER           :0D83AFD9
+  973:d=6  hl=2 l=  10 cons: SEQUENCE
+  975:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+  985:d=6  hl=2 l=  38 cons: SEQUENCE
+  987:d=7  hl=2 l=  36 cons: SET
+  989:d=8  hl=2 l=  34 cons: SEQUENCE
+  991:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+  996:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
+ 1025:d=6  hl=2 l=  32 cons: SEQUENCE
+ 1027:d=7  hl=2 l=  13 prim: UTCTIME           :210413203739Z
+ 1042:d=7  hl=2 l=  15 prim: GENERALIZEDTIME   :29991231000000Z
+ 1059:d=6  hl=2 l=  28 cons: SEQUENCE
+ 1061:d=7  hl=2 l=  26 cons: SET
+ 1063:d=8  hl=2 l=  24 cons: SEQUENCE
+ 1065:d=9  hl=2 l=   3 prim: OBJECT            :serialNumber
+ 1070:d=9  hl=2 l=  17 prim: UTF8STRING        :00-D0-E5-F2-00-02
+ 1089:d=6  hl=2 l=  89 cons: SEQUENCE
+ 1091:d=7  hl=2 l=  19 cons: SEQUENCE
+ 1093:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
+ 1102:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
+ 1112:d=7  hl=2 l=  66 prim: BIT STRING
+ 1180:d=6  hl=2 l=  89 cons: cont [ 3 ]
+ 1182:d=7  hl=2 l=  87 cons: SEQUENCE
+ 1184:d=8  hl=2 l=  29 cons: SEQUENCE
+ 1186:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Ident
+ 1191:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:04144588CC9696
+ 1215:d=8  hl=2 l=   9 cons: SEQUENCE
+ 1217:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
+ 1222:d=9  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
+ 1226:d=8  hl=2 l=  43 cons: SEQUENCE
+ 1228:d=9  hl=2 l=   8 prim: OBJECT            :1.3.6.1.5.5.7.1.32
+ 1238:d=9  hl=2 l=  31 prim: OCTET STRING      [HEX DUMP]:161D6869676877
+ 1271:d=5  hl=2 l=  10 cons: SEQUENCE
+ 1273:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 1283:d=5  hl=2 l= 103 prim: BIT STRING
+ 1388:d=3  hl=4 l= 260 cons: SET
+ 1392:d=4  hl=4 l= 256 cons: SEQUENCE
+ 1396:d=5  hl=2 l=   1 prim: INTEGER           :01
+ 1399:d=5  hl=2 l=  46 cons: SEQUENCE
+ 1401:d=6  hl=2 l=  38 cons: SEQUENCE
+ 1403:d=7  hl=2 l=  36 cons: SET
+ 1405:d=8  hl=2 l=  34 cons: SEQUENCE
+ 1407:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 1412:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
+ 1441:d=6  hl=2 l=   4 prim: INTEGER           :0D83AFD9
+ 1447:d=5  hl=2 l=  11 cons: SEQUENCE
+ 1449:d=6  hl=2 l=   9 prim: OBJECT            :sha256
+ 1460:d=5  hl=2 l= 105 cons: cont [ 0 ]
+ 1462:d=6  hl=2 l=  24 cons: SEQUENCE
+ 1464:d=7  hl=2 l=   9 prim: OBJECT            :contentType
+ 1475:d=7  hl=2 l=  11 cons: SET
+ 1477:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
+ 1488:d=6  hl=2 l=  28 cons: SEQUENCE
+ 1490:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
+ 1501:d=7  hl=2 l=  15 cons: SET
+ 1503:d=8  hl=2 l=  13 prim: UTCTIME           :210413214323Z
+ 1518:d=6  hl=2 l=  47 cons: SEQUENCE
+ 1520:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
+ 1531:d=7  hl=2 l=  34 cons: SET
+ 1533:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:49C21C9889B223
+ 1567:d=5  hl=2 l=  10 cons: SEQUENCE
+ 1569:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 1579:d=5  hl=2 l=  71 prim: OCTET STRING      [HEX DUMP]:3045022100A662
+
+   The JSON contained in the voucher-request:
+
+   {"ietf-voucher-request:voucher":{"assertion":"proximity","cr
+   eated-on":"2021-04-13T17:43:23.747-04:00","serial-number":"0
+   0-D0-E5-F2-00-02","nonce":"-_XE9zK9q8Ll1qylMtLKeg","proximit
+   y-registrar-cert":"MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDA
+   jBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZ
+   WxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zd
+   HJ1bmcgRm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNTRaFw0yMjAyM
+   jQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkA
+   RkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRhaW4tdGVzdC5leGFtcGxlL
+   mNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb
+   +lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p
+   0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1UdDwEB/wQEA
+   wIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaHmyPAv
+   Lvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAdI
+   8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}}
+
+C.2.2.  Registrar to MASA
+
+   As described in Section 5.5, the registrar will sign a registrar
+   voucher-request and will include the pledge's voucher-request in the
+   prior-signed-voucher-request.
+
+   <CODE BEGINS> file "parboiled_vr_00-D0-E5-F2-00-02.b64"
+   MIIPYwYJKoZIhvcNAQcCoIIPVDCCD1ACAQExDTALBglghkgBZQMEAgEwggl4BgkqhkiG
+   9w0BBwGggglpBIIJZXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3Nl
+   cnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QyMTo0Mzoy
+   My43ODdaIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2Ui
+   OiItX1hFOXpLOXE4TGwxcXlsTXRMS2VnIiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVx
+   dWVzdCI6Ik1JSUdjQVlKS29aSWh2Y05BUWNDb0lJR1lUQ0NCbDBDQVFFeERUQUxCZ2xn
+   aGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042QklJRGRuc2lhV1YwWmkx
+   MmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxjblJwYjI0aU9p
+   SndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNUzB3TkMweE0xUXhO
+   em8wTXpveU15NDNORGN0TURRNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0
+   UkRBdFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJaTFmV0VVNWVrczVjVGhNYkRG
+   eGVXeE5kRXhMWldjaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9p
+   Sk5TVWxDTDBSRFEwRlpTMmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFV
+   VkZFUVdwQ2RFMVNTWGRGUVZsTFExcEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZ
+   UW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhwWlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1k
+   T1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5SZFZwWWFHaGlXRUp6V2xNMWFt
+   SXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZiVGwyWkVOQ1JGRlVR
+   V1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVVMVVUWGhP
+   VkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O
+   SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFU
+   RlZSVUYzZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9k
+   bUpVUWxwTlFrMUhRbmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpL
+   V214VlNFa3dkWEF2YkRObFdtWTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdw
+   QlNUQkRSREZtU21aS1VpOW9TWGw1UkcxSVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10Nlox
+   ZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JLVVVWQ0wzZFJUVTFCYjBkRFEzTkhR
+   VkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpTR2RFUVV0Q1oyZHhhR3Rx
+   VDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVpczFlVUpMVGxK
+   VVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cxU2Ey
+   b3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRP
+   RmhCVWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJn
+   Z2dHeU1JSUJyakNDQVRXZ0F3SUJBZ0lFRFlPdjJUQUtCZ2dxaGtqT1BRUURBakFtTVNR
+   d0lnWURWUVFEREJ0b2FXZG9kMkY1TFhSbGMzUXVaWGhoYlhCc1pTNWpiMjBnUTBFd0lC
+   Y05NakV3TkRFek1qQXpOek01V2hnUE1qazVPVEV5TXpFd01EQXdNREJhTUJ3eEdqQVlC
+   Z05WQkFVTUVUQXdMVVF3TFVVMUxVWXlMVEF3TFRBeU1Ga3dFd1lIS29aSXpqMENBUVlJ
+   S29aSXpqMERBUWNEUWdBRUE2TjFRNGV6Zk1BS21vZWNyZmIwT0JNYzFBeUVIK0JBVGtG
+   NThGc1RTeUJ4czBTYlNXTHhGakRPdXdCOWdMR24yVHNUVUp1bUo2VlB3NVovVFA0aEo2
+   TlpNRmN3SFFZRFZSME9CQllFRkVXSXpKYVdBR1Ezc0xvalpXUmtWQWdHYkZhdE1Ba0dB
+   MVVkRXdRQ01BQXdLd1lJS3dZQkJRVUhBU0FFSHhZZGFHbG5hSGRoZVMxMFpYTjBMbVY0
+   WVcxd2JHVXVZMjl0T2prME5ETXdDZ1lJS29aSXpqMEVBd0lEWndBd1pBSXdUbWxHOHNY
+   a0tHTmJ3YktRY1lNYXBGYm1TYm5ISFVSRlVvRnVScXZiZ1lYN0ZsWHBCY3pmd0Yya2xs
+   TnV1amlnQWpBb3cxa2M0cjU1RW1pSCtPTUVYakJObFdsQlNaQzVRdUpqRWYwSnNteHNz
+   YytwdWNqT0o0U2hxbmV4TUV5N2JqQXhnZ0VFTUlJQkFBSUJBVEF1TUNZeEpEQWlCZ05W
+   QkFNTUcyaHBaMmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlNCRFFRSUVEWU92MlRB
+   TEJnbGdoa2dCWlFNRUFnR2dhVEFZQmdrcWhraUc5dzBCQ1FNeEN3WUpLb1pJaHZjTkFR
+   Y0JNQndHQ1NxR1NJYjNEUUVKQlRFUEZ3MHlNVEEwTVRNeU1UUXpNak5hTUM4R0NTcUdT
+   SWIzRFFFSkJERWlCQ0JKd2h5WWliSWplcWVSM2JPYUxVUnpNbEdyYzNGMlgra3ZKMWVy
+   cnRvQ3RUQUtCZ2dxaGtqT1BRUURBZ1JITUVVQ0lRQ21ZdUNFNjFIRlFYSC9FMTZHRE9D
+   c1ZxdUR0Z3IrUS82L0R1LzlRa3pBN2dJZ2Y3TUZoQUlQVzJQTndSYTJ2WkZRQUtYVWJp
+   bWtpSEt6WEJBOG1kMFZIYlU9In19oIIEbzCCAfwwggGCoAMCAQICBD+Ym1IwCgYIKoZI
+   zj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVs
+   bWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tIFVuc3RydW5nIEZv
+   dW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTU0WhcNMjIwMjI0MjEzMTU0WjBTMRIw
+   EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xIjAgBgNV
+   BAMMGWZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMB
+   BwNCAASWZVByNLqf5d3mX/bwgW/pSJ6BDBIHO0aPl2QrYwCNAg9XyXyUf4SMsg5h1smI
+   jRW0Qh/X8mq35M4F+KdM04s6oyowKDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDHDAOBgNV
+   HQ8BAf8EBAMCB4AwCgYIKoZIzj0EAwIDaAAwZQIwZk9gTFVIHpYH+N0fucgSjUU2h5sj
+   wLy78cs9JhVWb18fv9UcDmoJrxt2l5kZI/1+AjEAvKzDQbC6Da9S+Zxuen8AHSPIYgFh
+   vEvFwEeZNQoMd2FEAUoHUnBXAHX/vgcOmMvlMIICazCCAfKgAwIBAgIEKWsGWTAKBggq
+   hkjOPQQDAjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5k
+   ZWxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcg
+   Rm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0x
+   EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoG
+   A1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBS
+   b290IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYi
+   kb23VoAH29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR2
+   3dLwv/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud
+   DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0jBBgw
+   FoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMGzo2YpFR6
+   ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBvOPmvEu0w1YUp
+   fLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lwxggFLMIIBRwIBATB1
+   MG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8
+   MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFp
+   biBSb290IENBAgQ/mJtSMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG
+   9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQxMzIxNDMyM1owLwYJKoZIhvcNAQkEMSIE
+   IEnOrdWjlG70K74IhCJ7UXi+wPS+r2C8DFEqjabGP+G8MAoGCCqGSM49BAMCBEcwRQIh
+   AMhO3M+tSWb2wKTBOXPArN+XvjSzAhaQA/uLj3qhPwi/AiBDDthf6mjMuirqXE0yjMif
+   C2UY9oNUFF9Nl0wEQpBBAA==
+   <CODE ENDS>
+
+   The ASN1 decoding of the artifact:
+
+   file: examples/parboiled_vr_00_D0-E5-02-00-2D.b64
+
+    0:d=0  hl=4 l=3939 cons: SEQUENCE
+    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
+   15:d=1  hl=4 l=3924 cons: cont [ 0 ]
+   19:d=2  hl=4 l=3920 cons: SEQUENCE
+   23:d=3  hl=2 l=   1 prim: INTEGER           :01
+   26:d=3  hl=2 l=  13 cons: SET
+   28:d=4  hl=2 l=  11 cons: SEQUENCE
+   30:d=5  hl=2 l=   9 prim: OBJECT            :sha256
+   41:d=3  hl=4 l=2424 cons: SEQUENCE
+   45:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
+   56:d=4  hl=4 l=2409 cons: cont [ 0 ]
+   60:d=5  hl=4 l=2405 prim: OCTET STRING      :{"ietf-voucher-request:v
+ 2469:d=3  hl=4 l=1135 cons: cont [ 0 ]
+ 2473:d=4  hl=4 l= 508 cons: SEQUENCE
+ 2477:d=5  hl=4 l= 386 cons: SEQUENCE
+ 2481:d=6  hl=2 l=   3 cons: cont [ 0 ]
+ 2483:d=7  hl=2 l=   1 prim: INTEGER           :02
+ 2486:d=6  hl=2 l=   4 prim: INTEGER           :3F989B52
+ 2492:d=6  hl=2 l=  10 cons: SEQUENCE
+ 2494:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 2504:d=6  hl=2 l= 109 cons: SEQUENCE
+ 2506:d=7  hl=2 l=  18 cons: SET
+ 2508:d=8  hl=2 l=  16 cons: SEQUENCE
+ 2510:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 2522:d=9  hl=2 l=   2 prim: IA5STRING         :ca
+ 2526:d=7  hl=2 l=  25 cons: SET
+ 2528:d=8  hl=2 l=  23 cons: SEQUENCE
+ 2530:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 2542:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
+ 2553:d=7  hl=2 l=  60 cons: SET
+ 2555:d=8  hl=2 l=  58 cons: SEQUENCE
+ 2557:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 2562:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
+ 2615:d=6  hl=2 l=  30 cons: SEQUENCE
+ 2617:d=7  hl=2 l=  13 prim: UTCTIME           :200225213154Z
+ 2632:d=7  hl=2 l=  13 prim: UTCTIME           :220224213154Z
+ 2647:d=6  hl=2 l=  83 cons: SEQUENCE
+ 2649:d=7  hl=2 l=  18 cons: SET
+ 2651:d=8  hl=2 l=  16 cons: SEQUENCE
+ 2653:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 2665:d=9  hl=2 l=   2 prim: IA5STRING         :ca
+ 2669:d=7  hl=2 l=  25 cons: SET
+ 2671:d=8  hl=2 l=  23 cons: SEQUENCE
+ 2673:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 2685:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
+ 2696:d=7  hl=2 l=  34 cons: SET
+ 2698:d=8  hl=2 l=  32 cons: SEQUENCE
+ 2700:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 2705:d=9  hl=2 l=  25 prim: UTF8STRING        :fountain-test.example.co
+ 2732:d=6  hl=2 l=  89 cons: SEQUENCE
+ 2734:d=7  hl=2 l=  19 cons: SEQUENCE
+ 2736:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
+ 2745:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
+ 2755:d=7  hl=2 l=  66 prim: BIT STRING
+ 2823:d=6  hl=2 l=  42 cons: cont [ 3 ]
+ 2825:d=7  hl=2 l=  40 cons: SEQUENCE
+ 2827:d=8  hl=2 l=  22 cons: SEQUENCE
+ 2829:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usag
+ 2834:d=9  hl=2 l=   1 prim: BOOLEAN           :255
+ 2837:d=9  hl=2 l=  12 prim: OCTET STRING      [HEX DUMP]:300A06082B0601
+ 2851:d=8  hl=2 l=  14 cons: SEQUENCE
+ 2853:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
+ 2858:d=9  hl=2 l=   1 prim: BOOLEAN           :255
+ 2861:d=9  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020780
+ 2867:d=5  hl=2 l=  10 cons: SEQUENCE
+ 2869:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 2879:d=5  hl=2 l= 104 prim: BIT STRING
+ 2985:d=4  hl=4 l= 619 cons: SEQUENCE
+ 2989:d=5  hl=4 l= 498 cons: SEQUENCE
+ 2993:d=6  hl=2 l=   3 cons: cont [ 0 ]
+ 2995:d=7  hl=2 l=   1 prim: INTEGER           :02
+ 2998:d=6  hl=2 l=   4 prim: INTEGER           :296B0659
+ 3004:d=6  hl=2 l=  10 cons: SEQUENCE
+ 3006:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 3016:d=6  hl=2 l= 109 cons: SEQUENCE
+ 3018:d=7  hl=2 l=  18 cons: SET
+ 3020:d=8  hl=2 l=  16 cons: SEQUENCE
+ 3022:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 3034:d=9  hl=2 l=   2 prim: IA5STRING         :ca
+ 3038:d=7  hl=2 l=  25 cons: SET
+ 3040:d=8  hl=2 l=  23 cons: SEQUENCE
+ 3042:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 3054:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
+ 3065:d=7  hl=2 l=  60 cons: SET
+ 3067:d=8  hl=2 l=  58 cons: SEQUENCE
+ 3069:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 3074:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
+ 3127:d=6  hl=2 l=  30 cons: SEQUENCE
+ 3129:d=7  hl=2 l=  13 prim: UTCTIME           :200225213145Z
+ 3144:d=7  hl=2 l=  13 prim: UTCTIME           :220224213145Z
+ 3159:d=6  hl=2 l= 109 cons: SEQUENCE
+ 3161:d=7  hl=2 l=  18 cons: SET
+ 3163:d=8  hl=2 l=  16 cons: SEQUENCE
+ 3165:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 3177:d=9  hl=2 l=   2 prim: IA5STRING         :ca
+ 3181:d=7  hl=2 l=  25 cons: SET
+ 3183:d=8  hl=2 l=  23 cons: SEQUENCE
+ 3185:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 3197:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
+ 3208:d=7  hl=2 l=  60 cons: SET
+ 3210:d=8  hl=2 l=  58 cons: SEQUENCE
+ 3212:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 3217:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
+ 3270:d=6  hl=2 l= 118 cons: SEQUENCE
+ 3272:d=7  hl=2 l=  16 cons: SEQUENCE
+ 3274:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
+ 3283:d=8  hl=2 l=   5 prim: OBJECT            :secp384r1
+ 3290:d=7  hl=2 l=  98 prim: BIT STRING
+ 3390:d=6  hl=2 l=  99 cons: cont [ 3 ]
+ 3392:d=7  hl=2 l=  97 cons: SEQUENCE
+ 3394:d=8  hl=2 l=  15 cons: SEQUENCE
+ 3396:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
+ 3401:d=9  hl=2 l=   1 prim: BOOLEAN           :255
+ 3404:d=9  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF
+ 3411:d=8  hl=2 l=  14 cons: SEQUENCE
+ 3413:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
+ 3418:d=9  hl=2 l=   1 prim: BOOLEAN           :255
+ 3421:d=9  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020106
+ 3427:d=8  hl=2 l=  29 cons: SEQUENCE
+ 3429:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Ident
+ 3434:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:0414B9A5F6CB11
+ 3458:d=8  hl=2 l=  31 cons: SEQUENCE
+ 3460:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Ide
+ 3465:d=9  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:30168014B9A5F6
+ 3491:d=5  hl=2 l=  10 cons: SEQUENCE
+ 3493:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 3503:d=5  hl=2 l= 103 prim: BIT STRING
+ 3608:d=3  hl=4 l= 331 cons: SET
+ 3612:d=4  hl=4 l= 327 cons: SEQUENCE
+ 3616:d=5  hl=2 l=   1 prim: INTEGER           :01
+ 3619:d=5  hl=2 l= 117 cons: SEQUENCE
+ 3621:d=6  hl=2 l= 109 cons: SEQUENCE
+ 3623:d=7  hl=2 l=  18 cons: SET
+ 3625:d=8  hl=2 l=  16 cons: SEQUENCE
+ 3627:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 3639:d=9  hl=2 l=   2 prim: IA5STRING         :ca
+ 3643:d=7  hl=2 l=  25 cons: SET
+ 3645:d=8  hl=2 l=  23 cons: SEQUENCE
+ 3647:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
+ 3659:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
+ 3670:d=7  hl=2 l=  60 cons: SET
+ 3672:d=8  hl=2 l=  58 cons: SEQUENCE
+ 3674:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 3679:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
+ 3732:d=6  hl=2 l=   4 prim: INTEGER           :3F989B52
+ 3738:d=5  hl=2 l=  11 cons: SEQUENCE
+ 3740:d=6  hl=2 l=   9 prim: OBJECT            :sha256
+ 3751:d=5  hl=2 l= 105 cons: cont [ 0 ]
+ 3753:d=6  hl=2 l=  24 cons: SEQUENCE
+ 3755:d=7  hl=2 l=   9 prim: OBJECT            :contentType
+ 3766:d=7  hl=2 l=  11 cons: SET
+ 3768:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
+ 3779:d=6  hl=2 l=  28 cons: SEQUENCE
+ 3781:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
+ 3792:d=7  hl=2 l=  15 cons: SET
+ 3794:d=8  hl=2 l=  13 prim: UTCTIME           :210413214323Z
+ 3809:d=6  hl=2 l=  47 cons: SEQUENCE
+ 3811:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
+ 3822:d=7  hl=2 l=  34 cons: SET
+ 3824:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:49CEADD5A3946E
+ 3858:d=5  hl=2 l=  10 cons: SEQUENCE
+ 3860:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 3870:d=5  hl=2 l=  71 prim: OCTET STRING      [HEX DUMP]:3045022100C84E
+
+   The JSON contained in the voucher-request.  Note that the previous
+   voucher-request is in the prior-signed-voucher-request attribute.
+
+   {"ietf-voucher-request:voucher":{"assertion":"proximity","cr
+   eated-on":"2021-04-13T21:43:23.787Z","serial-number":"00-D0-
+   E5-F2-00-02","nonce":"-_XE9zK9q8Ll1qylMtLKeg","prior-signed-
+   voucher-request":"MIIGcAYJKoZIhvcNAQcCoIIGYTCCBl0CAQExDTALBg
+   lghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaG
+   VyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLC
+   JjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0MzoyMy43NDctMDQ6MDAiLC
+   JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Ii
+   1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFyLW
+   NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV
+   FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU
+   prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF
+   lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm
+   5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak
+   F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV
+   pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU
+   F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn
+   lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk
+   NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU
+   5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU
+   1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG
+   tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV
+   BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk
+   JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2
+   NGY0FkZisrQnc2WXkrVT0ifX2gggGyMIIBrjCCATWgAwIBAgIEDYOv2TAKBg
+   gqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb2
+   0gQ0EwIBcNMjEwNDEzMjAzNzM5WhgPMjk5OTEyMzEwMDAwMDBaMBwxGjAYBg
+   NVBAUMETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQ
+   cDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLxFj
+   DOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYEFEWIzJaWAG
+   Q3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYdaGlnaH
+   dheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDZwAwZAIwTm
+   lG8sXkKGNbwbKQcYMapFbmSbnHHURFUoFuRqvbgYX7FlXpBczfwF2kllNuuj
+   igAjAow1kc4r55EmiH+OMEXjBNlWlBSZC5QuJjEf0Jsmxssc+pucjOJ4Shqn
+   exMEy7bjAxggEEMIIBAAIBATAuMCYxJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC
+   5leGFtcGxlLmNvbSBDQQIEDYOv2TALBglghkgBZQMEAgGgaTAYBgkqhkiG9w
+   0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MTMyMTQzMj
+   NaMC8GCSqGSIb3DQEJBDEiBCBJwhyYibIjeqeR3bOaLURzMlGrc3F2X+kvJ1
+   errtoCtTAKBggqhkjOPQQDAgRHMEUCIQCmYuCE61HFQXH/E16GDOCsVquDtg
+   r+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2vZFQAKXUbimkiHKzXBA8md0VHb
+   U="}}
+
+C.2.3.  MASA to Registrar
+
+   The MASA will return a voucher to the registrar, which is to be
+   relayed to the pledge.
+
+   <CODE BEGINS> file "voucher_00-D0-E5-F2-00-02.b64"
+   MIIGIgYJKoZIhvcNAQcCoIIGEzCCBg8CAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG
+   9w0BBwGgggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoi
+   bG9nZ2VkIiwiY3JlYXRlZC1vbiI6IjIwMjEtMDQtMTNUMTc6NDM6MjQuNTg5LTA0OjAw
+   Iiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiItX1hF
+   OXpLOXE4TGwxcXlsTXRMS2VnIiwicGlubmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NB
+   WUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFRREFqQnRNUkl3RUFZS0NaSW1pWlB5
+   TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6WVc1a1pXeHRZVzR4UERB
+   NkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpiMjBnVlc1emRI
+   SjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5UUmFG
+   dzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVa
+   TUJjR0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05
+   MWJuUmhhVzR0ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0ND
+   cUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1ha
+   Q3RqQUkwQ0QxZkpmSlIvaEl5eURtSFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFq
+   S2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0NzR0FRVUZCd01jTUE0R0ExVWREd0VCL3dR
+   RUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJtVDJCTVZVZ2VsZ2Y0M1IrNXlC
+   S05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVhtUmtqL1g0Q01RQzhy
+   TU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNnZFNjRmNB
+   ZGYrK0J3Nll5K1U9In19oIIBdDCCAXAwgfagAwIBAgIEC4cKMTAKBggqhkjOPQQDAjAm
+   MSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjE0
+   MDE2WhcNMjMwNDEzMjE0MDE2WjAoMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBs
+   ZS5jb20gTUFTQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5Gwcb
+   pnRznB66bKmzqTCpojJZ96AdRwFtuTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6Wj
+   EDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDaQAwZgIxAK7LYS3UXI1uhqoLBh3G
+   02C6MnM2JdMjhUmHHM6UI3kankFVJB0VIqFIuwrAqzwTcwIxAIY8Z7OVouLl+a35HZzB
+   NDJ49c/q1UcDnwC/0FnLUcKYBIEkilETULF1si+dqLT0uTGCAQUwggEBAgEBMC4wJjEk
+   MCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBAgQLhwoxMAsGCWCGSAFl
+   AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIx
+   MDQxMzIxNDMyNFowLwYJKoZIhvcNAQkEMSIEIFUUjg4WYVO+MpX122Qfk/7zm/G6/B59
+   HD/xrVR0lGIjMAoGCCqGSM49BAMCBEgwRgIhAOhUfxbH2dwpB2BrTDcsYSjRkCCk/WE6
+   Mdt+y4z5KD9IAiEAphwdIUb40A0noNIUpH7N2lTyAFZgyn1lNHTteY9DmYI=
+   <CODE ENDS>
+
+   The ASN1 decoding of the artifact:
+
+   file: examples/voucher_00-D0-E5-F2-00-02.b64
+
+    0:d=0  hl=4 l=1570 cons: SEQUENCE
+    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
+   15:d=1  hl=4 l=1555 cons: cont [ 0 ]
+   19:d=2  hl=4 l=1551 cons: SEQUENCE
+   23:d=3  hl=2 l=   1 prim: INTEGER           :01
+   26:d=3  hl=2 l=  13 cons: SET
+   28:d=4  hl=2 l=  11 cons: SEQUENCE
+   30:d=5  hl=2 l=   9 prim: OBJECT            :sha256
+   41:d=3  hl=4 l= 888 cons: SEQUENCE
+   45:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
+   56:d=4  hl=4 l= 873 cons: cont [ 0 ]
+   60:d=5  hl=4 l= 869 prim: OCTET STRING      :{"ietf-voucher:voucher":
+  933:d=3  hl=4 l= 372 cons: cont [ 0 ]
+  937:d=4  hl=4 l= 368 cons: SEQUENCE
+  941:d=5  hl=3 l= 246 cons: SEQUENCE
+  944:d=6  hl=2 l=   3 cons: cont [ 0 ]
+  946:d=7  hl=2 l=   1 prim: INTEGER           :02
+  949:d=6  hl=2 l=   4 prim: INTEGER           :0B870A31
+  955:d=6  hl=2 l=  10 cons: SEQUENCE
+  957:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+  967:d=6  hl=2 l=  38 cons: SEQUENCE
+  969:d=7  hl=2 l=  36 cons: SET
+  971:d=8  hl=2 l=  34 cons: SEQUENCE
+  973:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+  978:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
+ 1007:d=6  hl=2 l=  30 cons: SEQUENCE
+ 1009:d=7  hl=2 l=  13 prim: UTCTIME           :210413214016Z
+ 1024:d=7  hl=2 l=  13 prim: UTCTIME           :230413214016Z
+ 1039:d=6  hl=2 l=  40 cons: SEQUENCE
+ 1041:d=7  hl=2 l=  38 cons: SET
+ 1043:d=8  hl=2 l=  36 cons: SEQUENCE
+ 1045:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 1050:d=9  hl=2 l=  29 prim: UTF8STRING        :highway-test.example.com
+ 1081:d=6  hl=2 l=  89 cons: SEQUENCE
+ 1083:d=7  hl=2 l=  19 cons: SEQUENCE
+ 1085:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
+ 1094:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
+ 1104:d=7  hl=2 l=  66 prim: BIT STRING
+ 1172:d=6  hl=2 l=  16 cons: cont [ 3 ]
+ 1174:d=7  hl=2 l=  14 cons: SEQUENCE
+ 1176:d=8  hl=2 l=  12 cons: SEQUENCE
+ 1178:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
+ 1183:d=9  hl=2 l=   1 prim: BOOLEAN           :255
+ 1186:d=9  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
+ 1190:d=5  hl=2 l=  10 cons: SEQUENCE
+ 1192:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 1202:d=5  hl=2 l= 105 prim: BIT STRING
+ 1309:d=3  hl=4 l= 261 cons: SET
+ 1313:d=4  hl=4 l= 257 cons: SEQUENCE
+ 1317:d=5  hl=2 l=   1 prim: INTEGER           :01
+ 1320:d=5  hl=2 l=  46 cons: SEQUENCE
+ 1322:d=6  hl=2 l=  38 cons: SEQUENCE
+ 1324:d=7  hl=2 l=  36 cons: SET
+ 1326:d=8  hl=2 l=  34 cons: SEQUENCE
+ 1328:d=9  hl=2 l=   3 prim: OBJECT            :commonName
+ 1333:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
+ 1362:d=6  hl=2 l=   4 prim: INTEGER           :0B870A31
+ 1368:d=5  hl=2 l=  11 cons: SEQUENCE
+ 1370:d=6  hl=2 l=   9 prim: OBJECT            :sha256
+ 1381:d=5  hl=2 l= 105 cons: cont [ 0 ]
+ 1383:d=6  hl=2 l=  24 cons: SEQUENCE
+ 1385:d=7  hl=2 l=   9 prim: OBJECT            :contentType
+ 1396:d=7  hl=2 l=  11 cons: SET
+ 1398:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
+ 1409:d=6  hl=2 l=  28 cons: SEQUENCE
+ 1411:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
+ 1422:d=7  hl=2 l=  15 cons: SET
+ 1424:d=8  hl=2 l=  13 prim: UTCTIME           :210413214324Z
+ 1439:d=6  hl=2 l=  47 cons: SEQUENCE
+ 1441:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
+ 1452:d=7  hl=2 l=  34 cons: SET
+ 1454:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:55148E0E166153
+ 1488:d=5  hl=2 l=  10 cons: SEQUENCE
+ 1490:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
+ 1500:d=5  hl=2 l=  72 prim: OCTET STRING      [HEX DUMP]:3046022100E854
+
+
+Acknowledgements
+
+   We would like to thank the various reviewers for their input, in
+   particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear,
+   Sergey Kasatkin, Anoop Kumar, Tom Petch, Markus Stenberg, Peter van
+   der Stok, and Thomas Werner.
+
+   Significant reviews were done by Jari Arkko, Christian Huitema, and
+   Russ Housley.
+
+   Henk Birkholz contributed the CDDL for the audit-log response.
+
+   This document started its life as a two-page idea from Steinthor
+   Bjarnason.
+
+   In addition, significant review comments were provided by many IESG
+   members, including Adam Roach, Alexey Melnikov, Alissa Cooper,
+   Benjamin Kaduk, Éric Vyncke, Roman Danyliw, and Magnus Westerlund.
+
+Authors' Addresses
+
+   Max Pritikin
+   Cisco
+
+   Email: pritikin@cisco.com
+
+
+   Michael C. Richardson
+   Sandelman Software Works
+
+   Email: mcr+ietf@sandelman.ca
+   URI:   http://www.sandelman.ca/
+
+
+   Toerless Eckert
+   Futurewei Technologies Inc.  USA
+   2330 Central Expy
+   Santa Clara, CA 95050
+   United States of America
+
+   Email: tte+ietf@cs.fau.de
+
+
+   Michael H. Behringer
+
+   Email: Michael.H.Behringer@gmail.com
+
+
+   Kent Watsen
+   Watsen Networks
+
+   Email: kent+ietf@watsen.net