<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-anima-bootstrapping-keyinfra-43"
  docName="draft-ietf-anima-bootstrapping-keyinfra-45" ipr="trust200902"
  obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
  symRefs="true" sortRefs="true" version="3"> version="3" number="8995" consensus="yes">

  <!-- xml2rfc v2v3 conversion 2.46.0 -->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <front>
    <title abbrev="BRSKI">Bootstrapping Remote Secure Key Infrastructures Infrastructure
    (BRSKI)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-anima-bootstrapping-keyinfra-43"/> name="RFC" value="8995"/>
    <author fullname="Max Pritikin" initials="M." surname="Pritikin">
      <organization>Cisco</organization>
      <address>
        <email>pritikin@cisco.com</email>
      </address>
    </author>
    <author fullname="Michael C. Richardson" initials="M." surname="Richardson">
      <organization abbrev="Sandelman">Sandelman abbrev="Sandelman Software Works">Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
        <uri>http://www.sandelman.ca/</uri>
      </address>
    </author>
    <author fullname="Toerless Eckert" initials="T.T.E." initials="T." surname="Eckert">
      <organization abbrev="Futurewei USA">
                Futurewei Technologies Inc.  USA</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>USA</country>
        </postal>
        <email>tte+ietf@cs.fau.de</email>
      </address>
    </author>
    <author fullname="Michael H. Behringer" initials="M.H." initials="M." surname="Behringer">
      <address>
        <email>Michael.H.Behringer@gmail.com</email>
      </address>
    </author>
    <author fullname="Kent Watsen" initials="K.W." initials="K." surname="Watsen">
      <organization>Watsen Networks</organization>
      <address>
        <email>kent+ietf@watsen.net</email>
      </address>
    </author>
    <date year="2020"/> year="2021" month="May"/>
    <area>Operations and Management</area>
    <workgroup>ANIMA WG</workgroup>
    <workgroup>ANIMA</workgroup>

    <abstract>
      <t>
        This document specifies automated bootstrapping of an Autonomic
        Control Plane.  To do this 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, or using only link-local connectivity, or on
        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.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        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 "pledges" in this
        document.  Pledges have an IDevID Initial Device Identifier (IDevID) installed in them at the factory.
      </t>
      <t>
        "BRSKI" is
        "BRSKI", pronounced like "brewski", is a colloquial term for beer in
        Canada and parts of the US-midwest. Midwestern United States <xref target="brewski" format="default"/> format="default"/>.
      </t>
      <t>
        This document primarily provides for the needs of
        the ISP and Enterprise focused ANIMA
        <xref target="I-D.ietf-anima-autonomic-control-plane" format="default">Autonomic enterprise-focused Autonomic Networking Integrated Model and Approach (ANIMA)
        Autonomic Control Plane (ACP)</xref>. (ACP) <xref target="RFC8994" format="default"/>.

	This bootstrap process satisfies
        the <xref target="RFC7575" format="default"/> requirements of section 3.3 requirement of making all operations
        secure by default. default per <xref target="RFC7575" sectionFormat="of" section="3.3"/>.

	Other users of the BRSKI protocol
        will need to provide separate applicability statements that
        include privacy and security considerations appropriate to that
        deployment.  <xref target="acpapplicability" format="default"/> explains the detailed
        applicability for this the ACP usage.
      </t>
      <t>
        The BRSKI protocol requires a significant amount of communication
        between manufacturer and owner: in its default modes 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.
      </t>

      <t>
        This document describes how pledges discover a pledge discovers (or are discovered by) an
        element of the network domain that it will belong to which the pledge belongs and that will perform
        the
        its bootstrap.  This element (device) is called the
        registrar.
        "registrar".  Before any other operation, the pledge and registrar need to
        establish mutual trust:
      </t>
      <ol spacing="normal" type="1">
        <li>Registrar authenticating the pledge: "Who is this device? What is
          its identity?"</li>
        <li>Registrar authorizing the pledge: "Is it mine? Do I want it?
          What are the chances it has been compromised?"</li>
        <li>Pledge authenticating the registrar: "What is this
          registrar's identity?"</li>
        <li>Pledge authorizing the registrar: "Should I join this network?"</li>
      </ol>
      <t>
          This document details protocols and messages to answer the above questions.
          It uses a TLS connection and an a PKIX-shaped (X.509v3) certificate (an IEEE
          802.1AR IDevID <xref target="IDevID" format="default"/> IDevID) format="default"/>) of the pledge to answer
          points 1 and 2.
          It uses a new artifact called a "voucher" that the registrar
          receives from a "Manufacturer Manufacturer Authorized Signing Authority" Authority (MASA) and
          passes it to the pledge to answer points 3 and 4.
      </t>
      <t>
          A proxy provides very limited connectivity between the pledge and
          the registrar.
      </t>
      <t>The syntactic details of vouchers are described in detail in <xref target="RFC8366" format="default"/>. This document details automated
      protocol mechanisms to obtain vouchers, including the definition
      of a 'voucher-request' "voucher-request" message that is a minor extension
      to the voucher format (see <xref target="voucher-request" format="default"/>) as defined
      by <xref target="RFC8366" format="default"/>.</t>

      <t>BRSKI results in the pledge storing an X.509 root
    certificate sufficient for verifying the registrar identity. In the
    process
    process, a TLS connection is established that can be directly used for
    Enrollment over Secure Transport (EST).

    In effect effect, BRSKI provides
    an automated mechanism for the "Bootstrap Distribution of CA Certificates"
    described in <xref target="RFC7030" format="default"/> Section 4.1.1 sectionFormat="comma" section="4.1.1"/>, wherein
    the pledge "MUST "<bcp14>MUST</bcp14> [...] engage a human user to authorize the CA certificate using
    out-of-band" information.
    out-of-band data". With BRSKI BRSKI, the pledge now can automate
    this process using the voucher. Integration with a complete EST
      enrollment is optional but trivial.</t>

      <t>BRSKI is agile enough to support
      bootstrapping alternative key infrastructures, such as a symmetric key
      solutions,
      solution, but no such system is described in this document.</t>
      <section numbered="true" toc="default">
        <name>Prior Bootstrapping Approaches</name>
        <t>To literally "pull yourself up by the bootstraps" is an impossible
        action. Similarly Similarly, the secure establishment of a key infrastructure
        without external help is also an impossibility. Today 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 SIM 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 "Trust on
        First Use' (TOFU) Use (TOFU)" <xref target="RFC7435" format="default"/>, 'resurrecting duckling' "resurrecting duckling"
        <xref target="Stajano99theresurrecting" format="default"/> format="default"/>, or 'pre-staging'.</t> "pre-staging".</t>

        <t>Another prior approach has been to try and
        minimize user actions during bootstrapping, but not eliminate all
        user-actions.
        user actions.
        The original EST protocol <xref target="RFC7030" format="default"/> does reduce user actions during bootstrap bootstrapping
        but does not provide solutions for how the following protocol steps
        can be made autonomic (not involving user actions):
        </t>
        <ul spacing="normal">
          <li>using the Implicit Trust Anchor (TA) <xref target="RFC7030" format="default"/> database to authenticate
                an owner specific owner-specific service (not an autonomic solution because
                the URL must be securely distributed),</li>
          <li>engaging a human user to authorize the CA certificate using
                  out-of-band data (not an autonomic solution because the human user
                  is involved),</li>
          <li>using a configured Explicit TA database (not an autonomic
                  solution because the distribution of an explicit TA database is
                  not autonomic),</li>
          <li>and using autonomic), and</li>
          <li>using a Certificate-Less certificate-less TLS mutual authentication method
                  (not an autonomic solution because the distribution of symmetric
                  key material is not autonomic).
              </li>
        </ul>
        <t>
            These "touch" methods do not meet the requirements for
            zero-touch.
        </t>
        <t>There are "call home" technologies where the pledge first
              establishes a connection to a well known 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:</t>
        <ul spacing="normal">
          <li>the pledge requires realtime real-time connectivity to the manufacturer
                  service,</li>
          <li>the domain identity is exposed to the manufacturer service (this is a
                  privacy concern),</li> concern), and</li>
          <li>the manufacturer is responsible for making the authorization
                  decisions (this is a liability concern),</li> concern).</li>
        </ul>
        <t>BRSKI addresses these issues by defining extensions to the EST protocol
             for the automated distribution of vouchers.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
          "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

        <t>The following terms are defined for clarity:</t>
        <dl newline="false" spacing="normal">
          <dt>ANI:</dt>
          <dd>The Autonomic Network Networking Infrastructure as
            defined by <xref target="I-D.ietf-anima-reference-model" target="RFC8993" format="default"/>.
            <xref target="acpapplicability" format="default"/> details specific requirements for pledges,
            proxies
            proxies, and registrars when they are part of an ANI.</dd>
          <dt>Circuit Proxy:</dt>
          <dd>A stateful implementation
              of the join proxy. Join Proxy. This is the assumed type of proxy.</dd>
          <dt>drop-ship:</dt>
          <dd>The physical distribution of equipment
            containing the "factory default" configuration to a final
            destination. In zero-touch scenarios scenarios, there is no staging or
            pre-configuration
            preconfiguration during drop-ship.</dd>
          <dt>Domain:</dt>
          <dd>The set of entities that share a common local
            trust anchor. This includes the proxy, registrar,
            Domain Certificate Authority, Management components
            domain CA, management components, and any
          existing entity that is already a member of the domain.</dd>
          <dt>domainID:</dt>
          <dd>The domain IDentity is a unique value
            based upon the Registrar CA's certificate.
            <xref target="domainID" format="default"/> specifies how it is calculated.
            </dd>
	     <dt>Domain CA:</dt>
          <dd>The domain Certification Authority (CA)
            provides certification functionalities to the domain. At a minimum minimum,
            it provides certification functionalities to a registrar and
            manages the private key that defines the domain. Optionally, it
            certifies all elements.</dd>
          <dt>domainID:</dt>
          <dd>The domain IDentity is a unique value
            based upon the registrar's CA certificate.
            <xref target="domainID" format="default"/> specifies how it is calculated.
            </dd>
          <dt>enrollment:</dt>
          <dd>The process where a device presents key
            material to a network and acquires a network-specific identity.
            For example example, when a certificate signing request is presented to a
            certification authority
            CA, and a certificate is obtained in
          response.</dd>
	    <dt>IDevID:</dt>
          <dd>An Initial Device Identifier X.509 certificate
            installed by the vendor on new equipment. This is a term from
            802.1AR <xref target="IDevID" format="default"/>.</dd>
          <dt>imprint:</dt>
          <dd>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 certification
            authority 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 <xref target="imprinting" format="default"/>. The analogy to
            Lorenz's work was first noted in <xref target="Stajano99theresurrecting" format="default"/>.</dd>
          <dt>IDevID:</dt>
          <dd>An Initial Device Identity X.509 certificate
            installed by the vendor on new equipment. This is a term from
            802.1AR <xref target="IDevID" format="default"/></dd>

          <dt>IPIP Proxy:</dt>
          <dd>A stateless proxy alternative.</dd>
          <dt>Join Proxy:</dt>
          <dd>A domain entity that helps the pledge join
            the domain. A join proxy 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 simplicity, this document sometimes uses the
            term of 'proxy' "proxy" to indicate the join proxy. Join Proxy. The pledge
            is unaware that they are communicating with a
            proxy rather than directly with a registrar.</dd>
          <dt>Join Registrar (and Coordinator):</dt>
          <dd>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 "Join Registrar (and coordinator)" Coordinator)" to control this process. Typically Typically, a
            join registrar
            Join Registrar is "inside" its domain. For simplicity simplicity, this document
            often refers to this as just "registrar". Within <xref target="I-D.ietf-anima-reference-model" format="default"/> this target="RFC8993" format="default"/>, it is
            referred to as the "join registrar autonomic service agent". "Join Registrar Autonomic Service Agent (ASA)".
            Other communities use the abbreviation "JRC".
            </dd>
          <dt>LDevID:</dt>
          <dd>A Local Device Identity Identifier X.509 certificate
            installed by the owner of the equipment. This is a term from
            802.1AR <xref target="IDevID" format="default"/></dd> format="default"/>.</dd>
          <dt>manufacturer:</dt>
          <dd>the
          <dd>The term manufacturer is used
            throughout this document to be as the entity that created the
            device.  This is typically the "original original equipment manufacturer"
            or OEM, manufacturer
            (OEM), but in more complex situations situations, it could be a "value value added
            retailer"
            retailer (VAR), or possibly even a systems integrator.  In
            general, it 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 field, increasing the chance that firmware will
            be more up to date.
            </dd>
          <dt>MASA Audit-Log:</dt>
          <dd>An anonymized list of previous owners
            maintained by the MASA on a per device (per pledge)
            basis. Described per-device (per-pledge)
            basis, as described in <xref target="MASAauditlog" format="default"/>.
            </dd>
          <dt>MASA Service:</dt>
          <dd>A third-party Manufacturer Authorized
            Signing Authority (MASA) MASA service on the global Internet. The MASA
            signs vouchers. It also provides a repository for audit-log
            information of privacy protected privacy-protected bootstrapping events. It does
            not track ownership. </dd>
          <dt>nonced:</dt>
          <dd>a
          <dd>A voucher (or request) that contains a nonce (the normal
          case).</dd>
         <dt>nonceless:</dt>
          <dd>a
          <dd>A voucher (or request) that does not
            contain a nonce, relying nonce and either relies upon accurate clocks for expiration, expiration or
            which
            does not expire.</dd>
          <dt>offline:</dt>
          <dd>When an architectural component cannot
              perform realtime real-time communications with a peer, either due to
              either network connectivity or because the peer is being turned off, the
              operation is said to be occurring offline.</dd>
          <dt>Ownership Tracker:</dt>
          <dd>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. Ownership tracking
	    Tracking information about ownership is indicated in
            vouchers
            vouchers, as described in <xref target="RFC8366" format="default"/></dd> format="default"/>.</dd>
          <dt>Pledge:</dt>
          <dd>The prospective (unconfigured) device, which has an
            identity installed at the factory.</dd>
          <dt>(Public) Key Infrastructure:</dt>
          <dd> The collection of systems and
            processes that sustain sustains the activities of a public key system.
            The registrar acts as an a "Registration Authority"; see
            <xref target="RFC5280" format="default"/> and <xref
	    target="RFC5272" format="default"/> (see
              section 7) "Registration Authority".</dd> sectionFormat="of" section="7"/>.</dd>
          <dt>TOFU:</dt>
          <dd>Trust on First Use. Used similarly to how it is described in <xref target="RFC7435" format="default"/>. 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.</dd>
          <dt>Voucher:</dt>
          <dd>A signed artifact from the MASA
            that indicates to a pledge the cryptographic identity of the
            registrar it should trust. trust to a pledge. There are different types of vouchers
            depending on how that trust is asserted. Multiple voucher types are
            defined in <xref target="RFC8366" format="default"/></dd> format="default"/>.</dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>Scope of solution</name> Solution</name>
        <section numbered="true" toc="default">
          <name>Support environment</name> Environment</name>
          <t>
          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 CPE ISP-provided Customer Premises Equipment (CPE) devices which 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
        a priori which device will go to which location.
          </t>
          <t>
          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.
          </t>
          <t>
          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. "handoff".
          BRSKI does not provide a low-latency handoff handoff, which is usually a
          requirement in such situations.
          For these solutions 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.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Constrained environments</name> Environments</name>
          <t>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 <xref target="RFC7228" format="default"/> is best used to describe the boundaries.</t>
          <t>The solution described in this document is aimed in general at
        non-constrained (i.e., class Class 2+ <xref target="RFC7228" format="default"/>) devices operating on a non-Challenged non-challenged
        network. The entire solution as described here is not intended to be
        useable as-is
        usable as is by constrained devices operating on challenged networks
          (such as 802.15.4 Low-power Low-Power and Lossy Networks (LLN)s).</t> (LLNs)).</t>

          <t>Specifically, there are protocol aspects described here that might
        result in congestion collapse or energy-exhaustion energy exhaustion of intermediate
        battery powered
        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 out of scope, but the underlying protocol operations
        (TLS handshake and signing structures) have sufficient algorithm
          agility to support such techniques when defined.</t>

          <t>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, powered and speak
        802.11). use
        802.11 wireless technology). It could also be used by non-constrained devices across a
        non-energy constrained, but challenged challenged, network (such as 802.15.4). The
        certificate contents, and the process by which the four
        questions above are resolved resolved, do apply to constrained devices. It is
        simply the actual on-the-wire imprint protocol that could be
        inappropriate.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Network Access Controls</name>
          <t>This document presumes that network access control has either
        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 Initial
        Device Identity IDevID is consistent with IEEE 802.1AR <xref target="IDevID" format="default"/>, 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 <xref target="RFC3748" format="default"/>), is out-of-scope.</t> out of scope for this document.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Bootstrapping is not Not Booting</name>
          <t>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.</t>
        </section>
      </section>
      <section anchor="PostEnrollment" numbered="true" toc="default">
        <name>Leveraging the new key infrastructure New Key Infrastructure / next steps</name> Next Steps</name>
        <t>
          As a result of the protocol described herein, the bootstrapped devices
          have the Domain domain CA trust anchor in common. An end entity end-entity (EE) certificate has
          optionally been issued from the Domain domain CA. This makes it possible
          to securely deploy functionalities across the domain, e.g:</t> domain; for example:</t>
        <ul spacing="normal">
          <li>Device management.</li> management</li>
          <li>Routing authentication.</li> authentication</li>
          <li>Service discovery.</li> discovery</li>
        </ul>
        <t>
          The major intended benefit is that it possible the ability to use the credentials
     deployed by this protocol to secure the
          Autonomic Control Plane (ACP) (<xref target="I-D.ietf-anima-autonomic-control-plane" format="default"/>). <xref target="RFC8994" format="default"/>.
        </t>
      </section>
      <section anchor="ANIrequirements" numbered="true" toc="default">
        <name>Requirements for Autonomic Network Networking Infrastructure (ANI) devices</name> Devices</name>
        <t>
          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.
        </t>
        <t>
          For devices that intend to become part of an Autonomic Network
          Infrastructure (ANI)
          (<xref target="I-D.ietf-anima-reference-model" format="default"/>) ANI
          <xref target="RFC8993" format="default"/> that includes an
          Autonomic Control Plane
          (<xref target="I-D.ietf-anima-autonomic-control-plane" format="default"/>),
          <xref target="RFC8994" format="default"/>, the
          BRSKI protocol MUST <bcp14>MUST</bcp14> be implemented.
        </t>
        <t>
          The pledge must perform discovery of the proxy as described in
          <xref target="discovery" format="default"/> using Generic Autonomic Signaling
          Protocol (GRASP)'s DULL the Discovery Unsolicited
   Link-Local (DULL) <xref target="I-D.ietf-anima-grasp" target="RFC8990" format="default"/> M_FLOOD announcements. announcements of the GeneRic Autonomic Signaling Protocol (GRASP).
        </t>
        <t>
          Upon successfully validating a voucher artifact, a status telemetry
          MUST
          <bcp14>MUST</bcp14> be returned. See returned; see <xref target="pledgestatus" format="default"/>.
        </t>
        <t>
          An ANIMA ANI pledge MUST <bcp14>MUST</bcp14> implement the EST automation
          extensions described in <xref target="ESTintegration" format="default"/>.
          They supplement the EST <xref target="RFC7030" format="default"/> EST to better
          support automated devices that do not have an end user.
        </t>
        <t>
          The ANI Join Registrar Autonomic Service Agent (ASA) MUST ASA <bcp14>MUST</bcp14> support all the BRSKI and above listed above-listed EST operations.
        </t>
        <t>
          All ANI devices SHOULD <bcp14>SHOULD</bcp14> support the BRSKI proxy function, using
          circuit proxies
          Circuit Proxies over the ACP. (See Autonomic Control Plane (ACP) (see <xref target="JRCgrasp" format="default"/>) format="default"/>).
        </t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Architectural Overview</name>
      <t>The logical elements of the bootstrapping framework are described in
      this section. <xref target="architecturefigure" format="default"/> provides a simplified overview of the components.
      </t>
      <figure anchor="architecturefigure">
        <name>Architecture Overview</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                                           +------------------------+
   +--------------Drop Ship----------------|
   +--------------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. RFC7030 e.g., RFC 7030 .
|       |     .           +-----------------+----------+     .
|       |     .           | Key Infrastructure         |     .
|       |     .           | (e.g., PKI Certificate CA)             |     .
+-------+     .           |       Authority)                            |     .
              .           +----------------------------+     .
              .                                              .
              ................................................
                            "Domain" components Components
]]></artwork>
      </figure>
      <t>We assume a multi-vendor multivendor network. In such an environment environment, there could
      be a Manufacturer Service 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 ownership tracking services for multiple
      manufacturers due to the required sales channel integrations necessary to
      track ownership.</t>

      <t>The domain is the managed network infrastructure with a Key Infrastructure 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 manufacturer service. Optionally, the registrar
      also acts as a PKI Certification Authority.</t> CA.</t>
      <section numbered="true" toc="default">
        <name>Behavior of a Pledge</name>
        <t>The pledge goes through a series of steps, which are outlined here
        at a high level.</t>
        <figure anchor="pledgestatusfigure">
          <name>Pledge State Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               ------------
              /  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  ) codes)
^------------+              |\___/ (e.g. (e.g., 202 'Retry-After') "Retry-After")
| Enroll     +------+-------+
| Failure failure           |
|              -----v------
|             /  Enrolled  \
^------------+             |
 Factory      \------------/
 reset

]]></artwork>
        </figure>
        <t>State descriptions for the pledge are as follows:</t>
        <ol spacing="normal" type="1">
          <li>Discover a communication channel to a registrar.</li>
          <li>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).</li> time.)</li>
          <li>Request to join the discovered registrar. A unique nonce is
                included
                included, ensuring that any responses can be associated with this
                particular bootstrapping attempt.</li>
          <li>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.
            </li>
          <li>Enroll. After imprint imprint, an authenticated TLS (HTTPS) connection exists
            between the pledge and registrar.
            Enrollment over Secure Transport (EST)
            EST <xref target="RFC7030" format="default"/> can then be used to obtain a domain
            certificate from a registrar.</li>
        </ol>
        <t>
          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.
        </t>
        <t>
          This specification details integration with EST enrollment so that pledges can
          optionally obtain a locally issued certificate, although any
          Representational State Transfer (REST) (see <xref target="REST" format="default"/>)
          interface could be integrated in future work.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Secure Imprinting using Using Vouchers</name>
        <t>A voucher is a cryptographically protected artifact (using a digital signature) to the pledge
        device authorizing a zero-touch imprint on the registrar
        domain. </t>

        <t>The format and cryptographic mechanism of vouchers is described in
        detail in <xref target="RFC8366" format="default"/>.</t>

        <t>Vouchers provide a flexible mechanism to secure imprinting: the
        pledge device only imprints when a voucher can be validated.
        At the lowest security levels levels, the MASA can indiscriminately issue
        vouchers and log claims of ownership by domains.  At the highest security
        levels
        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 leverage either leverage the currently defined claim
            mechanisms or to experiment with higher or lower security levels.
        </t>
        <t>
          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.
        </t>
      </section>
      <section anchor="IDevIDextension" numbered="true" toc="default">
        <name>Initial Device Identifier</name>
        <t>
          Pledge authentication and pledge voucher-request signing is via
          a PKIX-shaped certificate installed
          during the manufacturing process. This is the 802.1AR Initial
          Device Identifier (IDevID),
          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:
        </t>
        <ol spacing="normal" type="1">
        <ul>
          <li>
              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. <xref target="idevidprivacy" format="default"/> discusses privacy implications of the identifier.
            </li>
          <li>
              Provides
              Providing a cryptographic authentication of the pledge to the
              Registrar
              registrar (see <xref target="pledgeauthorization" format="default"/>).
            </li>
          <li>
              Secure
              Securing auto-discovery of the pledge's MASA by the registrar
              (see <xref target="obtainmasaurl" format="default"/>).
            </li>
          <li>
              Signing of a voucher-request by the pledge's IDevID
              (see <xref target="voucher-request" format="default"/>).
            </li>
          <li>
              Provides
              Providing a cryptographic authentication of the pledge to the
              MASA (see <xref target="MASAassertion" format="default"/>).
            </li>
        </ol>
        </ul>
        <t>
          Section
          Sections 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of
          <xref target="IDevID" format="default"/> discusses discuss keyUsage and
          extendedKeyUsage extensions in the IDevID certificate.
          <xref target="IDevID" format="default"/> acknowledges that adding restrictions
          in the certificate limits applicability of these long-lived
          certificates.  This specification emphasizes this point, point and
          therefore RECOMMENDS that no key usage restrictions be included.
          This is consistent with <xref target="RFC5280" format="default"/> section 4.2.1.3, sectionFormat="comma"
section="4.2.1.3"/>,
          which does not
          require key usage restrictions for end entity end-entity certificates.
        </t>
        <section anchor="PledgeIdentification" numbered="true" toc="default">
          <name>Identification of the Pledge</name>
          <t>

            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" serial-number
            field of a voucher or voucher-requests (see <xref target="voucher-request" format="default"/>)
            and in local policies on the registrar or MASA
            (see <xref target="ProtocolDetails" format="default"/>).
          </t>

	  <t>
            The
   There is a (certificate) serialNumber field is defined in <xref target="RFC5280" format="default"/>.
            That specification allows for sectionFormat="comma"
section="4.1.2.2"/>.  In ASN.1, this is referred to as the
   CertificateSerialNumber.  This field to be omitted if there is
            a good technical reason. IDevID certificates for use
            with this protocol are REQUIRED NOT relevant to include the "serialNumber" attribute this
   specification.  Do not confuse this field with the device's
            unique serial number
            (from serial-number
   defined by this document, or by <xref target="IDevID" format="default"/> section 7.2.8, and <xref target="RFC4519" sectionFormat="comma" section="2.31"/>.
	  </t>
	  <t>
The device serial number is defined in <xref target="RFC5280" format="default"/> section 4.1.2.2's list of standard
            attributes). section="A.1" sectionFormat="of"/> as the X520SerialNumber, with the OID tag id-at-serialNumber.
	  </t>

	  <t>
   The serialNumber device <em>serialNumber</em> field (X520SerialNumber) is used as follows
   by the pledge to build the
            "serial-number" <strong>serial-number</strong> 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".
	  </t>

          <t>
            An example of a printable form of the "serialNumber" serialNumber field
            is provided in <xref target="RFC4519" format="default"/> section 2.31 sectionFormat="comma" section="2.31"/> ("WI-3005").
            That section further provides equality and syntax attributes.
          </t>
          <t>
            Due to the reality of existing device identity provisioning
            processes, some
            manufacturers have stored serial-numbers in other
            fields. Registrar's SHOULD
	    Registrars <bcp14>SHOULD</bcp14> be configurable, on a per-manufacturer
            basis, to look for serial-number equivalents in other fields.
          </t>
          <t>
            As explained in <xref target="RequestVoucherFromMASA" format="default"/> format="default"/>, the Registrar MUST registrar <bcp14>MUST</bcp14> again extract the
            serial-number again
            serialNumber itself from the pledge's TLS certificate.  It
            can consult the serial-number in the pledge-request pledge request if there are is
            any possible confusion about the source of the serial-number.
          </t>
        </section>
        <section anchor="MASAURL" numbered="true" toc="default">
          <name>MASA URI extension</name> Extension</name>
          <t>
            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 <xref
target="RFC5280" format="default"/>. sectionFormat="of" section="7.4"/>.
          </t>
          <t>
            The URI provides the authority information.
            The BRSKI "/.well-known" tree (<xref target="RFC5785" format="default"/>) <xref target="RFC8615" format="default"/> is
            described in <xref target="ProtocolDetails" format="default"/>.
          </t>
          <t>
            A complete URI MAY <bcp14>MAY</bcp14> be in this extension, including the 'scheme', 'authority', "scheme", "authority", and 'path', "path".
            The complete URI will typically be used in diagnostic or
            experimental situations.
            Typically,

            Typically (and in consideration to constrained systems), this
            SHOULD
            <bcp14>SHOULD</bcp14> be reduced to only the 'authority', "authority", in which
            case a scheme of "https://"
            (<xref
            (see <xref target="RFC7230" format="default"/> section 2.7.3) sectionFormat="comma" section="2.7.3"/>)
            and 'path' a "path" of "/.well-known/est" "/.well-known/brski" is to be
            assumed.

          </t>
          <t>
            The registrar can assume that only the 'authority' "authority" is present in
            the extension, if there are no slash ("/") characters in the
            extension.
          </t>
          <t>
            Section 7.4 of
            <xref target="RFC5280" format="default"/> sectionFormat="of" section="7.4"/> calls out various
            schemes that MUST <bcp14>MUST</bcp14> be supported, including LDAP, HTTP the Lightweight Directory Access Protocol (LDAP), HTTP, and FTP.
            However, the registrar MUST <bcp14>MUST</bcp14> use HTTPS for the BRSKI-MASA connection.
          </t>
          <t>The new extension is identified as follows:</t>
          <figure anchor="masaurlmodule">
            <name>MASAURL ASN.1 Module</name>

            <sourcecode name="" type="" type="asn.1" markers="true"><![CDATA[
MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-MASAURLExtn2016(TBD) 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 TBD 32 }

MASAURLSyntax ::= IA5String

END

]]></sourcecode>
          </figure>

          <t>The choice of id-pe is based on guidance found in Section 4.2.2 of
          [RFC5280], <xref
target="RFC5280" sectionFormat="of" section="4.2.2" />: "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. </t>
        </section>
      </section>
      <section anchor="flow" numbered="true" toc="default">
        <name>Protocol Flow</name>
        <t>A representative flow is shown in
        <xref target="protocoltimesequencefigure" format="default"/></t> format="default"/>.</t>
        <figure anchor="protocoltimesequencefigure">
          <name>Protocol Time Sequence Diagram</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+         +---------+    +------------+     +------------+
| Pledge |         | Circuit |    | Domain     |     | Vendor     |
|        |         | Join    |    | Registrar  |     | Service    |
|        |         | Proxy   |    |  (JRC)     |     | (MASA)     |
+--------+         +---------+    +------------+     +------------+
  |                     |                   |           Internet |
[discover]              |                   |                    |
  |<-RFC4862
  |<-RFC 4862 IPv6 addr |                   |                    |
  |<-RFC3927
  |<-RFC 3927 IPv4 addr | Appendix A        |  Legend            |
  |-++++++++++++++++++->|                   | C - circuit Circuit        |
  | optional: mDNS query| Appendix B        |      join proxy     Join Proxy     |
  | RFC6763/RFC6762 RFCs 6763/6762 (+)  |                   | P - provisional   | Provisional TLS|
  |<-++++++++++++++++++-|                   |    TLS connection     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
  P---Voucher-Request(w/nonce for voucher)->|                    |
  P                  /-------------------   |                    |
  P                  |                 [accept device?]          |
  P                  |                 [contact Vendor] vendor]          |
  P                  |                      |--Pledge ID-------->|
  P                  |                      |--Domain ID-------->|
  P                  |                      |--optional:nonce--->|
  P              optional:                  |     [extract DomainID]
  P        can occur in advance             |     [update audit log] audit-log]
  P            if nonceleess nonceless                 |                    |
  P                  |                      |<- voucher ---------|
  P                  \-------------------   | w/nonce if provided|
  P<------voucher---------------------------|                    |
[imprint]                                   |                    |
  |-------voucher status telemetry--------->|                    |
  |                                         |<-device audit log--| audit-log--|
  |                             [verify audit log audit-log and voucher]   |
  |<--------------------------------------->|                    |
[enroll]                                    |                    |
  | Continue with RFC7030 enrollment using now      |                    |
  | using now bidirectionally authenticated TLS       |                    |
  | TLS session. session per RFC 7030.                   |                    |
[enrolled]                                  |                    |
]]></artwork>
        </figure>
        <t>
          On initial bootstrap, a new device (the pledge) uses a local service
          autodiscovery (GRASP
          auto-discovery (the GeneRic Autonomic Signaling Protocol (GRASP) or mDNS) Multicast DNS (mDNS)) to locate a join proxy. Join Proxy.  The
          join proxy
          Join Proxy connects the pledge to a local registrar (the JRC).
        </t>
        <t>
          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 voucher-request and its device identity
          IDevID certificate (IDevID) as part of the TLS session.
        </t>
        <t>
          The registrar can determine whether it expected such a device to
          appear,
          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 voucher-request
          (including device the device's serial number) is transmitted over the internet Internet in a
          TLS protected
          TLS-protected channel to the manufacturer, along with information about
          the registrar/owner.
        </t>
        <t>
          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.
        </t>
        <t>
          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, with and whether
          the bootstrap should be accepted.
        </t>
        <t>
          No filtering of information is possible in the signed voucher, so
          this is a binary yes-or-no decision.  If  After the registrar has applied any local policy to the voucher, if it accepts the voucher as a proper one for its device, voucher, then the voucher is returned to the pledge for imprinting.
        </t>
        <t>
          The voucher also includes a trust anchor that the pledge uses as
          representing to
          represent the owner.
	  This is used to successfully bootstrap from an environment
          where only the manufacturer has built-in trust by the
          device into to an environment where the owner now has a PKI footprint on the
          device.
        </t>
        <t>
          When BRSKI is followed with EST EST, this single footprint is further
          leveraged into the full owner's PKI and a an LDevID for the
          device. Subsequent reporting steps provide flows of  information to
          indicate success/failure of the process.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Architectural Components</name>
        <section anchor="pledge-overview" numbered="true" toc="default">
          <name>Pledge</name>
          <t>
            The pledge is the device that is attempting to join.
            The pledge It is assumed to talk 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.
          </t>
        </section>
        <section anchor="proxy-overview" numbered="true" toc="default">
          <name>Join Proxy</name>
          <t>
            The join proxy Join Proxy provides HTTPS connectivity between the
            pledge and the registrar. A circuit proxy Circuit Proxy mechanism is
            described in <xref target="proxydetails" format="default"/>. Additional
            mechanisms, including a CoAP Constrained Application Protocol (CoAP) mechanism and a stateless
            IPIP mechanism
            IP in IP (IPIP) mechanism, are the subject of future work.
          </t>
        </section>
        <section anchor="registrar-overview" numbered="true" toc="default">
          <name>Domain Registrar</name>
          <t>
            The domain's registrar operates as the BRSKI-MASA client when
            requesting vouchers from the MASA (see <xref target="brskimasatls" format="default"/>). The registrar
            operates as the BRSKI-EST server when pledges request
            vouchers (see <xref target="brskiesttls" format="default"/>). The registrar operates as the BRSKI-EST server
            "Registration Authority" if the pledge requests an end entity end-entity certificate
          over the BRSKI-EST connection (see <xref target="ESTintegration" format="default"/>).
          </t>
          <t>
            The registrar uses an Implicit Trust Anchor database for
            authenticating the BRSKI-MASA connection's MASA TLS Server Certificate. server certificate.
            Configuration or distribution of trust anchors is out-of-scope out of scope
            for this specification.
          </t>
          <t>
            The registrar uses a different Implicit Trust Anchor database for
            authenticating the BRSKI-EST connection's Pledge pledge TLS Client Certificate.
            Configuration or distribution of the BRSKI-EST client trust
            anchors is out-of-scope out of scope of this specification.  Note that the
            trust anchors
            in/excluded
            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.
          </t>
        </section>
        <section anchor="masa-overview" numbered="true" toc="default">
          <name>Manufacturer Service</name>
          <t>
            The Manufacturer Service manufacturer service provides two logically separate functions:
            the Manufacturer Authorized Signing Authority (MASA) MASA as described in Sections
            <xref target="RequestVoucherFromMASA" format="default"/> format="counter"/> and
            <xref target="VoucherResponse" format="default"/>, format="counter"/>
            and an ownership tracking/auditing function as described
            in Sections <xref target="pledgestatus" format="default"/> format="counter"/>
            and <xref target="authzLogRequest" format="default"/>. format="counter"/>.
          </t>
        </section>
        <section anchor="pki-overview" numbered="true" toc="default">
          <name>Public Key Infrastructure (PKI)</name>
          <t>
            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.
          </t>
          <t>
            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.
          </t>
          <t>
            The domain's registrar acts as an a
            Registration Authority <xref target="RFC5272" format="default"/>
            Registration Authority, format="default"/>, requesting certificates for pledges from
            the Key Infrastructure. PKI.
          </t>
          <t>
            The expectations of the PKI are unchanged from EST <xref target="RFC7030" format="default"/>.  This document does
            not place any additional architectural requirements on the Public Key
            Infrastructure. PKI.
          </t>
        </section>
      </section>
      <section anchor="certificatevalidaty" numbered="true" toc="default">
        <name>Certificate Time Validation</name>
        <section anchor="timeunknown" numbered="true" toc="default">
          <name>Lack of realtime clock</name> Real-Time Clock</name>
          <t>
            Many
            When bootstrapping, many devices when bootstrapping do not have knowledge of the
            current time. Mechanisms such as Network Time Protocols cannot be
            secured until bootstrapping is complete. Therefore Therefore, bootstrapping is
            defined with a framework that does not require knowledge of the current
            time.  A pledge MAY <bcp14>MAY</bcp14> ignore all time stamps in the voucher and
            in the certificate validity periods if it does not know
            the current time.
          </t>
          <t>
            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, CMS Cryptographic Message Syntax (CMS) signatures contain a signingTime.
          </t>
          <t>
            A pledge with a real time real-time clock in which it has confidence,
            MUST confidence
            <bcp14>MUST</bcp14> check the above time fields in all certificates and
            signatures that it processes.
          </t>
          <t>
            If the voucher contains a nonce nonce,
            then the pledge MUST <bcp14>MUST</bcp14> confirm the nonce matches the original
            pledge voucher-request. This ensures the voucher is fresh.
            See <xref target="RequestVoucherFromRegistrar" format="default"/>.
          </t>
        </section>
        <section anchor="infinitelifetime" numbered="true" toc="default">
          <name>Infinite Lifetime of IDevID</name>
          <t>
            <xref target="RFC5280" format="default"/> explains that
            long lived
            Long-lived pledge certificates "SHOULD "<bcp14>SHOULD</bcp14> be assigned the
            GeneralizedTime value of 99991231235959Z" for the notAfter field. field as explained in <xref target="RFC5280" format="default"/>.
          </t>
          <t>
            Some deployed IDevID management systems are not compliant
            with the 802.1AR requirement for infinite lifetimes, lifetimes and
            are put in typical &lt;= 3 year certificate lifetimes.
            Registrars SHOULD <bcp14>SHOULD</bcp14> be configurable on a per-manufacturer basis
            to ignore pledge lifetimes when the pledge did does not follow the RFC5280
            recommendations. recommendations in <xref
target="RFC5280"/>.
          </t>
        </section>
      </section>
      <section anchor="cloudregistrar" numbered="true" toc="default">
        <name>Cloud Registrar</name>
        <t>
          There exist operationally open networks wherein devices gain
          unauthenticated access to the Internet at large.
          In these use cases 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 are 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.
        </t>
        <t>
          There
          Additionally, there are additionally 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 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.
        </t>
        <t>
          In order to support these scenarios, the pledge MAY <bcp14>MAY</bcp14> contact a well
          known 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.</t>

        <t>If the pledge uses a well known well-known URI for contacting a cloud registrar registrar,
              a manufacturer-assigned Implicit Trust Anchor database (see <xref target="RFC7030" format="default"/>) MUST <bcp14>MUST</bcp14>
              be used to authenticate that service as described in <xref target="RFC6125" format="default"/>.  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 human-user configuration of an EST server URI in
              <xref target="RFC7030" format="default"/> format="default"/>, which also depends on RFC6125.</t>
<xref target="RFC6125"/>.</t>
      </section>
      <section anchor="obtainmasaurl" numbered="true" toc="default">
        <name>Determining the MASA to contact</name>
        <t>The Contact</name>
<t>
The registrar needs to be able to contact a MASA that is trusted by the pledge in order to obtain vouchers. There are three mechanisms described:</t> vouchers.</t>

        <t>The device's Initial Device Identifier (IDevID) IDevID will normally contain the MASA URL as detailed in <xref target="IDevIDextension" format="default"/>. This is the RECOMMENDED <bcp14>RECOMMENDED</bcp14>
        mechanism.</t>
        <t>It

        <t>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. As development; thus, as a final fallback fallback, the registrar MAY <bcp14>MAY</bcp14> 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.</t>
      </section>
    </section>
    <section anchor="voucher-request" numbered="true" toc="default">
      <name>Voucher-Request artifact</name> Artifact</name>
      <t>
        Voucher-requests are how vouchers are requested.
        The semantics of the voucher-request are described below, in the YANG model. module.
      </t>
      <t>
        A pledge forms the "pledge voucher-request", signs it with it's
        IDevID its
        IDevID, and submits it to the registrar.
      </t>
      <t>
        The
        In turn, the registrar in turn forms the "registrar voucher-request",
        signs it with it's Registrar keypair its registrar key pair, and submits it to the MASA.
      </t>
      <t>
        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.
      </t>
      <t>
        This network proximity results from the following properties in the
        ACP context:  the pledge is connected to the Join Proxy
        (<xref target="proxydetails" format="default"/>) using a Link-Local 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 registrar can observe that the connection is via the
        private ACP (ULA) address of the join proxy, Join Proxy, and could not it cannot come from
        outside the ACP.  The Pledge pledge must therefore be at most one IPv6
        Link-Local
        link-local hop away from an existing node on the ACP.
      </t>
      <t>
        Other users of BRSKI will need to define other kinds of assertions if
        the network proximity described above does not match their needs.
      </t>
      <t>
        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"
        proximity-registrar-cert leaf.
      </t>
      <t>
        Unless otherwise signaled (outside the voucher-request artifact), the
        signing structure is as defined for vouchers, vouchers; see
        <xref target="RFC8366" format="default"/>.
      </t>
      <section anchor="noncelessVoucherRequest" numbered="true" toc="default">
        <name>Nonceless Voucher Requests</name> Voucher-Requests</name>
        <t>
            A registrar MAY <bcp14>MAY</bcp14> 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" 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 Typically, this will
            be done via the scanning of bar-code a bar code or QR-code QR code on packaging, or via
            some sales channel integration.
        </t>
      </section>
      <section anchor="voucher-request-tree-diagram" numbered="true" toc="default">
        <name>Tree Diagram</name>
        <t>The following tree diagram illustrates a high-level view of a
                voucher-request document.  The voucher-request builds upon
                the voucher artifact described in <xref target="RFC8366" format="default"/>.
                The tree diagram is described in <xref target="RFC8340" format="default"/>.
                Each node in the diagram is
                fully described by the YANG module in <xref target="voucher-request-yang-module" format="default"/>.
                Please review the YANG module for a detailed description of the
                voucher-request format.</t>

        <figure anchor="voucherrequest_tree">
          <name>YANG Tree diagram Diagram for a Voucher-Request</name>

          <artwork name="" type="" type="yangtree" align="left" alt=""><![CDATA[
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
]]></artwork>
        </figure>

      </section>
      <!-- tree diagram -->

        <section anchor="voucher-request-examples" numbered="true" toc="default">
        <name>Examples</name>
        <t>This section provides voucher-request examples for illustration
                purposes.
                These examples show the JSON prior to CMS wrapping.
                JSON encoding rules specify that any binary
                content be base64 encoded (<xref target="RFC4648" format="default"/> section 4).
sectionFormat="comma" section="4"/>).
                The contents of the (base64) encoded certificates have been elided
                to save space. For detailed examples, see <xref target="exampleprocess" format="default"/>. These examples conform to the encoding rules
                defined in <xref target="RFC7951" format="default"/>.</t>
        <ol group="examples" spacing="normal" type="Example (%d)"> (%d):">
          <li>The following example illustrates a pledge voucher-request. The
            assertion leaf is indicated as 'proximity' "proximity", and the registrar's TLS server
            certificate is included in the 'proximity-registrar-cert' proximity-registrar-cert leaf. See
            <xref target="RequestVoucherFromRegistrar" format="default"/>.</li>
        </ol>
        <figure anchor="voucherrequest_example1">
          <name>JSON representation Representation of example an Example Voucher-Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="json">
{
    "ietf-voucher-request:voucher": {
        "assertion": "proximity",
        "nonce": "62a2e7693d82fcda2624de58fb6722e5",
        "serial-number" : "JADA123456789",
        "created-on": "2017-01-01T00:00:00.000Z",
        "proximity-registrar-cert": "base64encodedvalue=="
    }
}
]]></artwork>
</sourcecode>
        </figure>
        <ol group="examples" spacing="normal" type="Example (%d)"> (%d):">
          <li>The following example illustrates a registrar voucher-request.
                The 'prior-signed-voucher-request' 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 CMS-signed object.  In the JSON encoding used
                here
                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
                <xref target="RequestVoucherFromMASA" format="default"/>.</li>
        </ol>
        <figure anchor="voucherrequest_prior_example1">
          <name>JSON representation Representation of example an Example Prior-Signed Voucher-Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="json">
{
    "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=="
    }
}
]]></artwork>
</sourcecode>
        </figure>
        <ol group="examples" spacing="normal" type="Example (%d)"> (%d):">
          <li>The following example illustrates a registrar voucher-request.
                The 'prior-signed-voucher-request' 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 can not cannot
                communicate with the registrar (such as when it is powered
                down,
                down or still in packaging), packaging)
                and therefore could not 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
                <xref target="RequestVoucherFromMASA" format="default"/>.</li>
        </ol>
        <figure anchor="voucherrequest_offline_example1">
          <name>JSON representation Representation of an Offline Voucher-Request</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="json">
{
    "ietf-voucher-request:voucher": {
        "created-on":    "2017-01-01T00:00:02.000Z",
        "idevid-issuer": "base64encodedvalue==",
        "serial-number": "JADA123456789"
    }
}
]]></artwork>
</sourcecode>
        </figure>
      </section>
      <!-- examples -->

        <section anchor="voucher-request-yang-module" numbered="true" toc="default">
          <name>YANG Module</name>

        <t>Following is a YANG module <xref target="RFC7950" format="default"/> module that formally
          extending the
          extends a voucher <xref target="RFC8366" format="default"/> voucher into
        a voucher-request.</t> voucher-request.  This YANG module references <xref target="ITU.X690" format="default"/>. </t>

	<figure anchor="voucherrequest_yang">
          <name>YANG module Module for Voucher-Request</name>

          <sourcecode name="ietf-voucher-request@2018-02-14.yang" type="" name="ietf-voucher-request@2021-04-10.yang" type="yang" markers="true"><![CDATA[
module ietf-voucher-request {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
  prefix "vcr"; 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"; 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. voucher-request.
     It is a superset of the voucher itself.
     It provides content to the MASA for consideration
     during a voucher request. 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) 2019 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
    (http://trustee.ietf.org/license-info).
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 8995; see the
     RFC itself for full legal notices.";

  revision "2018-02-14" 2021-04-10 {
    description
      "Initial version";
    reference
      "RFC XXXX: 8995: Bootstrapping Remote Secure Key Infrastructure"; 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,
           voucher-request, and any occurence occurrence MUST be ignored"; ignored.";
      }
      refine "voucher/assertion" {
        mandatory false;
        description
          "Any assertion included in registrar voucher
              requests 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 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, voucher-request, while
             maintaining the prior signature information.

             The Registrar registrar and MASA MAY examine the prior signed prior-signed
             voucher information for the
             purposes of policy decisions.  For example 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 structure, as specified by
             RFC 5280, Section 4 4, encoded using the ASN.1
             distinguished encoding rules (DER), as specified
             in [ITU.X690.1994]. ITU X.690.

             The first certificate in the Registrar registrar TLS server
             certificate_list sequence (the end-entity TLS certificate,
             certificate; see [RFC8446]) RFC 8446) presented by the Registrar registrar
             to the Pledge. pledge.  This MUST be populated in a Pledge's voucher request 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";
        }
      }
    }
  }
}
]]></sourcecode>
        </figure>
      </section>
      <!-- yang module -->
    </section>
    <!-- voucher-request artifact -->
    <section anchor="proxydetails" numbered="true" toc="default">
      <name>Proxying details Details (Pledge - -- Proxy - -- Registrar)</name>
      <t>
        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,
        mechanism and an equivalent mechanism to configure the proxy.
      </t>
      <t>
        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.
      </t>
      <t>
        This section defines a stateful proxy mechanism which that is referred
        to as a "circuit" proxy.  This is a form of Application Level Gateway
        (<xref
        (see <xref target="RFC2663" format="default"/> section 2.9). sectionFormat="comma" section="2.9"/>).
      </t>
      <t>
        The proxy does not terminate the TLS handshake: it passes streams
        of bytes onward without examination.
        A proxy MUST NOT <bcp14>MUST NOT</bcp14> assume any specific TLS version.  Please see
        <xref target="RFC8446" format="default"/> section 9.3 sectionFormat="comma" section="9.3"/> for
details on TLS invariants.
      </t>
      <t>
        A Registrar registrar can directly provide the proxy announcements
        described below, in which case the
        announced port can point directly to the Registrar registrar itself.  In this
        scenario
        scenario, the pledge is unaware that there is no proxying occurring.
        This is useful for Registrars which registrars that are servicing pledges on directly
        connected networks.
      </t>
      <t>
        As a result of the proxy Discovery discovery process in <xref target="brskigrasp" format="default"/>,
        the port number exposed by the proxy
        does not need to be well known, known or require an IANA allocation.
      </t>
      <t>
        During the discovery of the Registrar 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 which that the Join Proxy and Registrar registrar have in common.
      </t>
      <t>
        In order to permit the proxy functionality to be implemented on the
        maximum variety of devices 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 control-plane CPU of such a device,
        with available capabilities for the proxy function similar to many
        class 2 IoT devices.
      </t>
      <t>
        The document <xref target="I-D.richardson-anima-state-for-joinrouter" format="default"/> provides a
        more extensive analysis and background of the alternative proxy methods.
      </t>
      <section anchor="discovery" numbered="true" toc="default">
        <name>Pledge discovery Discovery of Proxy</name>
        <t>
              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 link-local addresses.
        </t>
        <t>To discover the proxy proxy, the pledge performs the following
                actions:</t>
        <ol spacing="normal" type="1">
          <li>MUST: Obtains
          <li><bcp14>MUST</bcp14>: Obtain a local address using IPv6
                    methods as described in <xref target="RFC4862" format="default"/> IPv6 "IPv6
                    Stateless Address AutoConfiguration. Autoconfiguration" <xref target="RFC4862" format="default"/>.
                    Use of <xref target="RFC4941" format="default"/> temporary addresses <xref target="RFC8981" format="default"/> is
                    encouraged.  To limit pervasive monitoring (
                    <xref target="RFC7258" format="default"/>), format="default"/>, a new temporary address MAY <bcp14>MAY</bcp14>
                    use a short lifetime (that is, set TEMP_PREFERRED_LIFETIME
                    to be short).
                    Pledges will generally prefer use of IPv6 Link-Local link-local
                    addresses, and discovery of the proxy will be by Link-Local link-local
                    mechanisms.
                    IPv4 methods are described in <xref target="IPv4operations" format="default"/></li>
          <li>MUST: format="default"/>.</li>

          <li><bcp14>MUST</bcp14>: Listen for GRASP M_FLOOD
                    (<xref target="I-D.ietf-anima-grasp" format="default"/>)
                    <xref target="RFC8990" format="default"/>
                    announcements of the objective: "AN_Proxy".
                    See section <xref target="brskigrasp" format="default"/> for the details of
                    the objective.  The pledge MAY <bcp14>MAY</bcp14> listen concurrently for
                    other sources of information, information; see <xref target="mdnsmethods" format="default"/>.
                </li>
        </ol>
        <t>

            Once a proxy is
            discovered
            discovered, the pledge communicates with a registrar through the
            proxy using the bootstrapping protocol defined in <xref target="ProtocolDetails" format="default"/>.
        </t>
        <t>
              While the GRASP M_FLOOD mechanism is passive for the pledge, the
              non-normative other methods (mDNS, (mDNS and IPv4 methods) described in
              <xref target="mdnsmethods" format="default"/> are active.
              The pledge SHOULD <bcp14>SHOULD</bcp14> run those methods in parallel with listening
              to
              for the M_FLOOD.  The active methods SHOULD
              back-off <bcp14>SHOULD</bcp14>
              back off by doubling to a maximum of one hour to avoid overloading the
              network with discovery attempts.  Detection of change of
              physical link status change (Ethernet carrier carrier, for instance) SHOULD <bcp14>SHOULD</bcp14>
              reset the back off back-off timers.
        </t>
        <t>
              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 Layer 2/3 Ethernet switch may have
              hundreds of physical ports.
        </t>
        <t>
              Each possible proxy offer SHOULD <bcp14>SHOULD</bcp14> 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.
        </t>
        <t>
              The connection attempts via a single proxy SHOULD <bcp14>SHOULD</bcp14> exponentially
              back-off
              back off to a maximum of one hour to avoid overloading the network
              infrastructure.   The back-off timer for each  MUST  <bcp14>MUST</bcp14> be
              independent of other connection attempts.
        </t>
        <t>
                Connection attempts SHOULD <bcp14>SHOULD</bcp14> be run in
                parallel to avoid head of queue head-of-queue problems wherein an attacker
                running a fake proxy or registrar could intentionally perform protocol
                actions intentionally slowly.  Connection attempts to
                different proxies SHOULD <bcp14>SHOULD</bcp14> be sent with an interval of 3 to
                5s. The pledge SHOULD <bcp14>SHOULD</bcp14> continue to
                listen to for additional GRASP M_FLOOD messages during
                the connection attempts.
        </t>
        <t>
              Each connection attempt through a distinct Join Proxy MUST <bcp14>MUST</bcp14>
              have a unique nonce in the voucher-request.
        </t>
        <t>
              Once a connection to a
              registrar is established (e.g. (e.g., establishment of a TLS session key) key),
              there are expectations of more timely responses, responses; see <xref target="RequestVoucherFromRegistrar" format="default"/>.
        </t>
        <t>
              Once all discovered services are attempted (assuming that none
              succeeded)
              succeeded), the device MUST <bcp14>MUST</bcp14> return to listening for GRASP M_FLOOD.
              It SHOULD <bcp14>SHOULD</bcp14> periodically retry any manufacturer-specific mechanisms.
              The pledge MAY <bcp14>MAY</bcp14> prioritize selection order as
              appropriate for the anticipated environment.
        </t>
        <section anchor="brskigrasp" numbered="true" toc="default">
          <name>Proxy GRASP announcements</name> Announcements</name>
          <t>
               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
               <xref target="I-D.ietf-anima-autonomic-control-plane" target="RFC8994" format="default"/>.

          </t>
          <t>
               The formal Concise Data Definition Language (CDDL) <xref
target="RFC8610" format="default"/> definition is:
</t>
          <figure anchor="proxy_discovery_cddl">
            <name>CDDL definition Definition of Proxy Discovery message</name> Message</name>

            <sourcecode name="proxygrasp.cddl" type="" type="CDDL" markers="true"><![CDATA[
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 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
                                 ; [GRASP] section RFC 8990, Section 2.9.5.1, note
                                 ; Note 3.
port-number      = selected by Proxy
]]></sourcecode>
          </figure>
          <t>
               Here is an example M_FLOOD announcing a proxy at fe80::1,
               on TCP port 4443.
	  </t>

          <figure anchor="proxy_discovery_mflood">
            <name>Example of Proxy Discovery message</name> Message</name>

 <artwork name="" type="" align="left" alt=""><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
            [["AN_Proxy", 4, 1, ""],
             [O_IPv6_LOCATOR,
              h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]]
]]></artwork>
          </figure>
          <t>
               On a small network network, the Registrar MAY registrar <bcp14>MAY</bcp14> include the GRASP
               M_FLOOD announcements to locally connected networks.
          </t>
          <t>
               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 document, are optional. Other
               methods MUST NOT <bcp14>MUST NOT</bcp14> be enabled unless the Join Registrar ASA
               indicates support for them in it's its own announcement.
          </t>
        </section>
      </section>
      <section anchor="coapconnection" numbered="true" toc="default">
        <name>CoAP connection Connection to Registrar</name>
        <t>
          The use of CoAP to connect from pledge to registrar
          is out of scope for this document, document and is described in future
          work. See <xref target="I-D.ietf-anima-constrained-voucher" format="default"/>.
        </t>
      </section>
      <section anchor="JRCgrasp" numbered="true" toc="default">
        <name>Proxy discovery Discovery and communication Communication of Registrar</name>
        <t> The registrar SHOULD <bcp14>SHOULD</bcp14> announce itself so that proxies can find it
        and determine what kind of connections can be terminated.
        </t>
	<t>
          The registrar announces itself using ACP instance of GRASP using M_FLOOD messages. messages,
          with the "AN_join_registrar" objective, within the ACP instance.
          A registrar may announce any convenient port
          number, including using a use of stock port 443.
          ANI proxies MUST <bcp14>MUST</bcp14> support GRASP discovery of registrars.
	</t>

        <t>
          The M_FLOOD is formatted as follows:
</t>
        <figure anchor="registrar_discovery_example1">
          <name>An example Example of a Registrar announcement message</name> Announcement Message</name>

          <artwork name="" type="" align="left" alt=""><![CDATA[
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
            [["AN_join_registrar", 4, 255, "EST-TLS"],
             [O_IPv6_LOCATOR,
              h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]]
]]></artwork>

        </figure>
        <t>
          The formal CDDL definition is:
</t>
        <figure anchor="registrar_discovery_cddl">
          <name>CDDL definition Definition for Registrar announcement message</name> Announcement Message</name>

          <sourcecode name="jrcgrasp.cddl" type="" type="CDDL" markers="true"><![CDATA[
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 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) of supported
                             ; protocols: "EST-TLS" for RFC7030. RFC 7030.
]]></sourcecode>
        </figure>
        <t>
          The M_FLOOD message MUST <bcp14>MUST</bcp14> be sent periodically.  The default period SHOULD <bcp14>SHOULD</bcp14> be
          60 seconds, and the value SHOULD <bcp14>SHOULD</bcp14> be operator configurable but SHOULD
          NOT <bcp14>SHOULD
          NOT</bcp14> be smaller than 60 seconds.  The frequency of sending MUST <bcp14>MUST</bcp14> be such
          that the aggregate amount of periodic M_FLOODs from all flooding
          sources cause causes only negligible traffic across the ACP.
        </t>
        <t>
               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.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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]]]></artwork>
        <t>
               A protocol of 6 indicates that TCP proxying on the
               indicated port is desired.
        </t>
        <t>
               Registrars MUST <bcp14>MUST</bcp14> announce the set of protocols that they
               support.  They MUST
               support, and they <bcp14>MUST</bcp14> support TCP traffic.
        </t>
        <t>
               Registrars MUST <bcp14>MUST</bcp14> accept HTTPS/EST traffic on the TCP ports
               indicated.
        </t>
        <t>
               Registrars MUST <bcp14>MUST</bcp14> support the ANI TLS circuit proxy Circuit Proxy and
               therefore BRSKI across HTTPS/TLS native across the ACP.
        </t>
        <t>
               In the ANI, the Autonomic Control Plane (ACP) secured ACP-secured instance of
               GRASP (<xref target="I-D.ietf-anima-grasp" format="default"/>) MUST <xref target="RFC8990" format="default"/> <bcp14>MUST</bcp14> be used for
               discovery of ANI registrar ACP addresses
               and ports by ANI proxies.  The  Therefore, the TCP leg of the proxy connection between
               the ANI proxy and ANI registrar therefore also runs across the ACP.
        </t>
      </section>
    </section>
    <section anchor="ProtocolDetails" numbered="true" toc="default">
      <name>Protocol Details (Pledge - -- Registrar - -- MASA)</name>
      <t>The pledge MUST <bcp14>MUST</bcp14> initiate BRSKI after boot if it is unconfigured.
        The pledge MUST NOT <bcp14>MUST NOT</bcp14> automatically initiate BRSKI if it has been
        configured or is in the process of being configured.</t>
      <t>
          BRSKI is described as extensions to EST <xref target="RFC7030" format="default"/>.
          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 same "/.well-known" "/.well-known/brski" URI tree as and implements the existing EST URIs as
          described in
          EST <xref target="RFC7030" format="default"/> section 3.2.2. sectionFormat="comma" section="3.2.2"/>. The communication channel
          between the pledge and the registrar is referred to as "BRSKI-EST"
          (see <xref target="architecturefigure" format="default"/>).
      </t>
      <t>The
      <t>
	The communication channel between the registrar and MASA is similarly described as extensions a new
   communication channel, similar to EST EST, within the same "/.well-known" newly registered
   "/.well-known/brski" tree.  For clarity clarity, this channel is referred to
   as "BRSKI-MASA". (See "BRSKI-MASA" (see <xref target="architecturefigure" format="default"/>).</t> format="default"/>).
      </t>

      <t>The MASA URI is "https://" authority "/.well-known/est".</t> "/.well-known/brski".</t>

      <t>
          BRSKI uses existing CMS message formats for existing EST
          operations.  BRSKI uses JSON
          <xref target="RFC8259" format="default"/> for all new operations defined here, here and
          for voucher formats. In all places where a binary value must be carried
          in a JSON string, the use of a base64 format (<xref target="RFC4648" format="default"/> section 4)
sectionFormat="comma" section="4"/>) is to be used, as per
          <xref target="RFC7951" format="default"/> section 6.6. sectionFormat="comma" section="6.6"/>.
      </t>
      <t>
          While EST section 3.2 (<xref target="RFC7030" sectionFormat="comma" section="3.2"/>) does not insist upon use of HTTP
          persistent connections
          (<xref target="RFC7230" format="default"/> section 6.3), sectionFormat="comma" section="6.3"/>),
          BRSKI-EST connections SHOULD <bcp14>SHOULD</bcp14> 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 MITM Man-in-the-Middle (MITM) attack
          during a critical phase.
      </t>
      <t>
          If non-persistent connections are used, then both the pledge and
          the registrar MUST <bcp14>MUST</bcp14> remember the certificates seen, that have been seen and also sent
          for the first connection.  They MUST <bcp14>MUST</bcp14> check each subsequent
          connections
          connection for the same certificates, and each end MUST <bcp14>MUST</bcp14> use
          the same certificates as well.  This places a difficult restriction
          on rolling certificates on the Registrar. registrar.
      </t>
      <t>Summarized automation extensions for the BRSKI-EST flow are:</t>
      <ul spacing="normal">
        <li>
              The pledge either attempts concurrent connections via each
              discovered proxy, proxy or it times out quickly and tries connections
              in series, as explained at the end of <xref target="brskiesttls" format="default"/>.
            </li>
        <li>
              The pledge provisionally accepts the registrar certificate during
              the TLS handshake as detailed in <xref target="brskiesttls" format="default"/>.
            </li>
        <li>
              The pledge requests a voucher using
              the new REST calls described below.  This voucher is then validated.
            </li>
        <li>
              The pledge completes authentication of the server certificate as
              detailed in <xref target="CompletingAuthenticationBootstrapping" format="default"/>. This
              moves the BRSKI-EST TLS connection out of the provisional
              state.
            </li>
        <li>
              Mandatory bootstrap steps conclude with voucher status
              telemetry (see <xref target="pledgestatus" format="default"/>).
            </li>
      </ul>
      <t>
          The BRSKI-EST TLS connection can now be used for EST enrollment.
      </t>
      <t>The extensions for a registrar (equivalent to an EST server) are:</t>
      <ul spacing="normal">
        <li>
            Client authentication is automated using Initial Device Identity
            (IDevID) IDevID as per the EST certificate based certificate-based client authentication.
            The subject field's DN encoding MUST <bcp14>MUST</bcp14> include the "serialNumber"
            attribute   with the device's unique serial number
            as explained in <xref target="PledgeIdentification" format="default"/> format="default"/>.
        </li>
        <li>The registrar requests and validates the voucher from the MASA.</li>
        <li>The registrar forwards the voucher to the pledge when
          requested.</li>
        <li>
            The registrar performs log verifications (described in
            <xref target="auditLogVerification" format="default"/>) in addition to local
            authorization checks before accepting optional pledge device
            enrollment requests.
          </li>
      </ul>
      <section anchor="brskiesttls" numbered="true" toc="default">
        <name>BRSKI-EST TLS establishment details</name> Establishment Details</name>
        <t>The pledge establishes the TLS connection with the registrar through
                the circuit proxy Circuit Proxy (see <xref target="proxydetails" format="default"/>) format="default"/>),
                but the TLS handshake is with the registrar. The BRSKI-EST pledge
                is the TLS client 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.
        </t>
        <t>
              Use of TLS 1.3 (or newer) is encouraged.
              TLS 1.2 or newer is REQUIRED <bcp14>REQUIRED</bcp14> on the Pledge pledge side.
              TLS 1.3 (or newer) SHOULD <bcp14>SHOULD</bcp14> be available on the Registrar registrar server interface,
              and the Registrar registrar client interface, but TLS 1.2 MAY <bcp14>MAY</bcp14> be used.
              TLS 1.3 (or newer) SHOULD <bcp14>SHOULD</bcp14> be available on the MASA server interface, but TLS
              1.2 MAY <bcp14>MAY</bcp14> be used.
        </t>
        <t>
              Establishment of the BRSKI-EST TLS connection is as
              specified in EST <xref target="RFC7030" format="default"/> section 4.1.1 "Bootstrap Distribution of CA Certificates" (Section <xref target="RFC7030" format="default"/> target='RFC7030' section='4.1.1' sectionFormat='bare'/>) of <xref target='RFC7030' format="default"/>, 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 out of scope of
              this specification.  Note that the trust anchors
              in/excluded
              in / excluded from the database will affect which manufacturers'
              devices are acceptable to the registrar as pledges, pledges and can
              also be used to limit the set of MASAs that are trusted for
              enrollment.
        </t>
        <t>
              The signature in the certificate MUST <bcp14>MUST</bcp14> be validated even if a
              signing key can not cannot (yet) be validated.  The certificate (or
              chain) MUST <bcp14>MUST</bcp14> be retained for later validation.
        </t>
        <t>
              A self-signed
              certificate for the Registrar registrar is acceptable as the voucher
              can validate it upon successful enrollment.
        </t>
        <t>The pledge performs input validation of all data received
               until a voucher is verified as specified in <xref target="CompletingAuthenticationBootstrapping" format="default"/> and
               the TLS connection leaves the provisional state. Until these
               operations are complete complete, the pledge could be communicating
               with an attacker.
        </t>
        <t>
              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 <bcp14>MUST</bcp14> be considered untrusted.  This
              particularly applies to HTTP headers and CMS structures that
              make up the voucher.
        </t>
        <t>
              A pledge that can connect to multiple Registrars registrars concurrently
              SHOULD
              <bcp14>SHOULD</bcp14> 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 <xref target="slowloris" format="default"/>).
        </t>
        <t>
              A pledge that can not 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 seconds, then the
              pledge SHOULD <bcp14>SHOULD</bcp14> 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 <bcp14>MAY</bcp14> continue to wait,
              as long as it is concurrently listening for new proxy
              announcements.
        </t>
      </section>
      <section anchor="RequestVoucherFromRegistrar" numbered="true" toc="default">
        <name>Pledge Requests Voucher from the Registrar</name>
        <t>When the pledge bootstraps bootstraps, it makes a request for a voucher from a
        registrar.</t>

        <t>This is done with an HTTPS POST using the operation path value of
        "/.well-known/est/requestvoucher".</t>
        "/.well-known/brski/requestvoucher".</t>

        <t>The pledge voucher-request Content-Type is:</t> is as follows.</t>
        <dl newline="false" spacing="normal">
          <dt>application/voucher-cms+json</dt>
          <dd>
            <xref
          <dt>application/voucher-cms+json:</dt>
          <dd><xref target="RFC8366" format="default"/> defines a "YANG-defined JSON document that has been signed using a CMS Cryptographic Message Syntax (CMS)
           structure", and the voucher-request described in
           <xref target="voucher-request" format="default"/> is created in the same way.
           The media type is the same as defined in <xref target="RFC8366" format="default"/>.
           This is also used for the pledge voucher-request.
           The pledge MUST <bcp14>MUST</bcp14> sign the request using the
           credentials in <xref target="IDevIDextension" format="default"/> credential. format="default"/>.
          </dd>
        </dl>
        <t>Registrar
        implementations SHOULD <bcp14>SHOULD</bcp14> anticipate future media types but but, of course course, will simply fail the request if those
        types are not yet known.</t>
        <t>
          The pledge SHOULD <bcp14>SHOULD</bcp14> include an <xref target="RFC7231" format="default"/> section 5.3.2
          "Accept" header field (see <xref target="RFC7231" sectionFormat="comma" section="5.3.2"/>) indicating the acceptable media type for the voucher
          response. The  "application/voucher-cms+json" media type is defined
          in <xref target="RFC8366" format="default"/> format="default"/>, but constrained voucher formats are
          expected in the future. Registrars and MASA are expected to be
          flexible in what they accept.
        </t>
        <t>The pledge populates the voucher-request fields as follows:</t>
        <dl newline="false" spacing="normal">
          <dt>created-on:</dt>
          <dd>Pledges that have a realtime real-time clock are
            RECOMMENDED
            <bcp14>RECOMMENDED</bcp14> 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 <bcp14>MAY</bcp14> omit this field.
            </dd>
          <dt>nonce:</dt>
          <dd>The pledge voucher-request MUST <bcp14>MUST</bcp14> contain a
            cryptographically strong random or pseudo-random number
            nonce (see <xref target="RFC4086" format="default"/> section 6.2). sectionFormat="comma" section="6.2"/>).
            As the nonce is usually generated very early in the boot sequence sequence,
            there is a concern that the same nonce might be generated across
            multiple boots, or after a factory reset.
            Different nonces MUST <bcp14>MUST</bcp14> 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 <xref target="timeunknown" format="default"/>.
            </dd>
          <dt>assertion:</dt>
          <dd>
              The pledge indicates support for the mechanism
              described in this document, by putting the value "proximity" in the
              voucher-request, MUST and <bcp14>MUST</bcp14> include the
              "proximity-registrar-cert"
              proximity-registrar-cert field (below).
            </dd>
            <dt>proximity-registrar-cert:</dt>

          <dd>In a pledge
            voucher-request
            voucher-request, this is the first certificate in the TLS server
            'certificate_list'
            "certificate_list" sequence (see [RFC5246]) <xref target="RFC8446" sectionFormat="comma" section="4.4.2"/>) presented by the
            registrar to the pledge. That is, it is the end-entity
            certificate. This MUST <bcp14>MUST</bcp14> be populated in a pledge voucher-request.
            </dd>
          <dt>serial-number</dt>
          <dt>serial-number:</dt>
          <dd>The serial number of the pledge
            is included in the voucher-request from the Pledge. pledge. This value is
            included as a sanity check only, but it is not to be forwarded
            by the Registrar registrar as described in <xref target="RequestVoucherFromMASA" format="default"/>.
            </dd>
        </dl>
        <t>All other fields MAY <bcp14>MAY</bcp14> be omitted in the pledge voucher-request.</t>
        <t>An
        <t>See an example JSON payload of a pledge voucher-request is in
            <xref target="voucher-request-examples" format="default"/> format="default"/>, Example 1.</t>
        <t>
          The registrar confirms that the
          assertion is 'proximity' "proximity" and that pinned
          'proximity-registrar-cert'
          proximity-registrar-cert is the Registrar's registrar's certificate.
          If this validation fails, then there is an On-Path Attacker on-path attacker (MITM),
          and the connection MUST <bcp14>MUST</bcp14> be closed after the returning of an
          HTTP 401 error code.
        </t>
      </section>
      <section anchor="pledgeauthorization" numbered="true" toc="default">
        <name>Registrar Authorization of Pledge</name>
        <t>
          In a fully automated network network, all devices must be securely identified
          and authorized to join the domain.
        </t>
        <t>
          A Registrar 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:</t> include the allowance of:</t>
        <ul spacing="normal">
          <li>allow any
          <li>any device of a specific type (as determined by the X.509
          IDevID),</li>
          <li>allow any
          <li>any device from a specific vendor (as determined by the
          X.509 IDevID),</li>
          <li>allow a
          <li>a specific device from a vendor (as determined by the X.509
          IDevID) against a domain white list. acceptlist.  (The mechanism for checking
          a shared white list acceptlist potentially used by multiple Registrars registrars is out
          of scope).</li> scope.)</li>
        </ul>
        <t>
          If validation fails fails, the registrar SHOULD <bcp14>SHOULD</bcp14> 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 a whitelist) MAY an acceptlist) <bcp14>MAY</bcp14> be responded to with an a
          403 HTTP error code.
        </t>
        <t>If authorization is successful successful, the registrar obtains a voucher from the MASA service (see
            <xref target="RequestVoucherFromMASA" format="default"/>) and returns that MASA signed MASA-signed voucher to the pledge
        as described in <xref target="VoucherResponse" format="default"/>.</t>
      </section>
      <section anchor="brskimasatls" numbered="true" toc="default">
        <name>BRSKI-MASA TLS establishment details</name> Establishment Details</name>
        <t>
          The BRSKI-MASA TLS connection is a 'normal' "normal" TLS connection
          appropriate for HTTPS REST interfaces. The registrar initiates the
          connection and uses the MASA URL that is obtained as described in
          <xref target="obtainmasaurl" format="default"/>. The mechanisms in
          <xref target="RFC6125" format="default"/> SHOULD <bcp14>SHOULD</bcp14> be used in authentication of the
          MASA using a DNS-ID that matches that which is found in the IDevID.
          Registrars MAY <bcp14>MAY</bcp14> include a mechanism to override the MASA URL on a
          manufacturer-by-manufacturer basis, and within that override 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.
        </t>
        <t>
          Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
          REQUIRED.
          <bcp14>REQUIRED</bcp14>.  TLS 1.3 (or newer) SHOULD <bcp14>SHOULD</bcp14> be available.
        </t>
        <t>
          As described in <xref target="RFC7030" format="default"/>, the MASA and the
          registrars SHOULD <bcp14>SHOULD</bcp14> be prepared to support TLS client
          certificate Client
          Certificate authentication and/or HTTP Basic, Digest, or SCRAM Salted Challenge Response Authentication Mechanism (SCRAM) authentication.
          This connection MAY <bcp14>MAY</bcp14> also have no client authentication at all.
        </t>
        <t>
          Registrars SHOULD <bcp14>SHOULD</bcp14> permit
          trust anchors to be pre-configured preconfigured on a per-vendor(MASA) per-vendor (MASA) basis.
          Registrars SHOULD <bcp14>SHOULD</bcp14> include the ability to configure a TLS
          ClientCertificate
          Client Certificate on a per-MASA basis, or to use no client
          certificate. Client
          Certificate.  Registrars SHOULD <bcp14>SHOULD</bcp14> also permit HTTP Basic and
          Digest authentication to be configured.
        </t>
        <t>
          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 <xref target="authzLogRequest" format="default"/>.
        </t>
        <t>
          Implementors
          Implementers are advised that
          contacting the MASA is to establish establishes a secured API connection with a
          web service service, and that there are a number of authentication models
          being explored within the industry. Registrars are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to
          fail gracefully and generate useful administrative notifications or
          logs in the advent of unexpected HTTP 401 (Unauthorized) responses
          from the MASA.
        </t>
        <section anchor="masaauthentication" numbered="true" toc="default">
          <name>MASA authentication Authentication of                                                     customer Customer Registrar</name>
          <t>
            Providing per-customer options requires that the customer's
            registrar to be uniquely identified.  This can be done by any stateless
            method that HTTPS supports such as with HTTP Basic
            or Digest authentication (that is using a password), but the use
            of TLS Client Certificate authentication is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
          </t>
          <t>
            Stateful methods involving API tokens, or HTTP Cookies, are not
            recommended.
          </t>
          <t>
            It is expected that the setup and configuration of per-customer
            Client Certificates is done as part of a sales ordering process.
          </t>
          <t>
            The use of public PKI (i.e. (i.e., WebPKI) End-Entity Certificates end-entity certificates to
            identify the Registrar registrar is reasonable, and if done universally universally,
            this would permit a MASA to identify a customers' Registrar customer's registrar simply by a
            FQDN.
            Fully Qualified Domain Name (FQDN).
          </t>
          <t>
            The use of DANE records in DNSSEC signed DNSSEC-signed zones would also permit use of
            a FQDN to identify customer Registrars. registrars.
          </t>
          <t>
            A third (and simplest, but least flexible) mechanism would be for
            the MASA to simply store the Registrar's registrar's certificate pinned in a
            database.
          </t>
          <t>
            A MASA without any supply chain supply-chain integration can simply accept
            Registrars
            registrars without any authentication, authentication or can accept them on a
            blind Trust-on-First-Use TOFU basis as described in <xref target="masasecurityreduction_tofu" format="default"/>.
          </t>
          <t>
            This document does not make a specific recommendation on how the
            MASA authenticates the Registrar 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 supply-chain logistics for $100
            CPE devices and $100,000 core routers.
          </t>
        </section>
      </section>
      <section anchor="RequestVoucherFromMASA" numbered="true" toc="default">
        <name>Registrar Requests Voucher from MASA</name>
        <t>
          When a registrar receives a pledge voucher-request voucher-request, it in turn
          submits a registrar voucher-request to the MASA service via an
          HTTPS interface (<xref <xref target="RFC7231" format="default"/>). format="default"/>.
        </t>
        <t>This is done with an HTTP POST using the operation path value of
        "/.well-known/est/requestvoucher".</t>
        "/.well-known/brski/requestvoucher".</t>

        <t>The voucher media type "application/voucher-cms+json" is defined in
          <xref target="RFC8366" format="default"/> 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 <bcp14>MUST</bcp14> sign the registrar voucher-request.
        </t>
        <t>
          MASA implementations SHOULD <bcp14>SHOULD</bcp14> anticipate future media
          ntypes but but, of course course, will simply fail the request if those types are
          not yet known.
        </t>
        <t>
          The voucher-request CMS object includes some number of certificates
          that are input to the MASA as it populates the
          'pinned-domain-cert'.
          pinned-domain-cert. As the
          <xref target="RFC8366" format="default"/> is quite flexible in what may be put into
          the 'pinned-domain-cert', 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 (EE) Certificate end-entity certificate that the Registrar uses, registrar uses
          to the entire private Enterprise CA certificate.
          More specific
          More-specific certificates result in a tighter binding of the
          voucher to the domain, while less specific less-specific certificates result in
          more flexibility in how the domain is represented by certificates.
        </t>
        <t>
          A Registrar which registrar that is seeking a nonceless voucher for later offline use
          benefits from a less specific less-specific certificate, as it permits the actual
          keypair
          key pair used by a future Registrar registrar to be determined by the pinned
          certificate authority.
          CA.
        </t>
        <t>
          In some cases, a less specific less-specific certificate, such as a public WebPKI
          certificate authority,
          CA, could be too open, 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.
        </t>
        <t>
          The Registrar SHOULD registrar <bcp14>SHOULD</bcp14> request a voucher with the most specificity
          consistent with the mode that it is operating in.
          In order to do this, when the Registrar registrar prepares the CMS structure
          for the signed voucher-request, it SHOULD <bcp14>SHOULD</bcp14> include only certificates
          which
          that are a part of the chain that it wishes the MASA to pin.
          This MAY <bcp14>MAY</bcp14> be as small as only the End-Entity end-entity certificate (with id-kp-cmcRA set) that
          it uses as it's its TLS Server Certificate, server certificate, or it MAY <bcp14>MAY</bcp14> be the entire
          chain, including the Domain domain CA.
        </t>
        <t>
          The Registrar SHOULD registrar <bcp14>SHOULD</bcp14> include an <xref target="RFC7231" format="default"/> section
          5.3.2 "Accept" header field (see <xref target="RFC7231" sectionFormat="comma" section="5.3.2"/>) indicating the response
media types that are
          acceptable. This list SHOULD <bcp14>SHOULD</bcp14> be the entire list presented to the
          Registrar
          registrar in the Pledge's pledge's original request (see <xref target="RequestVoucherFromRegistrar" format="default"/>) format="default"/>), but MAY it <bcp14>MAY</bcp14> be a subset.
          The MASA is expected to be flexible in what it accepts.
        </t>
        <t>The registrar populates the voucher-request fields as follows:</t>
        <dl newline="false" spacing="normal">
          <dt>created-on:</dt>
          <dd>
          The Registrars SHOULD registrar <bcp14>SHOULD</bcp14> populate this field with the current date and
          time when the Registrar formed this voucher request. voucher-request is formed. This field
          provides additional information to the MASA.
        </dd>
          <dt>nonce:</dt>
          <dd>This value, if present, is copied from the pledge
            voucher-request. The registrar voucher-request MAY <bcp14>MAY</bcp14> omit
            the nonce as per <xref target="noncelessVoucherRequest" format="default"/>.
        </dd>
          <dt>serial-number:</dt>
          <dd>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 certificate; see <xref target="IDevIDextension" format="default"/>.
        The registrar MUST <bcp14>MUST</bcp14> verify that the serial number serial-number field it parsed matches the serial number 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 <bcp14>MUST NOT</bcp14> simply copy the serial number serial-number field from a pledge voucher request voucher-request as that field is claimed but
        not certified.</dd>
          <dt>idevid-issuer:</dt>
          <dd>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, then an
        appropriate value needs to be configured from the same out-of-band source as the serial-number.
        </dd>
          <dt>prior-signed-voucher-request:</dt>
          <dd>The signed pledge
        voucher-request SHOULD <bcp14>SHOULD</bcp14> be included in the registrar voucher-request.
        The entire CMS signed CMS-signed structure is to be included, included and base64 encoded for
        transport in the JSON structure.
        </dd>
        </dl>
        <t>
          A nonceless registrar voucher-request MAY <bcp14>MAY</bcp14> 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 serialNumber field and appropriate 'Accept "Accept" header field' field values from the physical device
          labeling or from the sales channel (out-of-scope (which is out of scope for this
          document).
        </t>
        <t>All other fields MAY <bcp14>MAY</bcp14> be omitted in the registrar
        voucher-request.</t>
        <t>
          The "proximity-registrar-cert" proximity-registrar-cert field MUST NOT <bcp14>MUST NOT</bcp14> be present in the
          registrar voucher-request.
        </t>
        <t>Example
        <t>See example JSON payloads of registrar voucher-requests are in
            <xref target="voucher-request-examples" format="default"/> format="default"/>, Examples 2 through 4.</t>

	<t>The MASA verifies that the registrar voucher-request is internally consistent
        but does not necessarily authenticate the registrar certificate since the
        registrar MAY <bcp14>MAY</bcp14> be unknown to the MASA in advance. The MASA
        performs the actions and validation checks described in the following
        sub-sections
        subsections before issuing a voucher.</t>
        <section numbered="true" toc="default">
          <name>MASA renewal Renewal of expired vouchers</name> Expired Vouchers</name>
          <t>
            As described in
            <xref target="RFC8366" format="default"/> format="default"/>, 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 registrar with the same Domain CA) domain CA),
            then the request for
            a renewed voucher SHOULD <bcp14>SHOULD</bcp14> 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 <xref target="VoucherResponse" format="default"/>.
          </t>
          <t>To inform the MASA that existing vouchers are not to be renewed renewed, one
            can update or revoke the registrar credentials used to authorize the request (see Sections
            <xref target="MASAauthenticationOfRegistrar" format="default"/> format="counter"/> and <xref target="revocationcheck" format="default"/>). format="counter"/>). More
            flexible methods will likely involve sales channel integration and
            authorizations (details are out-of-scope out of scope of this document).</t>
        </section>
        <section anchor="MASApinned" numbered="true" toc="default">
          <name>MASA pinning Pinning of registrar</name> Registrar</name>
          <t>
            A certificate chain is extracted from the Registrar's registrar's signed CMS container.
            This chain may be as short as a single End-Entity Certificate, end-entity certificate, up
            to the entire registrar certificate chain, including the Domain domain
            CA certificate,
            as specified in <xref target="RequestVoucherFromMASA" format="default"/>.
          </t>
          <t>
            If the domain's CA is unknown to the MASA, then it is to be
            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, origin but
            to establish the consistency of the domain PKI.
          </t>
          <t>
            The MASA MAY <bcp14>MAY</bcp14> use the certificate farthest in the chain
            chain that it received is farthest
            from the Registrar from end-entity certificate of the
            end-entity, registrar, as determined by MASA policy.
            A MASA MAY <bcp14>MAY</bcp14> have a local policy that in which it only pins the End-Entity end-entity
            certificate. This is consistent with <xref target="RFC8366" format="default"/>.
            Details of the policy will typically depend upon the degree of
            Supply Chain Integration,
            supply-chain integration and the mechanism used by the Registrar registrar to
            authenticate.  Such a policy would also determine how
            the MASA will respond to a request for a nonceless voucher.
          </t>
        </section>
        <section anchor="revocationcheck" numbered="true" toc="default">
          <name>MASA checking Check of voucher request signature</name> the Voucher-Request Signature</name>
          <t>
            As described in <xref target="MASApinned" format="default"/>, the MASA has
            extracted Registrar's the registrar's domain CA.  This is used to validate the
            CMS signature (<xref <xref target="RFC5652" format="default"/>) format="default"/> on the voucher-request.
          </t>
          <t>
            Normal PKIX revocation
            checking is assumed during voucher-request signature validation.
            This CA certificate MAY <bcp14>MAY</bcp14> have
            Certificate Revocation List (CRL) distribution points, points or Online
            Certificate Status Protocol (OCSP) information (<xref <xref target="RFC6960" format="default"/>). format="default"/>.  If they are present, the MASA MUST <bcp14>MUST</bcp14>
            be able to reach the relevant servers belonging to the
            Registrar's
            registrar's domain CA to perform the revocation checks.
          </t>
          <t>
            The use of OCSP Stapling is preferred.
          </t>
        </section>
        <section anchor="MASAauthenticationOfRegistrar" numbered="true" toc="default">
          <name>MASA verification Verification of domain registrar</name> the Domain Registrar</name>
          <t>
            The MASA MUST <bcp14>MUST</bcp14> 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) <xref target="RFC7030" sectionFormat="comma" 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
            registration authorities of the domain.
          </t>
          <t>
            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 end-entity
            certificates (such as an LDevID certificate) from
            having vouchers issued against them.
          </t>
          <t>
            Other cases of inappropriate voucher issuance are detected
            by examination of the audit log. audit-log.
          </t>
          <t>
            If a nonceless voucher-request is submitted submitted, the MASA MUST <bcp14>MUST</bcp14>
            authenticate the registrar either as described in either
            EST (see Sections <xref target="RFC7030" format="default"/> section 3.2.3, section 3.3.2, sectionFormat="bare" section="3.2.3"/> and
<xref target="RFC7030" sectionFormat="bare" section="3.3.2"/> of
<xref target="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 out of scope of this document).
          </t>
          <t>
            In the nonced case, validation of the Registrar's registrar's identity (via
            TLS Client Certificate or HTTP authentication) MAY <bcp14>MAY</bcp14> be omitted
            if the MASA knows that the device policy is to accept audit-only vouchers.
          </t>
        </section>
        <section anchor="MASAassertion" numbered="true" toc="default">
          <name>MASA verification Verification of pledge prior-signed-voucher-request</name> the Pledge 'prior-signed-voucher-request'</name>
          <t>
            The MASA MAY <bcp14>MAY</bcp14> verify that the registrar voucher-request
            includes the 'prior-signed-voucher-request' prior-signed-voucher-request field. If so so, the
            prior-signed-voucher-request MUST <bcp14>MUST</bcp14> include a
            'proximity-registrar-cert'
            proximity-registrar-cert that is consistent with the
            certificate used to sign the registrar voucher-request.
            Additionally
            Additionally, the
            voucher-request serial-number leaf MUST <bcp14>MUST</bcp14> match the pledge
            serial-number that the MASA extracts from the signing certificate
            of the prior-signed-voucher-request.
            The consistency check described above is entails checking that the
            'proximity-registrar-cert' SPKI fingerprint
            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
            in
            <xref target="RFC7469" format="default"/> section 2.6, paragraph three. sectionFormat="comma" section="2.6"/>.
          </t>
          <t>
            If these checks succeed succeed, the MASA updates
            the voucher and audit-log assertion leafs with the "proximity"
            assertion, as defined by <xref target="RFC8366" format="default"/> section 5.3.
sectionFormat="comma" section="5.3"/>.
          </t>
        </section>
        <section anchor="MASAnoncehandling" numbered="true" toc="default">
          <name>MASA nonce handling</name> Nonce Handling</name>
          <t>
            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 <bcp14>MUST</bcp14>
            verify that the nonce is consistent.
            (Recall from above that the
            voucher-request might not contain a nonce, nonce; see
            Sections <xref target="RequestVoucherFromMASA" format="default"/> format="counter"/> and
            <xref target="MASAauthenticationOfRegistrar" format="default"/>). format="counter"/>.)
          </t>
          <t>
            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".
          </t>
        </section>
      </section>
      <section anchor="VoucherResponse" numbered="true" toc="default">
        <name>MASA and Registrar Voucher Response</name>
        <t>The MASA voucher response to the registrar is forwarded
          without changes to the pledge; therefore therefore, this section applies
          to both the MASA and the registrar. The HTTP signaling described
          applies to both the MASA and registrar responses.
        </t>
        <t>
          When a voucher request 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 otherwise, the registrar constructs a new registrar
          voucher-request and sends it to the MASA.
        </t>
        <t>
          Registrar evaluation of the voucher itself is purely for
          transparency and audit purposes to further inform log verification
          (see <xref target="auditLogVerification" format="default"/>) and therefore format="default"/>); therefore, a
          registrar could accept future voucher formats that are opaque to
          the registrar.
        </t>
        <t>
          If the voucher-request is successful, the server (MASA (a MASA responding
          to a registrar or a registrar responding to a pledge) response MUST <bcp14>MUST</bcp14>
          contain an HTTP 200 response code. The server MUST <bcp14>MUST</bcp14> answer with a
          suitable 4xx or 5xx HTTP <xref target="RFC7230" format="default"/> error code when a problem occurs.
          In this case, the response data from the MASA MUST <bcp14>MUST</bcp14> be a plaintext plain text
          human-readable (UTF-8) error message containing explanatory
          information describing why the request was rejected.
        </t>
        <t>
          The registrar MAY <bcp14>MAY</bcp14> respond with an HTTP 202 ("the request has been
          accepted for processing, but the processing has not been completed") as
          described in EST <xref target="RFC7030" format="default"/> section 4.2.3 sectionFormat="comma" section="4.2.3"/>, wherein the
          client "MUST "<bcp14>MUST</bcp14> wait at least the specified 'Retry-After' "retry-after" time before
          repeating the same request".
          (see request"
          (also see <xref target="RFC7231" format="default"/> section 6.6.4) sectionFormat="comma" section="6.6.4"/>).
          The pledge is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to provide local
          feedback (blinked LED etc) LED, etc.) during this wait cycle if mechanisms for this
          are available. To prevent an attacker registrar from significantly
          delaying bootstrapping bootstrapping, the pledge MUST <bcp14>MUST</bcp14> limit the 'Retry-After' Retry-After time to
          60 seconds. Ideally Ideally, the pledge would keep track of the
          appropriate Retry-After header field values for any number of
          outstanding registrars registrars, but this would involve a state table
          on the pledge.  Instead  Instead, the
          pledge MAY <bcp14>MAY</bcp14> ignore the exact Retry-After value in favor of a single hard
          coded 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 only <bcp14>SHOULD</bcp14> 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 fails, and the pledge returns to discovery 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.

        </t>
        <t>
          A pledge that retries a request after receiving a 202 message MUST <bcp14>MUST</bcp14>
          resend the same voucher-request.  It MUST NOT <bcp14>MUST NOT</bcp14> sign a new
          voucher-request each time, and in particular, it MUST NOT <bcp14>MUST NOT</bcp14> change
          the nonce value.
        </t>
        <t>
          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 <bcp14>MUST NOT</bcp14>
          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.
        </t>
        <t>A 403 (Forbidden) response is appropriate if the voucher-request
        is not signed correctly, stale, correctly or is stale or if the pledge has another
        outstanding voucher that cannot be overridden.</t>

        <t>A 404 (Not Found) response is appropriate when the request is for a
        device that is not known to the MASA.</t>

        <t>A 406 (Not Acceptable) response is appropriate if a voucher of the
        desired type or using that uses the desired algorithms (as indicated by the
        Accept:
        "Accept" header fields, fields and algorithms used in the signature) cannot be
        issued such as such because the MASA knows the pledge cannot process
        that type. The registrar SHOULD <bcp14>SHOULD</bcp14> use this response if it determines
        the pledge is unacceptable due to inventory control, MASA audit-logs, or
        any other reason.</t>
        <t>
          A 415 (Unsupported Media Type) response is appropriate
          for a request that has a voucher-request or Accept: "Accept" value that is
          not understood.
        </t>
        <t>The voucher response format is as indicated in the submitted
        Accept
        "Accept" header fields or based on the MASA's prior understanding of proper
        format for this Pledge. pledge. Only the <xref target="RFC8366" format="default"/>
        "application/voucher-cms+json" media type <xref target="RFC8366" format="default"/> is defined at this
        time. The syntactic details of vouchers are described in detail in
        <xref target="RFC8366" format="default"/>. <xref target="voucherjsonexample" format="default"/> shows
        a sample of the contents of a voucher.
        </t>
        <figure anchor="voucherjsonexample">
          <name>An example voucher</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[ Example Voucher</name>
<sourcecode type="json">
{
  "ietf-voucher:voucher": {
    "nonce": "62a2e7693d82fcda2624de58fb6722e5",
    "assertion": "logged",
    "pinned-domain-cert": "base64encodedvalue==",
    "serial-number": "JADA123456789"
  }
}
]]></artwork>
</sourcecode>
        </figure>
        <t>The MASA populates the voucher fields as follows:</t>
        <dl newline="false" spacing="normal">
          <dt>nonce:</dt>
          <dd>The nonce from the pledge if available. See <xref target="MASAnoncehandling" format="default"/>.</dd>
          <dt>assertion:</dt>
          <dd>The method used to verify the relationship
        between the pledge and registrar. See <xref target="MASAassertion" format="default"/>.</dd>
          <dt>pinned-domain-cert:</dt>
          <dd>A certificate. See certificate; see <xref target="MASApinned" format="default"/>. This figure is illustrative, illustrative; for an example,
        see <xref target="exampleprocess" format="default"/> where an End Entity end-entity certificate
        is used. </dd>
          <dt>serial-number:</dt>
          <dd>The serial-number as provided in the
          voucher-request. Also see <xref target="MASAassertion" format="default"/>.</dd>
          <dt>domain-cert-revocation-checks:</dt>
          <dd>Set as appropriate for the
          pledge's capabilities and as documented in <xref target="RFC8366" format="default"/>.

          The MASA MAY <bcp14>MAY</bcp14> set this field to 'false' "false" since setting it to 'true' "true" would
          require that revocation information be available to the pledge pledge, and this
          document does not make normative requirements for
          <xref target="RFC6961" format="default"/> format="default"/>, <xref target="RFC8446" sectionFormat="of" section="4.4.2.1"/>, or equivalent integrations.</dd>
          <dt>expires-on:</dt>
          <dd>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 <xref target="timeunknown" format="default"/>. 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 certificate revocation
          information (CRL) CRL lifetime. The expires-on field SHOULD <bcp14>SHOULD</bcp14> be before
          the earliest of these three values.
          Typically
          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 <bcp14>RECOMMENDED</bcp14> period for (a) is on the order of
          20 minutes, so it will typically determine the lifespan 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 lifespan life span of the
          ownership relationship.
        </dd>
        </dl>
        <t>
          Whenever a voucher is issued issued, the MASA MUST <bcp14>MUST</bcp14> update the
          audit-log sufficiently to generate the response as described in
          <xref target="MASAauditlog" format="default"/>.
          The internal state requirements to maintain the audit-log
          are out-of-scope. out of scope.
        </t>
        <section anchor="CompletingAuthenticationBootstrapping" numbered="true" toc="default">
          <name>Pledge voucher verification</name> Voucher Verification</name>
          <t>
          The pledge MUST <bcp14>MUST</bcp14> 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 out of scope of this document; this protocol
          does not update these this trust anchor(s).
          </t>
          <t>
          The pledge MUST <bcp14>MUST</bcp14> verify that the serial-number field of the signed voucher
          matches the pledge's own serial-number.
          </t>
          <t>
          The pledge MUST <bcp14>MUST</bcp14>
          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, policy; see <xref target="pledgeReductions" format="default"/>) format="default"/>).
          </t>
          <t>
          The pledge MUST <bcp14>MUST</bcp14> be prepared to parse and fail gracefully from
          a voucher response that does not contain a 'pinned-domain-cert' pinned-domain-cert
          field.
          Such a thing indicates a failure to enroll in this domain,
          and the pledge MUST <bcp14>MUST</bcp14> attempt joining with other available Join Proxy. Proxies.
          </t>
          <t>
          The pledge MUST <bcp14>MUST</bcp14> be prepared to ignore additional fields that it does not recognize.
          </t>
        </section>
        <section anchor="PledgeAuthenticationOfProvisionalTLS" numbered="true" toc="default">
          <name>Pledge authentication Authentication of provisional Provisional TLS connection</name> Connection</name>
          <t>
            Following the process described in <xref target="RFC8366" format="default"/>,
            the pledge should consider the public key from the
            pinned-domain-cert as the sole temporary trust anchor.
          </t>
          <t>
            The pledge then evaluates the TLS Server Certificate 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 End-Entity
            Certificate provided public key in the end-entity
            certificate provided by the TLS Server. server.
          </t>
          <t>
            If a registrar's credentials cannot be verified using the
            pinned-domain-cert trust anchor from the voucher voucher, then the TLS
            connection is immediately
            discarded
            discarded, and the pledge abandons attempts to bootstrap with this
            discovered registrar. The pledge SHOULD <bcp14>SHOULD</bcp14> send voucher status
            telemetry (described below) before closing the TLS connection.
            The pledge MUST <bcp14>MUST</bcp14> attempt to enroll using any other proxies
            it has found.  It SHOULD <bcp14>SHOULD</bcp14> return to the same proxy again after
            unsuccessful attempts with other proxies.  Attempts should be
            made repeated at repeated intervals according to the backoff back-off timer
            described earlier.
            Attempts SHOULD <bcp14>SHOULD</bcp14> be repeated as failure may be the result of a
            temporary inconsistency (an inconsistently rolled registrar key,
            or some other mis-configuration). misconfiguration).  The inconsistency could also
            be the result of an active MITM attack on the EST connection.
          </t>
          <t> The registrar MUST <bcp14>MUST</bcp14> use a certificate that chains to the pinned-domain-cert
            as its TLS server certificate.
          </t>
          <t>The pledge's PKIX path validation of a registrar certificate's validity
            period information is as described in <xref target="timeunknown" format="default"/>.
            Once the PKIX path validation is successful successful, the TLS connection is
            no longer provisional.</t>
          <t>The pinned-domain-cert MAY <bcp14>MAY</bcp14> be installed as a
            trust anchor for future operations such as enrollment (e.g. (e.g., as recommended per <xref target="RFC7030" format="default"/> as recommended) format="default"/>) or trust anchor management or raw protocols that do not need full PKI based PKI-based key management. It can be used to authenticate any dynamically
            discovered EST server that contain contains the id-kp-cmcRA extended key
            usage extension as detailed in EST RFC7030 section 3.6.1; (see <xref target="RFC7030" sectionFormat="comma" section="3.6.1"/>); but to
            reduce system complexity complexity, the pledge SHOULD <bcp14>SHOULD</bcp14> avoid additional
            discovery operations. Instead Instead, the pledge SHOULD <bcp14>SHOULD</bcp14> communicate directly
            with the registrar as the EST server. The 'pinned-domain-cert' pinned-domain-cert
            is not a complete
            distribution of the CA certificate response, as described in <xref target="RFC7030" format="default"/> section 4.1.3 CA Certificate Response, sectionFormat="comma"
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 certificate response is
            obtained
            obtained, it is more authoritative for the domain than the limited
            'pinned-domain-cert'
            pinned-domain-cert response.</t>
        </section>
      </section>
      <section anchor="pledgestatus" numbered="true" toc="default">
        <name>Pledge BRSKI Status Telemetry</name>
        <t>The domain is expected to provide indications to the system
        administrators concerning device lifecycle life-cycle status. To facilitate this this,
        it needs telemetry information concerning the device's
        status.</t>
        <t>The pledge MUST <bcp14>MUST</bcp14> indicate its pledge status regarding the voucher.
        It does this by sending a status message to the Registrar.</t> registrar.</t>
        <t>The posted data media type: application/json</t>

<t>The client sends an HTTP POST to the server at the URI ".well-known/est/voucher_status".</t> ".well-known/brski/voucher_status".</t>

        <t>
          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 registrar that receives a status
          message with a version larger than it knows about SHOULD <bcp14>SHOULD</bcp14> log the
          contents and alert a human.
        </t>
        <t>The Status status field indicates if the voucher was acceptable.
        Boolean values are acceptable, where "true" indicates the voucher was
        acceptable.
        </t>
        <t>
          If the voucher was not acceptable acceptable, the Reason string indicates
          why. In the a failure case case, this message may be sent to an
          unauthenticated, potentially malicious registrar and therefore registrar; therefore, the
          Reason string SHOULD NOT <bcp14>SHOULD NOT</bcp14> provide information beneficial to an
          attacker. The operational benefit of this telemetry information is
          balanced against the operational costs of not recording that an a
          voucher was ignored by a client that the registrar expected was going to continue
          joining the domain.
        </t>
        <t>
          The reason-context attribute is an arbitrary JSON object (literal
          value or hash of values) which that provides additional information
          specific to this pledge.  The contents of this field are not
          subject to standardization.
        </t>
        <t>
          The version and status fields MUST <bcp14>MUST</bcp14> be present.
          The Reason field SHOULD <bcp14>SHOULD</bcp14> be present whenever the status field
          is false.  The Reason-Context field is optional.
	  In the case of a SUCCESS, the Reason string <bcp14>MAY</bcp14> be omitted.
        </t>
  <t>
          The keys to this JSON object are case-sensitive case sensitive and MUST <bcp14>MUST</bcp14> be lowercase.
          <xref target="telemetryexample" format="default"/> shows an example JSON.
        </t>
        <figure anchor="cddl-voucherstatus">
          <name>CDDL for Voucher Status POST</name>
          <sourcecode name="voucherstatus.cddl" type="CDDL" markers="true"><![CDATA[
voucherstatus-post = {
    "version": uint,
    "status": bool,
    ? "reason": text,
    ? "reason-context" : { $$arbitrary-map }
  }
}
]]></sourcecode>
        </figure>

 <figure anchor="telemetryexample">
          <name>Example Status Telemetry</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          <sourcecode type="json"><![CDATA[
{
    "version":"1",
    "version": 1,
    "status":false,
    "reason":"Informative human readable human-readable message",
    "reason-context": { "additional" : "JSON" }
}
]]></artwork>
]]></sourcecode>
 </figure>
        <t>
          The server SHOULD <bcp14>SHOULD</bcp14> respond with an HTTP 200 but MAY <bcp14>MAY</bcp14> simply
          fail with an HTTP 404 error. The client ignores any response. Within
          the server logs the The server SHOULD <bcp14>SHOULD</bcp14> capture this telemetry
          information. information within the server logs.
        </t>
        <t>
          Additional standard JSON fields in this POST MAY <bcp14>MAY</bcp14> be added, added; see
          <xref target="pledgestatustelemetryregistry" format="default"/>.  A server that
          sees unknown fields should log them, but otherwise ignore them.
        </t>
      </section>
      <section anchor="authzLogRequest" numbered="true" toc="default">
        <name>Registrar audit-log request</name> Audit-Log Request</name>
        <t>
           After receiving the pledge status telemetry (see <xref target="pledgestatus" format="default"/>, format="default"/>),
           the registrar SHOULD <bcp14>SHOULD</bcp14> request the MASA audit-log from the MASA
        service.</t>
        <t>
          This is done with an HTTP POST using the operation path value of
          "/.well-known/est/requestauditlog".
          "/.well-known/brski/requestauditlog".
        </t>
        <t>
          The registrar SHOULD <bcp14>SHOULD</bcp14> 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" idevid-issuer and "serial-number" serial-number informs the MASA
          which log is requested requested, so the appropriate log can be prepared
          for the response.
          Using the same media type and message minimizes
          cryptographic and message operations operations, although it results in additional
          network traffic.
          The relying MASA implementation MAY <bcp14>MAY</bcp14> 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.
        </t>
        <t>
          A registrar MAY <bcp14>MAY</bcp14> request logs at future times. If the registrar
          generates a new request request, then the MASA is forced to perform
          the additional cryptographic operations to verify the new request.
        </t>
        <t>
          A MASA that receives a request for a device that does not exist,
          or for which the requesting owner was never an owner owner, returns an
          HTTP 404 ("Not found") code.
        </t>
        <t>
          It is reasonable for a Registrar, registrar, that the MASA does not believe
          to be the current owner, to request the audit-log.  There are
          probably reasons for this 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 occurance. occurrence.  It is also possible that the device legitimately
          spends time in two different networks.
        </t>
        <t>
          Rather than returning the audit-log as a response to the POST (with
          a return code 200), the MASA MAY <bcp14>MAY</bcp14> instead return a 201 ("Created")
          response (<xref target="RFC7231" format="default"/> sections 6.3.2 sectionFormat="bare"/>, Sections
<xref target="RFC7231" sectionFormat="bare" section="6.3.2"/> and 7.1), <xref
target="RFC7231" sectionFormat="bare" section="7.1"/>), with
          the URL to the prepared (and idempotent, therefore cachable) audit
          response in the Location: "Location" header field.
        </t>
        <t>
          In order to avoid enumeration of device audit-logs,
          a MASA that return returns URLs SHOULD <bcp14>SHOULD</bcp14> take care to make the returned
          URL unguessable.
          <xref target="W3C.WD-capability-urls-20140218" target="W3C.capability-urls" format="default"/> provides very good additional guidance.
          For instance, rather than returning URLs containing a database number
          such as https://example.com/auditlog/1234 or the EUI Extended Unique Identifier (EUI) of the device
          such https://example.com/auditlog/10-00-00-11-22-33,
          the MASA SHOULD <bcp14>SHOULD</bcp14> return a randomly generated value (a "slug" in
          web parlance).  The value is used to find the relevant database
          entry.
        </t>
        <t>
          A MASA that returns a code 200 MAY <bcp14>MAY</bcp14> also include a Location: "Location" header
          for future reference by the registrar.
        </t>
        <section anchor="MASAauditlog" numbered="true" toc="default">
          <name>MASA audit log response</name> Audit-Log Response</name>
          <t>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 audit-log may be abridged by removal of old or repeated
          values as explained below.
          The returned data is in JSON format (<xref <xref target="RFC8259" format="default"/>), format="default"/>,
          and the Content-Type SHOULD <bcp14>SHOULD</bcp14> be "application/json".

          </t>
          <t>
            The following CDDL (<xref <xref target="RFC8610" format="default"/>) format="default"/> explains the
            structure of the JSON format audit-log response:
          </t>
          <figure anchor="cddl-auditlog">
            <name>CDDL for audit-log response</name> Audit-Log Response</name>
            <sourcecode name="auditlog.cddl" type="" type="CDDL" markers="true"><![CDATA[
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,
}
]]></sourcecode>
          </figure>
          <t>An example:
          </t>
          <figure anchor="example-auditlog">
            <name>Example of audit-log response</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[ an Audit-Log Response</name>
<sourcecode type="json">
{
  "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"
     }
}
]]></artwork>
</sourcecode>
          </figure>
          <t>
            The domainID is a binary SubjectKeyIdentifier value calculated
            according to <xref target="domainID" format="default"/>.
            It is encoded once in base64 in order to be transported in this
            JSON container.
          </t>
          <t>
            The date is in formatted per <xref target="RFC3339" format="default"/> format, format="default"/>, which is
            consistent with typical JavaScript usage of JSON.
          </t>
          <t>
            The truncation structure MAY <bcp14>MAY</bcp14> be omitted if all values are zero.
            Any counter missing from the truncation structure is the be
            assumed to be zero.
          </t>
          <t>
            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 <bcp14>SHOULD</bcp14> be used in preference to
            omitting the entry.
            While the nonce is often created as a base64 encoded base64-encoded random
            series of bytes, this should not be assumed.
          </t>
          <t>
            Distribution of a large log is less than ideal. This structure can
            be optimized as follows: Nonced nonced or Nonceless nonceless entries for the
            same domainID MAY <bcp14>MAY</bcp14> be abridged from the log leaving only the single
            most recent nonced or nonceless entry for that domainID. In the case of
            truncation
            truncation, the 'event' "event" truncation value SHOULD <bcp14>SHOULD</bcp14> contain a count of the number of events for this
            domainID that were omitted. The log SHOULD NOT <bcp14>SHOULD NOT</bcp14> be further
            reduced
            reduced, but there could exist an operational situation could exist where maintaining
            the full log is not possible. In such situations situations, the log MAY <bcp14>MAY</bcp14> be
            arbitrarily abridged for length, with the number of removed
            entries indicated as 'arbitrary'. "arbitrary".
          </t>
          <t>
            If the truncation count exceeds 1024 1024, then the MASA
            MAY
            <bcp14>MAY</bcp14> use this value without further incrementing it.
          </t>
          <t>
            A log where duplicate entries for the same domain have
            been omitted ("nonced duplicates" and/or "nonceless duplicates) duplicates")
            could still be acceptable for informed decisions. A log that
            has had "arbitrary" truncations is less acceptable acceptable, but manufacturer
            transparency is better than hidden truncations.
          </t>
          <t>
            A registrar that sees a version value greater than 1 indicates
            an audit log 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 end point endpoint will be used.
          </t>
          <t>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 <bcp14>SHOULD</bcp14> anticipate new kinds of responses, responses and
            SHOULD
            <bcp14>SHOULD</bcp14> provide operator controls to indicate how to process
            unknown responses.
          </t>
        </section>
        <section anchor="domainID" numbered="true" toc="default">
          <name>Calculation of domainID</name>
          <t>
            The domainID is a binary value (a BIT STRING) that uniquely
            identifies a Registrar registrar by the "pinned-domain-cert". pinned-domain-cert.
          </t>
          <t>
            If the "pinned-domain-cert" pinned-domain-cert certificate
            includes the SubjectKeyIdentifier (<xref target="RFC5280" format="default">Section
            4.2.1.2</xref>), sectionFormat="comma" section="4.2.1.2"/>), then it is to be used as the domainID.  If not,
            the SPKI Fingerprint as described in
            <xref target="RFC7469" format="default"/> section 2.4 sectionFormat="comma" section="2.4"/> is to be used.
            This value needs to be calculated by both the MASA (to
            populate the audit-log), audit-log) and by the Registrar registrar (to recognize itself in the audit log). audit-log).
          </t>
          <t>
            <xref target="RFC5280" format="default"/> section 4.2.1.2 sectionFormat="comma" section="4.2.1.2"/> does not mandate that the
            SubjectKeyIdentifier extension be present in non-CA certificates.
            It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that Registrar registrar certificates (even if
            self-signed),
            self-signed) always include the SubjectKeyIdentifier to be
            used as a domainID.
          </t>
          <t>
            The domainID is determined
            from the certificate chain associated with the
            pinned-domain-cert and is used to update the audit-log.
          </t>
        </section>
        <section anchor="auditLogVerification" numbered="true" toc="default">
          <name>Registrar audit log verification</name> Audit-Log Verification</name>
          <t>
            Each time the Manufacturer Authorized Signing Authority (MASA) MASA
            issues a voucher, it appends details of the assignment to
            an internal audit log audit-log for that device.
            The internal audit log audit-log is processed when responding to
            requests for details as described in <xref target="authzLogRequest" format="default"/>.
            The contents of the audit log audit-log can express a variety of trust
            levels, and this section explains what kind of trust a
            registrar can derive from the entries.
          </t>
          <t>
            While the audit log 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 contents content of the voucher-requests
            which
            that determines how meaningful the audit log audit-log entries are.
          </t>
          <t>A registrar SHOULD <bcp14>SHOULD</bcp14> 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 pre-owned preowned can be
          expected to have an extensive history.  The following discussion is provided to help
          explain the value of each log element:</t>
          <dl newline="false" spacing="normal">
            <dt>date:</dt>
            <dd>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 administrator, events before/after certain dates can
              have different levels of importance. For example example, for equipment
              that is expected to be new, and thus have has no history, it
            would be a surprise to find prior entries.</dd>
            <dt>domainID:</dt>
            <dd> If the log includes an unexpected domainID 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 white lists acceptlists of prior
              domains to anomaly detection (e.g. (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. (e.g., "this device was re-deployed some number of times
              internally
              internally, but the external audit log audit-log shows additional re-deployments
              our internal logs are unaware of").</dd>
            <dt>nonce:</dt>
            <dd>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.</dd>
            <dt>assertion:</dt>
            <dd>The assertion leaf in the voucher and
            audit log
            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, or not. 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.</dd>
          </dl>
          <t>
            A relatively simple policy is to white list acceptlist known (internal or
            external) domainIDs, domainIDs and require all vouchers to have a nonce.
            An alternative is to require that all nonceless vouchers be from a
            subset (e.g. (e.g., only internal) of domainIDs.
            If the policy is violated 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 registrar <bcp14>MUST</bcp14> then refuse
            any EST actions, actions and SHOULD <bcp14>SHOULD</bcp14> inform a human via a log.
            A registrar MAY <bcp14>MAY</bcp14> be configured to ignore (i.e. (i.e., override the above
            policy) the
            history of the device device, but it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that this only be
            configured if hardware assisted (i.e. TPM hardware-assisted (i.e., Transport Performance Metrics (TPM) anchored) Network
            Endpoint Assessment (NEA) <xref target="RFC5209" format="default"/> is supported.
          </t>
        </section>
      </section>
      <section anchor="ESTintegration" numbered="true" toc="default">
        <name>EST Integration for PKI bootstrapping</name> Bootstrapping</name>

        <t>The pledge SHOULD <bcp14>SHOULD</bcp14> follow the BRSKI operations with EST enrollment operations
        including "CA Certificates Request", "CSR Attributes" 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 <xref target="RFC7030" format="default"/>. As noted above, use of HTTP persistent HTTP-persistent
        connections simplifies the pledge state machine.</t>
        <!-- dealing with: https://github.com/anima-wg/anima-bootstrap/issues/24 -->
        <t>
          Although EST allows clients to obtain multiple certificates by sending
          multiple Certificate Signing Requests (CSR) requests, (CSRs), BRSKI does not support this mechanism directly.
          This is because BRSKI pledges MUST <bcp14>MUST</bcp14> use the CSR Attributes request
          (<xref target="RFC7030" format="default"/> section 4.5). sectionFormat="comma" section="4.5"/>).
          The registrar MUST <bcp14>MUST</bcp14> 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 <bcp14>MAY</bcp14>
          contain more complex logic logic, but doing so is out-of-scope out of scope of this
          specification.
          BRSKI does not signal any enhancement or restriction to this
          capability.
        </t>
        <section numbered="true" toc="default">
          <name>EST Distribution of CA Certificates</name>
          <t>The pledge SHOULD <bcp14>SHOULD</bcp14> request the full EST Distribution of CA
          Certificates message. See RFC7030, section 4.1.</t>
          certificate messages; see <xref target="RFC7030" sectionFormat="comma" section="4.1"/>.</t>

          <t>This ensures that the pledge has the complete set of current CA
          certificates beyond the pinned-domain-cert (see <xref target="PledgeAuthenticationOfProvisionalTLS" format="default"/> for a discussion of the
          limitations inherent in having a single certificate instead of a full
          CA Certificates response.) certificate response). Although these limitations are acceptable during initial bootstrapping, they are not appropriate for ongoing PKIX end entity end-entity certificate validation.</t>
        </section>
        <section anchor="csrattributes" numbered="true" toc="default">
          <name>EST CSR Attributes</name>
          <t>Automated bootstrapping occurs without local administrative
          configuration of the pledge. In some deployments 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 domain-specific
          identity information. Conceptually Conceptually, the CA has complete control over
          all fields issued in the end entity end-entity certificate. Realistically Realistically, this
          is operationally difficult with the current status of PKI
          certificate authority
          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 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.</t>

          <t>To alleviate these operational difficulties, the pledge MUST <bcp14>MUST</bcp14>
          request the
          EST "CSR Attributes" from the EST server 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 integrations, and instead 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.</t>

          <t>
            In networks using the BRSKI enrolled certificate to authenticate
            the ACP (Autonomic Control Plane), ACP, the EST CSR attributes MUST Attributes <bcp14>MUST</bcp14> include
            the ACP Domain Information Fields domain information fields defined in
            <xref target="I-D.ietf-anima-autonomic-control-plane" format="default"/> section 6.1.1. target="RFC8994" sectionFormat="comma" section="6.2.2"/>.
          </t>
          <t>The registrar MUST <bcp14>MUST</bcp14> 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 CMC, Certificate Management over CMS (CMC), which
          provides mechanisms to override the CSR attributes, Attributes, then these
          mechanisms MAY <bcp14>MAY</bcp14> be used even if the client ignores the guidance for the CSR Attribute
          guidance.</t> Attributes.</t>
        </section>
        <section numbered="true" toc="default">
          <name>EST Client Certificate Request</name>
          <t>The pledge MUST <bcp14>MUST</bcp14> request a new client certificate. See RFC7030,
          section 4.2.</t> Client
Certificate; see <xref target="RFC7030" sectionFormat="comma" section="4.2"/>.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Enrollment Status Telemetry</name>
          <t>
            For automated bootstrapping of devices, the administrative elements
            providing
            that provide bootstrapping also provide indications to the system
            administrators concerning device lifecycle 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.
            <xref target="RFC7030" format="default"/> assumes
            Since an end user and therefore does
            not include is assumed per <xref target="RFC7030" format="default"/>, a final success indication back to the server. server is not included. This is
            insufficient for automated use cases.
          </t>
          <t>
            The client MUST <bcp14>MUST</bcp14> send an indicator to the Registrar registrar about its
            enrollment status.  It does this by using an HTTP POST of
            a JSON dictionary with the of attributes described below to
            the new EST endpoint at "/.well-known/est/enrollstatus". "/.well-known/brski/enrollstatus".
          </t>
          <t>
            When indicating a successful enrollment enrollment, the client SHOULD <bcp14>SHOULD</bcp14> first
            re-establish the EST TLS session using the newly obtained
            credentials. TLS 1.2 1.3 supports doing this in-band, but
            TLS 1.3 1.2 does not.  The client SHOULD <bcp14>SHOULD</bcp14> therefore always close the existing
            TLS connection, connection and start a new one. one, using the same Join Proxy.
          </t>
          <t>
            In the case of a failed enrollment, the client MUST <bcp14>MUST</bcp14> 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.)
          </t>
          <t>
            The reason-context attribute version and status fields <bcp14>MUST</bcp14> be present.  The Reason field <bcp14>SHOULD</bcp14> be present
            whenever the status field is false.
            In the case of a SUCCESS, the Reason string <bcp14>MAY</bcp14> be omitted.
	  </t>
	    <t>
            The reason-context attribute is an arbitrary JSON object (literal
            value or hash of values) which 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.
          </t>
          <t>
            In the case of a SUCCESS the Reason string is omitted.
          </t>
          <figure anchor="cddl-enrollstatus">
            <name>CDDL for enrollment status Enrollment Status POST</name>
            <sourcecode name="enrollstatus.cddl" type="" type="CDDL" markers="true"><![CDATA[
enrollstatus-post = {
    "version": uint,
    "status": bool,
    ? "reason": text,
    ? "reason-context" : { $$arbitrary-map }
  }
}
]]></sourcecode>
          </figure>
          <t>
            An example status report can be seen below.  It is sent with
            with
            the media type: application/json
          </t>
          <figure anchor="example-enrollstatus">
            <name>Example of                                                           enrollment status Enrollment Status POST</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="json">
{
    "version":"1",
    "version": 1,
    "status":true,
    "reason":"Informative human readable message",
    "reason-context": { "additional" : "JSON" }
}
]]></artwork>
</sourcecode>
          </figure>
          <t>The server SHOULD <bcp14>SHOULD</bcp14> respond with an HTTP 200 but MAY <bcp14>MAY</bcp14> simply fail
          with an HTTP 404 error.</t>
          <t>
            Within the server logs logs, the server MUST <bcp14>MUST</bcp14> capture if this message
            was received over an a TLS session with a matching client
            certificate. Client
            Certificate.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Multiple certificates</name> Certificates</name>
          <t>
            Pledges that require multiple certificates could establish
            direct EST connections to the registrar.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>EST over CoAP</name>
          <t>This document describes extensions to EST for the purposes purpose
              of bootstrapping of 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 Instead, it is anticipated that a definition of
              CoAP mappings will occur in subsequent documents such as
              <xref target="I-D.ietf-ace-coap-est" format="default"/> and that
              CoAP mappings for BRSKI will be discussed either there or
              in future work.</t>
        </section>
      </section>
    </section>
    <section anchor="estbase64" numbered="true" toc="default">
      <name>Clarification of transfer-encoding</name> Transfer-Encoding</name>
      <t>
        <xref target="RFC7030" format="default"/> defines its endpoints to include a
        "Content-Transfer-Encoding" heading, heading and the payloads to be
         base64-encoded DER <xref target="RFC4648" format="default"/> Base64 encoded DER. format="default"/>.
      </t>
      <t>
        When used within BRSKI, the original RFC7030 EST endpoints remain
        Base64 encoded,
        base64 encoded <xref target="RFC7030"/> (as clarified by <xref target="RFC8951" format="default"/>), but the new BRSKI end points which endpoints that send and receive binary
        artifacts (specifically, "/.well-known/est/requestvoucher") "/.well-known/brski/requestvoucher") are
        binary. That is, no encoding is used.
      </t>
      <t>
        In the BRSKI context, the EST "Content-Transfer-Encoding" header
        field if present, SHOULD <bcp14>SHOULD</bcp14> be ignored. ignored if present. This header field does not need
        to be included.
      </t>
    </section>
    <section anchor="reducedsecuritymodes" numbered="true" toc="default">
      <name>Reduced security operational modes</name> Security Operational Modes</name>
      <t>
        A common requirement of bootstrapping is to support less secure operational
        modes for support specific 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 lifecycle life-cycle management issues
        identified in <xref target="privacyconsiderations" format="default"/>.  They are presented here as informative
        (non-normative) design guidance for future standardization
        activities.
        <xref target="acpapplicability" format="default"/> provides standardization applicability statements
        for the ANIMA ACP. Other users
        would be expected expect that subsets of these mechanisms could be profiled with an
        accompanying applicability statements similar to the one described in
        <xref target="acpapplicability" format="default"/>.
      </t>
      <t>
        This section is considered non-normative in the generality of the
        protocol.  Use of the suggested mechanisms here MUST <bcp14>MUST</bcp14> be detailed in
        specific profiles of BRSKI, such as in <xref target="acpapplicability" format="default"/>.
      </t>
      <section numbered="true" toc="default">
        <name>Trust Model</name>
        <t>
        This section explains the trust relationships detailed in <xref target="flow" format="default"/>:
        </t>

<figure>
  <name>Elements of BRSKI Trust Model</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+         +---------+    +------------+     +------------+
| Pledge |         | Join    |    | Domain     |     |Manufacturer|
|        |         | Proxy   |    | Registrar  |     | Service    |
|        |         |         |    |            |     | (Internet) |
+--------+         +---------+    +------------+     +------------+
              ]]></artwork>
        <t keepWithPrevious="true">Figure 10</t>
</figure>
        <dl newline="false" spacing="normal">
          <dt>Pledge:</dt>
          <dd>The pledge could be compromised and
            providing
            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 <bcp14>RECOMMENDED</bcp14> but are
            out-of-scope
            out of scope of this document.</dd>
          <dt>Join Proxy:</dt>
          <dd>Provides proxy functionalities but is not
            involved in security considerations.</dd>
          <dt>Registrar:</dt>
          <dd>When interacting with a MASA MASA, a
            registrar makes all decisions. For Ownership Audit Vouchers (see <xref target="RFC8366" format="default"/>) format="default"/>), the registrar is provided an opportunity to
            accept MASA decisions.</dd>
          <dt>Vendor Service, MASA:</dt>
          <dd>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. </dd>
          <dt>Vendor Service, Ownership Validation:</dt>
          <dd>This form of
            manufacturer service is trusted to accurately know which device is owned
            by which domain.</dd>
        </dl>
      </section>
      <section anchor="pledgeReductions" numbered="true" toc="default">
        <name>Pledge security reductions</name> Security Reductions</name>
        <t>
          The following is a list of alternative behaviours behaviors that the
          pledge can be programmed to implement.  These behaviours behaviors are not
          mutually exclusive, nor are they dependent upon each other.
          Some of these methods enable offline and emergency (touch based) (touch-based)
          deployment use cases.  Normative language is used as these behaviours behaviors
          are referenced in later sections in a normative fashion.

        </t>
        <ol spacing="normal" type="1">
          <li>
                The pledge MUST <bcp14>MUST</bcp14> accept nonceless vouchers. This allows for
                a use case where the registrar can not cannot connect to the MASA
                at the deployment time.
                Logging and validity periods address the
                security considerations of supporting these use cases.
              </li>
          <li>
                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
                <bcp14>MUST NOT</bcp14> 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.
              </li>
          <li>
                The pledge MAY <bcp14>MAY</bcp14> have an operational mode where it skips voucher
                validation one time. For example 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 <bcp14>SHOULD</bcp14> 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.
              </li>
          <li>
                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 <bcp14>SHOULD</bcp14> include server certificate verification using
                an on-screen fingerprint.
              </li>
        </ol>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> 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 hardware-assisted Network Endpoint
        Assessment (NEA: (NEA) <xref target="RFC5209" format="default"/>) format="default"/>
        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.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Registrar security reductions</name> Security Reductions</name>
        <t>
          A registrar can choose to accept devices using less secure methods.
          They MUST NOT <bcp14>MUST NOT</bcp14> 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:
        </t>
        <ol spacing="normal" type="1">

          <li>A registrar MAY <bcp14>MAY</bcp14> choose to accept all devices, or all devices of
          a particular type, at the administrator's discretion. This type. The administrator could
            occur when informing all registrars of make this choice in cases where it
          is operationally difficult to configure the registrar with the unique identifiers
          identifier of each new
            entities might be operationally difficult.</li> device expected.</li>

          <li>A registrar MAY <bcp14>MAY</bcp14> 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 factory-installed credential. New Entities entities without an
            X.509 IDevID credential MAY <bcp14>MAY</bcp14> form the request per <xref target="RequestVoucherFromRegistrar" format="default"/> request using the
            format per <xref target="RequestVoucherFromMASA" format="default"/> format 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.) pledge). The pledge MAY <bcp14>MAY</bcp14> refuse to
            provide a TLS client certificate Client Certificate (as one is not available.) available). The
            pledge SHOULD <bcp14>SHOULD</bcp14> support HTTP-based or certificate-less TLS
            authentication as described in EST RFC7030 section 3.3.2. <xref target="RFC7030"
sectionFormat="comma" section="3.3.2"/>. A
            registrar MUST NOT <bcp14>MUST NOT</bcp14> accept unauthenticated New Entities 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.)</li>
          <li>A registrar MAY <bcp14>MAY</bcp14> submit a nonceless voucher-requests voucher-request to the MASA
            service (by not including a nonce in the voucher-request.) 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.</li>
          <li>
              A registrar MAY <bcp14>MAY</bcp14> 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.
            </li>
          <li>A registrar MAY <bcp14>MAY</bcp14> accept voucher formats of future types that
              can not
              cannot be parsed by the Registrar. registrar. This reduces the Registrar's registrar's
              visibility into the exact voucher contents but does not change
              the protocol operations.</li>
        </ol>
      </section>
      <section anchor="masasecurityreductions" numbered="true" toc="default">
        <name>MASA security reductions</name> Security Reductions</name>
        <t>
          Lower security modes chosen by the MASA service affect all device
          deployments unless the lower-security 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. registrar.
        </t>
        <section anchor="masasecurityreduction_nonce" numbered="true" toc="default">
          <name>Issuing Nonceless vouchers</name> Vouchers</name>
          <t>
            A MASA has the option of not including a nonce in the voucher, 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 and, in
            effect
            effect, makes the specified Domain domain an always trusted entity to the
            pledge during any subsequent bootstrapping attempts. That The log information captures when
            a nonceless voucher was issued is captured in the log information issued so that the registrar
            can make appropriate security decisions when a pledge joins the
            Domain.
            domain. Nonceless vouchers are useful to support use cases where registrars might
            not be online during actual device deployment.
          </t>
          <t>
            While a nonceless voucher may include an expiry date, a typical
            use for a nonceless voucher is for it to be long-lived. 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.
          </t>
          <t>
            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  Thus, many nonceless vouchers
            will have no expiry dates.
          </t>
          <t>
            Thus, the long lived long-lived nonceless voucher does not require the 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 <bcp14>RECOMMENDED</bcp14> 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.
          </t>
          <t>
            If the pledge device is known to have
            a real-time-clock real-time clock that is set from the factory, use of a voucher
            validity period is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
          </t>
        </section>
        <section anchor="masasecurityreduction_tofu" numbered="true" toc="default">
          <name>Trusting Owners on First Use</name>
          <t>
            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 chain, and it allows
            for a very low overhead MASA service.
	    A registrar uses the audit
            log audit-log
            information as a an in-depth defense in depth strategy to ensure that this
            does not occur unexpectedly (for example example, when purchasing new
            equipment
            equipment, the registrar would throw an error if any audit log audit-log
            information is reported.) reported). The MASA SHOULD <bcp14>SHOULD</bcp14> verify the
            'prior-signed-voucher-request'
            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.
          </t>
          <t>
            A MASA that practices Trust-on-First-Use (TOFU) TOFU for Registrar registrar
            identity may wish to annotate the origin of the connection
            by IP address or netblock, netblock and restrict future use of that
            identity from other locations.  A MASA that does this SHOULD <bcp14>SHOULD</bcp14>
            take care to not create nuisance situations for itself when
            a customer has multiple registrars, registrars or uses outgoing IPv4 NAT44 IPv4-to-IPv4 NAT (NAT44)
            connections that change frequently.
          </t>
        </section>
        <section anchor="masasecurityreduction_newanchor" numbered="true" toc="default">
          <name>Updating or extending voucher trust anchors</name> Extending Voucher Trust Anchors</name>
          <t>
            This section deals with the problem of a two problems: A MASA that is no longer available due to
	    a failed business, or the situation where business and a MASA that is uncooperative to a secondary sale.
          </t>
          <t>
            A manufacturer could offer a management mechanism that allows the
            list of voucher verification trust anchors to be extended.
            <xref target="I-D.ietf-netconf-keystore" format="default"/> is 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.
          </t>
          <t>
            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), seller) or some other trusted third party who is mediating
            the sale.  If it was is a third party, then the seller would need
            to have taken take steps to introduce the third party third-party configuration to
            the device prior to disconnection.  The third party
            (e.g.
            (e.g., a wholesaler of used equipment) could however could, however,
            use a mechanism described in <xref target="pledgeReductions" format="default"/>
            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 can not cannot
            be replaced, the new owner's Registrar registrar would have to support
            an override of the MASA URL.
          </t>
          <t>
            To be useful for resale or other transfers of ownership 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. enterprise.  This would
            entail having previous configuration in the system until entirely
            replaced by the new owner, and it represents some level of risk.
          </t>
          <t>
            The
            For the second mechanism is that 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 second 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 device, and this may be unacceptable to
            some owners.
          </t>
          <t>
            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, power but is also a lot of responsibility: if access to
            the private part of the new anchors
            are lost lost, the manufacturer may be unable to help.
          </t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requires
      <t>Per this document, IANA has completed the following IANA actions:</t> actions.</t>
      <section numbered="true" toc="default">
        <name>The IETF XML Registry</name>
        <t>
          This document registers a URI in the "IETF XML
          Registry" <xref target="RFC3688" format="default"/>.
          IANA is asked to register has registered the following:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request
            Registrant Contact: The
<dl spacing="compact">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-voucher-request</dd>
<dt>Registrant Contact:</dt><dd>The ANIMA WG of the IETF.
            XML: N/A, IETF.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
            ]]></artwork> namespace.</dd>
</dl>
      </section>
      <section numbered="true" toc="default">
        <name>YANG Module Names Registry</name>
        <t>
          This document registers a YANG module in the
          "YANG Module Names" registry <xref target="RFC6020" format="default"/>.
          IANA is asked to register has registered the following:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
              name:         ietf-voucher-request
              namespace:    urn:ietf:params:xml:ns:yang:ietf-voucher-request
              prefix:       vch
              reference:    THIS DOCUMENT
              ]]></artwork>
<dl spacing="compact">
              <dt>Name:</dt><dd>ietf-voucher-request</dd>
              <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-voucher-request</dd>
              <dt>Prefix:</dt><dd>vch</dd>
              <dt>Reference:</dt><dd>RFC 8995</dd>
</dl>
      </section>

 <section numbered="true" toc="default">
        <name>Well-known EST registration</name>
        <name>BRSKI Well-Known Considerations</name>
        <section numbered="true" toc="default">
          <name>BRSKI .well-known Registration</name>
          <t>
          This
            To the "Well-Known URIs" registry at
            <eref target="https://www.iana.org/assignments/well-known-uris/"/>,
            this document extends registers the definitions of "est" (so far defined via
          RFC7030) in well-known name "brski" with the
          "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml"
          registry.
            following filled-in template from <xref target="RFC8615" format="default"/>:
          </t>
                <dl newline="false" spacing="compact">
                <dt>URI Suffix:</dt><dd>brski</dd>
                <dt>Change Controller:</dt><dd>IETF</dd>
	        </dl>

          <t>
            IANA is asked to change has changed the registration of "est" to now only
            include RFC7030 <xref target="RFC7030" format="default"/> and no longer this document.
            Earlier draft versions of this document used "/.well-known/est" rather
            than "/.well-known/brski".
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>BRSKI .well-known Registry</name>
          <t>
            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 <xref target="RFC8126" format="default"/> process.
            The initial contents of this registry are:
          </t>

<table anchor="table_IANA">
  <name>BRSKI Well-Known URIs</name>
  <thead>
    <tr>
      <th>URI</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>requestvoucher</td>
      <td>pledge to registrar, and from registrar to MASA</td>
      <td>RFC 8995</td>

    </tr>
    <tr>
      <td>voucher_status</td>
      <td>pledge to registrar</td>
      <td>RFC 8995</td>
    </tr>
 <tr>
      <td>requestauditlog</td>
      <td>registrar to MASA</td>
      <td>RFC 8995</td>
 </tr>
  <tr>
      <td>enrollstatus</td>
      <td>pledge to registrar</td>
      <td>RFC 8995</td>
    </tr>
</tbody>
</table>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>PKIX Registry</name>
        <t>IANA is requested to register has registered the following:</t>
        <t>
          This document requests
          a number for id-mod-MASAURLExtn2016(TBD) id-mod-MASAURLExtn2016(96)
          from the pkix(7) id-mod(0) Registry.
        </t>
        <t>
          This document
          IANA has received an early allocation assigned a number from the id-pe registry
          (SMI
          (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.
        <!-- https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.1 -->

        </t>
      </section>
      <section anchor="pledgestatustelemetryregistry" numbered="true" toc="default">
        <name>Pledge BRSKI Status Telemetry</name>
        <t>
          IANA is requested to create has created a new Registry entitled: registry entitled "BRSKI
          Parameters",
          Parameters" and has created, within that Registry to create registry, a table called:
          "Pledge BRSKI Status Telemetry Attributes".
          New items can be added using the
          Specification Required. Required process.  The following items are to be in the
          initial registration, with this document (<xref (see <xref target="pledgestatus" format="default"/>) as the reference:
        </t>
        <ul spacing="normal">
          <li>version</li>
          <li>Status</li>
          <li>Reason</li>
          <li>reason-context</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>DNS Service Names</name>
        <t>IANA is requested to register has registered the following Service Names:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Service Name: brski-proxy
Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>.
Contact: IESG <iesg@ietf.org>
Description: The service names:</t>

<dl spacing="compact">
<dt>Service Name:</dt><dd>brski-proxy</dd>
<dt>Transport Protocol(s):</dt><dd>tcp</dd>
<dt>Assignee:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
<dt>Contact:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
<dt>Description:</dt><dd>The Bootstrapping Remote Secure Key
             Infrastructures Proxy
Reference: [This document]

Service Name: brski-registrar
Transport Protocol(s): tcp
Assignee: IESG <iesg@ietf.org>.
Contact: IESG <iesg@ietf.org>
Description: The Infrastructure
Proxy</dd>
<dt>Reference:</dt><dd>RFC 8995</dd>
</dl>
<dl spacing="compact">
<dt>Service Name:</dt><dd>brski-registrar</dd>
<dt>Transport Protocol(s):</dt><dd>tcp</dd>
<dt>Assignee:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
<dt>Contact:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
<dt>Description:</dt><dd>The Bootstrapping Remote Secure Key
             Infrastructures Registrar
Reference: [This document]
          ]]></artwork> Infrastructure
Registrar</dd>
<dt>Reference:</dt><dd>RFC 8995</dd>
</dl>
      </section>
 <section numbered="true" toc="default">
        <name>GRASP Objective Names</name>
        <t>IANA has registered the following GRASP Objective
        Names:</t>
        <t>
          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 <xref target="brskigrasp" format="default"/> of this document.
        </t>
        <t>
          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 <xref target="JRCgrasp" format="default"/> of this document.
        </t>
      </section>
    </section>

    <section anchor="acpapplicability" numbered="true" toc="default">
      <name>Applicability to the Autonomic Control Plane (ACP)</name>
      <t>
        This document provides a solution to the requirements for secure
        bootstrap set out
        bootstrapping as defined in <xref "<xref target="RFC8368" format="default">Using an Autonomic Control Plane for
        Stable Connectivity of Network Operations, Administration, and
        Maintenance </xref>,
format="title"/>" <xref target="I-D.ietf-anima-reference-model" format="default">A target="RFC8368" format="default"/>,
       "A Reference Model for Autonomic Networking</xref> Networking" <xref target="RFC8993" format="default"/>, and specifically the
        <xref target="I-D.ietf-anima-autonomic-control-plane" format="default">An
       "An Autonomic Control Plane (ACP)</xref>, section 3.2 (Secure Bootstrap), (ACP)" <xref target="RFC8994" format="default"/>; see Sections <xref target="RFC8994" sectionFormat="bare" section="3.2"/> ("Secure Bootstrap over an Unconfigured Network") and
        section 6.1 (ACP
        <xref target="RFC8994" sectionFormat="bare" section="6.2"/> ("ACP Domain, Certificate Certificate, and Network). Network").
      </t>
      <t>
        The protocol described in this document has appeal in a number of
        other non-ANIMA use cases.  Such uses of the protocol will be
        deploying
        deployed into other environments with different tradeoffs of
        privacy, security, reliability reliability, and autonomy from manufacturers.
        As such such, those use cases will need to provide their own applicability
        statements,
        statements and will need to address unique privacy and security
        considerations for the environments in which they are used.
      </t>
      <t>
        The autonomic control plane (ACP) ACP that is bootstrapped by
        the BRSKI protocol is typically used in medium to large Internet
        Service Provider
        service provider organizations. Equivalent enterprises that have
        significant layer-3 Layer 3 router connectivity also will find significant
        benefit, particularly if the Enterprise enterprise has many sites.
        (A network consisting of primarily layer-2 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). ACP.)
      </t>
      <t>
        In the ACP, the Join Proxy is found to be proximal because
        communication between the pledge and the join proxy Join Proxy is exclusively
        on IPv6 Link-Local link-local addresses.  The proximity of the
        Join Proxy to the Registrar registrar is validated by the Registrar registrar using ANI
        ACP IPv6 Unique Local Addresses (ULA). ULAs.
        ULAs are not routable over the Internet, so as long as the Join
        Proxy is operating correctly correctly, the proximity asssertion assertion is satisfied.
	Other uses of BRSKI will need make similar analysis if they
        use proximity assertions.
      </t>
      <t>
        As specified in the ANIMA charter, this work "..focuses "focuses on
        professionally-managed networks."  Such a network has an operator
        and can do things like install, configure configure, and operate the
        Registrar
        registrar function.  The operator makes purchasing decisions
        and is aware of what manufacturers it expects to see on its
        network.
      </t>
      <t>
        Such an operator is also capable of performing bootstrapping of a
        device using a serial-console serial console (craft console). The zero-touch
        mechanism presented in this and the ACP document <xref target="I-D.ietf-anima-autonomic-control-plane" target="RFC8994" format="default"/>
        represents a
        significiant
        significant efficiency: in particular particular, it reduces the need to
        put senior experts on airplanes to configure devices in person.
      </t>
      <t>
        There is a recognition as
        As the technology evolves evolves, there is recognition that not every
        situation may work out, and occasionally a human may still have to
        visit.  In recognition of  Given this, some mechanisms are presented in
        <xref target="pledgeReductions" format="default"/>. The manufacturer MUST <bcp14>MUST</bcp14> provide at
        least one of the one-touch mechanisms described that permit
        enrollment to be proceed without the availability of any manufacturer
        server (such as the MASA).
      </t>
      <t>
        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, 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.
      </t>
      <section anchor="operationalrequirements" numbered="true" toc="default">
        <name>Operational Requirements</name>
        <t>
          This section collects operational requirements based upon the three
          roles involved in BRSKI: The Manufacturer Authorized Signing
          Authority (MASA), the (Domain) Owner MASA, the (domain) owner, and the Device. device.
          It should be recognized that the manufacturer may be involved in two
          roles, as it creates the software/firmware for the device, device and also
          may also be the operator of the MASA.
        </t>
        <t>
          The requirements in this section are presented using BCP14
          (<xref BCP 14 language
          <xref target="RFC2119" format="default"/>, format="default"/> <xref target="RFC8174" format="default"/>)
          language. format="default"/>.

	  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 <bcp14>MAY</bcp14> have different different, requirements.
        </t>
        <section anchor="masarequirements" numbered="true" toc="default">
          <name>MASA Operational Requirements</name>
          <t>
            The manufacturer MUST <bcp14>MUST</bcp14> arrange for an online service to be available called the MASA. MASA to be available. It MUST <bcp14>MUST</bcp14> be available at the URL which that is encoded
            in the IDevID certificate extensions described in <xref target="MASAURL" format="default"/>.
          </t>
          <t>
            The online service MUST <bcp14>MUST</bcp14> have access to a private key with which to
            sign voucher artifacts <xref target="RFC8366" format="default"/> format voucher artifacts. format="default"/>.  The public
            key, certificate, or certificate chain MUST <bcp14>MUST</bcp14> be built in to into the
            device as part of the firmware.
          </t>
          <t>
            It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the manufacturer arrange for this signing
            key (or keys) to be escrowed according to typical software source
            code escrow practices <xref target="softwareescrow" format="default"/>.
          </t>
          <t>
            The MASA accepts voucher requests voucher-requests from Domain Owners 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 domain owners need
            to be positively identified by TLS pinned Client Certicate pinned, Certificates or an HTTP
            Authentication
            authentication process.  The MASA creates signed voucher artifacts
            according to its internally defined policies.
          </t>
          <t>
            The MASA MUST <bcp14>MUST</bcp14> operate an audit log audit-log for devices that is accessible.
            The audit log audit-log is designed to be easily cacheable cacheable, and the MASA MAY <bcp14>MAY</bcp14>
            find it useful to put this content on a CDN. Content Delivery Network (CDN).
          </t>
        </section>
        <section anchor="domainownerrequirements" numbered="true" toc="default">
          <name>Domain Owner Operational Requirements</name>
          <t>
            The domain owner MUST <bcp14>MUST</bcp14> operate an EST (<xref <xref target="RFC7030" format="default"/>) format="default"/>
            server with the extensions described in this document.  This is
            the JRC or Registrar. registrar.  This JRC/EST
            server MUST <bcp14>MUST</bcp14> announce itself using GRASP within the ACP.  This EST
            server will typically reside with the Network Operations Center for
            the organization.
          </t>
          <t>
            The domain owner MAY <bcp14>MAY</bcp14> operate an internal certificate authority (CA) CA that
            is seperate separate from the EST server, or it MAY <bcp14>MAY</bcp14> 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 <bcp14>MAY</bcp14> be announced into the ACP
            from multiple locations to achieve an appropriate level of
            redundancy.
          </t>
          <t>
            In order to recognize which devices and which manufacturers are
            welcome on the domain owner's network, the domain owner SHOULD <bcp14>SHOULD</bcp14>
            maintain a white list an acceptlist of manufacturers.  This MAY <bcp14>MAY</bcp14> extend to
            integration with purchasing departments to know the serial numbers
            of devices.
          </t>
          <t>
            The domain owner SHOULD <bcp14>SHOULD</bcp14> use the resulting overlay ACP network to
            manage devices, replacing legacy out-of-band mechanisms.
          </t>
          <t>
            The domain owner SHOULD <bcp14>SHOULD</bcp14> operate one or more EST servers which that can
            be used to renew the domain certificates (LDevIDs) (LDevIDs), which are
            deployed to devices.  These servers MAY <bcp14>MAY</bcp14> be the same as the JRC, JRC or
            MAY
            <bcp14>MAY</bcp14> be a distinct set of devices, as approriate appropriate for resiliency.
          </t>
          <t>
            The organization MUST <bcp14>MUST</bcp14> take appropriate precautions against loss of
            access to the certificate authority CA private key.  Hardware security
            modules and/or secret splitting are appropriate.
          </t>
        </section>
        <section anchor="devicerequirements" numbered="true" toc="default">
          <name>Device Operational Requirements</name>
          <t>
            Devices MUST <bcp14>MUST</bcp14> come with built-in trust anchors that permit the device to
            validate vouchers from the MASA.
          </t>
          <t>
            Device MUST
            Devices <bcp14>MUST</bcp14> come with (unique, per-device) IDevID certificates that
            include their serial numbers, numbers and the MASA URL extension.
          </t>
          <t>
            Devices are expected to find Join Proxies using GRASP, and then connect
            to the JRC using the protocol described in this document.
          </t>
          <t>
            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 link-local addresses as
            described in  <xref target="I-D.ietf-anima-autonomic-control-plane" target="RFC8994" format="default"/>.
          </t>
          <t>
            Once a device has been enrolled enrolled, it SHOULD <bcp14>SHOULD</bcp14> listen for the address
            of the JRC using GRASP, and it SHOULD <bcp14>SHOULD</bcp14> enable itself as a Join
            Proxy,
            Proxy and announce itself on all links/interfaces using GRASP DULL.
          </t>
          <t>
            Devices are expected to renew their certificates before they
            expire.
          </t>
        </section>
      </section>
    </section>
    <section anchor="privacyconsiderations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <section numbered="true" toc="default">
        <name>MASA audit log</name> Audit-Log</name>
        <t>
        The MASA audit log 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 Denial-of-Service attacks (<xref target="dosmasa" format="default"/>),
        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.
        </t>
        <t>
        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.
        </t>
        <t>
        Additionally
        Additionally, the domainID captures only the unauthenticated
        subject key identifier of the domain. A privacy sensitive privacy-sensitive domain could
        theoretically generate a new domainID for each device being
        deployed. Similarly Similarly, a privacy sensitive 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 Registrar based audit log the registrar-based audit-log inspection.
        </t>
      </section>
      <section anchor="idevidregistrar" numbered="true" toc="default">
        <name>What BRSKI-EST reveals</name> Reveals</name>
        <t>
            During the provisional phase of the BRSKI-EST connection between
            the Pledge pledge and the Registrar, registrar, each party reveals its
            certificates to each other.  For the Pledge, pledge, this includes the
            serialNumber attribute, the MASA URL, and the identity that
            signed the IDevID certificate.
        </t>
        <t>
            TLS 1.2 reveals the certificate identities to on-path observers,
            including the Join Proxy.
        </t>
        <t>
            TLS 1.3 reveals the certificate identities only to the end
            parties, but as the connection is provisional, provisional; an on-path
            attacker (MTIM) (MITM) can see the certificates.  This includes not just
            malicious attackers, attackers but also Registrars registrars that are visible
            to the Pledge, pledge but which are not part of the intended domain.
        </t>
        <t>
            The certificate of the Registrar registrar is rather arbitrary from the
            point of view of the BRSKI protocol. As no
            validations <xref target="RFC6125" format="default"/>
            validations are expected to be done, the contents could be easily
            pseudonymized.  Any device that can see a join proxy Join Proxy would be
            able to connect to the Registrar 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.
        </t>
        <t>
            The certificate of the Pledge 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 pledge to third parties if it chose to do so.
        </t>
        <t>
            Research into a mechanism to do multi-step, multi-party multistep, multiparty authenticated
            key agreement, incorporating some kind of zero-knowledge proof proof,
            would be valuable.  Such a mechanism would ideally avoid
            disclosing identities until the pledge, registrar 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, pledge
            or the identity of the MASA.  This part of the problem may be unsolveable. unsolvable.
        </t>
      </section>
      <section anchor="idevidprivacy" numbered="true" toc="default">
        <name>What BRSKI-MASA reveals Reveals to the manufacturer</name> Manufacturer</name>
        <t>
            With consumer-oriented devices, the "call-home" mechanism in IoT
            devices raises significant privacy concerns.  See
            <xref target="livingwithIoT" format="default"/> and <xref target="IoTstrangeThings" format="default"/> for exemplars.  The Autonomic Control
            Plane (ACP) ACP usage of BRSKI is not targeted at individual usage of
            IoT devices, devices but rather at the Enterprise enterprise and ISP creation of
            networks in a zero-touch fashion where the "call-home" represents
            a different class of privacy and lifecycle life-cycle management concerns.
        </t>
        <t>
            It needs to be re-iterated 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) occur.)
        </t>
        <t>
            The BRSKI call-home mechanism is mediated via the owner's
            Registrar,
            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.
        </t>
        <t>
            While the contents of the signed part of the pledge voucher request
            can not 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 re-iterate, reiterate, encrypted by TLS while in transit.
        </t>
        <t>
            The BRSKI-MASA exchange reveals the following information to the
            manufacturer:
        </t>
        <ul spacing="normal">
          <li>
                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.
              </li>
          <li>
                an identity of the domain owner in the form of the domain
                trust anchor.  However, this is not a global PKI anchored 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, either via either
                a pinned certificate, certificate or perhaps another HTTP authentication
                method, as per <xref target="MASAauthenticationOfRegistrar" format="default"/>.
              </li>
          <li>
                the time the device is activated, activated.
              </li>
          <li>
                the IP address of the domain Owner's Registrar. owner's registrar.
                For ISPs and Enterprises, enterprises, the IP address provides very clear
                geolocation of the owner.  No amount of IP address privacy
                extensions (<xref target="RFC4941" format="default"/>) <xref target="RFC8981" format="default"/> can do anything about
                this, as a simple whois lookup likely identifies the ISP or
                Enterprise
                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.
              </li>
        </ul>
        <t>
            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.
        </t>
        <t>
            The manufacturer knows the IP address of the Registrar, registrar, but it
            can not
            cannot see the IP address of the device itself.  The
            manufacturer can not cannot track the device to a detailed physical
            or network location, only to the location of the Registrar. registrar.
            That is likely to be at the Enterprise enterprise or ISPs ISP's headquarters.
        </t>
        <t>
            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 establish established baseline would, however, be notable.
        </t>
        <t>
            The situation is not improved by the enterprise/ISP using
            anonymization services such as Tor <xref target="Dingledine2004" format="default">ToR</xref>, target="Dingledine" format="default"/>, 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 Man-In-The-Middle-Attack MITM attack on the first attempt
            (breaking/killing it with a TCP RST), reset (RST)), and then letting subsequent
            connection pass through.
        </t>
        <t>
            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 companies company's normal marketing
            site is hosted behind.  This makes lots 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 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 re-designs, redesigns, outsourcing, etc.)
            separate from the MASA, which may need to operate reliably for
            decades.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Manufacturers and Used or Stolen Equipment</name>
        <t>
            As explained above, the manufacturer receives information each
            time that a device which that is in factory-default mode does a
            zero-touch bootstrap, bootstrap and attempts to enroll into a domain
            owner's registrar.
        </t>
        <t>
            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.
        </t>
        <ol spacing="normal" type="1">
          <li>
                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.
              </li>
          <li>
                In the case of Used 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.
              </li>
          <li>
                A manufacturer could however 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.
              </li>
          <li>
                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, component), the device would not bootstrap.
              </li>

          <li>
                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.
              </li>
        </ol>
        <t>
            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), repeat) a daily or even monthly
            occurrence.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Manufacturers and Grey market equipment</name> Market Equipment</name>
        <t>
            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 tech support to be done in the
            local language), and government export regulation (such as whether
            strong crypto is permitted to be exported, exported or permitted to be
            used in a particular market).  When an 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.
        </t>
        <t>
            A manufacturer could decide not to issue a voucher to an
            enterprise/ISP based upon their location.  There are a number of
            ways which that this could be determined: from the geolocation of the
            registrar, from sales channel knowledge about the customer, and
            from what products are (un-)available available or unavailable in that market.  If the device
            has a GPS GPS, the coordinates of the device could even be placed into
            an extension of the voucher.
        </t>
        <t>
            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, firmware or a license key that will activate the correct
            firmware.
        </t>
        <t>
            BRSKI permits the above process to be automated (in an autonomic
            fashion),
            fashion) and therefore perhaps encourages this kind of
            differentiation by reducing the cost of doing it.
        </t>
        <t>
            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 come to
            believe they are dealing with Grey market equipment, Market equipment when it
            is they
            are simply dealing with a global enterprise.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Some mitigations Mitigations for meddling Meddling by manufacturers</name> Manufacturers</name>
        <t>
            The most obvious mitigation is not to buy the product.
            Pick manufacturers that are up-front up front about their policies, policies and who do
            not change them gratuitously.
        </t>
        <t>
            <xref target="masasecurityreduction_newanchor" format="default"/>
            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 mechanism, 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, here but rather
            allow the starting trust assumptions to be changed.
            This is an area for
            future standardization work.
        </t>
        <t>
            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
            to
            run a MASA.
        </t>
        <t>
            The BRSKI protocol depends upon a trust anchor on the device
            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, devices and then acts as a pseudonymized MASA for a variety
            of devices from a variety of manufacturers.
        </t>
        <t>
            Although replacement of the IDevID is not required for all
            modes described above, a manufacturers manufacturer could support such a
            thing.   Some may wish to consider replacement of the IDevID
            as an indication that the device's warrantee warranty is terminated.
            For others, the privacy requirements of some deployments might
            consider this a standard operating practice.
        </t>
        <t>
            As discussed at the end of <xref target="MASAauditlog" format="default"/>,
            new work could be done to use a
            distributed consensus technology for the audit log. audit-log.
            This would permit the audit log audit-log to continue to be useful,
            even when there is a chain of MASA due to changes of ownership.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Death of a manufacturer</name> Manufacturer</name>
        <t>
            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,
            deployed but need to be re-initialized, they might have been
            purchased reinitialized, used, or they might have  kept in a warehouse as
            long-term spares.
        </t>
        <t>
            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 advertising, and janitorial services.
        </t>
        <t>
            Further, it is expected that as part of any service agreement
            that 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.
        </t>
      </section>
    </section>
    <section anchor="securityconsiderations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        This document details a protocol for bootstrapping that balances
        operational concerns against security concerns. As detailed in the introduction,
        and touched on again in <xref target="reducedsecuritymodes" format="default"/>,
        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.
      </t>
      <t>
        To facilitate logging and administrative oversight, in addition
        to triggering Registrar 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 <bcp14>RECOMMENDED</bcp14> to verify MASA logs
      if voucher status telemetry is not received.</t>

      <t>To facilitate truly limited clients clients, EST RFC7030 section 3.3.2
      requirements
      requires that the client MUST <bcp14>MUST</bcp14> support a client authentication model
      have been reduced in (see <xref target="RFC7030" sectionFormat="comma" section="3.3.2"/>);
      <xref target="reducedsecuritymodes" format="default"/> to a
      statement updates these requirements by stating that the registrar "MAY" <bcp14>MAY</bcp14> choose to accept devices
      that fail cryptographic authentication. This reflects
      current (poor) practices in shipping devices without a cryptographic
      identity that are NOT RECOMMENDED.</t> <bcp14>NOT RECOMMENDED</bcp14>.</t>

      <t>During the provisional period of the connection connection, the pledge MUST <bcp14>MUST</bcp14> 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.
      </t>

      <t>Pledges might chose to engage in protocol operations with
      multiple discovered registrars in parallel. As noted above 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 failure, and the pledge
      choses
      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 analytics analytic purposes.</t>

      <section anchor="dosmasa" numbered="true" toc="default">
        <name>Denial of Service (DoS) against MASA</name>
        <t>There are uses use cases where the MASA could be unavailable or
        uncooperative to the Registrar. 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
        registrar owner in that MASA behavior might limit the ability to
        bootstrap a pledge device. For example example, this might be an issue during
        disaster recovery. This risk can be mitigated by Registrars registrars that
        request and maintain long term long-term copies of "nonceless" vouchers. In
        that way way, they are guaranteed to be able to bootstrap their devices.</t>

        <t>The issuance of nonceless vouchers themselves creates a security
        concern. If the Registrar registrar of a previous domain can intercept protocol
        communications
        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 audit-log that is verified by the subsequent Registrar registrar
        and by Pledges 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.</t>

        <t>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 Supply-chain
        integration ("know your customer") is an additional
        step that MASA providers and device vendors can explore.</t>
      </section>
      <section numbered="true" toc="default">
        <name>DomainID must be resistant Must Be Resistant to second-preimage attacks</name> Second-Preimage Attacks</name>
        <t>
          The domainID is used as the reference in the audit log 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 audit-log
          entries that are fake.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Availability of good random numbers</name> Good Random Numbers</name>
        <t>
          The nonce used by the Pledge pledge in the voucher-request SHOULD <bcp14>SHOULD</bcp14> be
          generated by a Strong Cryptographic Sequence (<xref target="RFC4086" format="default"/> section 6.2).
sectionFormat="comma" section="6.2"/>).  TLS has a similar requirement.
        </t>
        <t>
          In particular particular, implementations should pay attention to the advance
          in  <xref target="RFC4086" format="default"/> section 3, particularly section 3.4. format="default"/>; see Sections <xref target="RFC4086" sectionFormat="bare" section="3"/> and, in particular,
 <xref target="RFC4086" sectionFormat="bare" section="3.4"/>.
          The random seed used by a device at boot MUST <bcp14>MUST</bcp14> be
          unique across all devices and all bootstraps.  Resetting a device to
          factory default state does not obviate this requirement.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Freshness in Voucher-Requests</name>
        <t>
          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.
        </t>
        <t>
          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.
        </t>
        <t>
          Because the registrar authenticates the pledge, a full Man-in-the-Middle MITM
          attack is not possible, despite the provisional TLS authentication
          by the pledge (see <xref target="ProtocolDetails" format="default"/>.)
          Instead
          Instead, we examine the case of a fake registrar (Rm)
          that communicates with the pledge in parallel or in close time close-time proximity
          with the intended registrar. (This scenario is intentionally supported as
          described in <xref target="discovery" format="default"/>.)
        </t>
        <t>
          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 (either because (because
          either the Rm is collaborating with a legitimate registrar according to supply chain
          information, supply-chain
          information or because the MASA is in audit-log only mode), then
          a voucher linking the pledge to the registrar Rm is issued.
        </t>
        <t>
          Such a voucher, when passed back to the pledge, would link the
          pledge to registrar Rm, Rm and would permit the pledge to
          end the provisional state. It now trusts the Rm and, if it has any
          security vulnerabilities leveragable leverageable by an Rm with full
          administrative control, can be assumed to be a
          threat against the intended registrar.
        </t>
        <t>
          This flow is mitigated by the intended registrar verifying the audit
          logs audit-logs
          available from the MASA as described in
          <xref target="authzLogRequest" format="default"/>. 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' "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 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.</t>
        <t>
          Additionally, in order to successfully use the resulting voucher voucher, the Rm
          would have to attack the pledge and return it to a bootstrapping
          enabled bootstrapping-enabled
          state. This would require wiping the pledge of current
          configuration and triggering a re-bootstrapping rebootstrapping of the pledge.
          This is no more likely than simply taking control of the pledge
          directly
          directly, but if this is a consideration consideration, it is
          <bcp14>RECOMMENDED</bcp14> that the target network is
          RECOMMENDED to take the following steps:
        </t>
        <ul spacing="normal">
          <li>Ongoing network monitoring for unexpected bootstrapping attempts by pledges.</li>
          <li>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.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Trusting manufacturers</name> Manufacturers</name>
        <t>
          The BRSKI extensions to EST permit a new pledge to be completely
          configured with domain specific 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.
        </t>
        <t>
          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 <xref target="IDevIDextension" format="default"/>, the malicious pledge will have no problem
          collaborating with it's its MASA to produce a completely valid voucher.
        </t>
        <t>
          BRSKI does not, however, fundamentally change the trust model from
          domain owner to manufacturer.  Assuming that the pledge used
          its IDevID with RFC7030 EST <xref target="RFC7030"/> and BRSKI, the domain
(registrar) still needs to trust the manufacturer.
        </t>
        <t>
          Establishing this trust between domain and manufacturer is outside
          the scope of BRSKI.  There are a number of mechanisms that can be
          adopted including:
        </t>
        <ul spacing="normal">
          <li>
              Manually configuring each manufacturer's trust anchor.
            </li>
          <li>
              A Trust-On-First-Use (TOFU) 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, e.g., dem0.example. vs vs.
              demO.example.
            </li>
          <li>
              scanning the trust anchor from a QR code that came with the
              packaging (this is really a manual TOFU mechanism) mechanism).
            </li>
          <li>
              some sales integration process processing where trust anchors are provided
              as part of the sales process, probably included in a digital
              packing "slip", or a sales invoice.
            </li>
          <li>
              consortium membership, where all manufacturers of a particular
              device category (e.g, a light bulb, bulb or a cable-modem) cable modem) are
              signed by an certificate authority a CA specifically for this.
              This is done by CableLabs today.

	      It is used for authentication
              and authorization as part of TR-79: <xref target="docsisroot" format="default"/> and <xref target="TR069" format="default"/>.
            </li>
        </ul>
        <t>
          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
          useable
          usable on it's its own.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Manufacturer Maintenance of trust anchors</name> Trust Anchors</name>
        <t>
          BRSKI depends upon the manufacturer building in trust anchors
          to the pledge device.  The voucher artifact which 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.
        </t>
        <t>
          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.
        </t>
        <t>
          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
          certificate authority
          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 issues issue in non-constrained
          environments.
        </t>
        <t>
          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 pre-installed. preinstalled.  Devices built in different
          factories, or on different days, or in any other consideration 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.
        </t>
        <t>
          Aside from the concern about long-term access to private keys, a
          major limiting factor for the shelf-life 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, 2019 and will have no defense
          against attacks (both quantum and von-neuman brute force von Neumann brute-force attacks)
          which
          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 lifespan life span of a device in a warehouse.
          If any update to the firmware to support new cryptographic mechanism mechanisms
          were possible (while the device was in a warehouse), updates to
          trust anchors would also be done at the same time.
        </t>
        <t>
          The set of standard operating procedures for maintaining
          high value
          high-value private keys is well documented. For instance,
          the WebPKI provides a number of options for audits at in
          <xref target="cabforumaudit" format="default"/>, and the DNSSEC root operations are well
          documented at in <xref target="dnssecroot" format="default"/>.
        </t>
        <t>
          It is not clear if Manufacturers manufacturers will take this level of
          precaution, or how strong the economic incentives are to maintain
          an appropriate level of security.
        </t>
        <t>
          This
          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
          sections
          below examines the situation where a MASA web server itself
          is under attacker control, but that the MASA signing key itself
          is safe in a not-directly connected hardware module.
        </t>
        <section numbered="true" toc="default">
          <name>Compromise of Manufacturer IDevID signing keys</name> Signing Keys</name>
          <t>
            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, manufacturer
            but can be entirely different devices: Trojan horses in effect.
          </t>
          <t>
            As the attacker controls the MASA URL in the certificate,
            the registrar can be convinced to talk to the attackers' attacker's MASA.
            The Registrar registrar does not need to be in any kind of promiscuous mode
            to be vulnerable.
          </t>
          <t>
            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.
          </t>
          <t>
            There does not otherwise seem to be any risk from this compromise
            to devices which that are already deployed, deployed or which that are sitting
            locally in boxes waiting for deployment (local spares).
            The issue is that operators will be unable to trust devices
            which
            that have been in an uncontrolled warehouse as they do not know
            if those are real devices.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Compromise of MASA signing keys</name> Signing Keys</name>
          <t>
            There are two periods of time in which to consider: when the MASA
            key has fallen into the hands of an attacker, attacker and after the MASA
            recognizes that the key has been compromised.
          </t>
          <section numbered="true" toc="default">
            <name>Attacker opportunties Opportunities with compromised a Compromised MASA key</name> Key</name>
            <t>
              An attacker that has access to the MASA signing key could create
              vouchers.  These vouchers could be for existing deployed
              devices,
              devices or for devices which that are still in a warehouse.
              In order to exploit these vouchers 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.
            </t>
            <t>
              If the attacker controls a Registrar which 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, 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 get to put the device put 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.
            </t>
            <t>
              The above scenario seems rather unlikely as it requires some
              element of physical access; but were 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.
            </t>
            <t>
              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 consumers consumer devices with that have low overall
              implementation quality, the end users might be familiar with
              needing the
              need to reset the device regularly.
            </t>
            <t>
              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 registrar and MASA, and there is no
              opportunity to introduce the fake voucher through that conduit.
            </t>
          </section>
          <section numbered="true" toc="default">
            <name>Risks after key compromise Key Compromise is known</name> Known</name>
            <t>
              Once the operator of the MASA realizes that the voucher signing
              key has been compromised compromised, it has to do a few things.
            </t>
            <t>
              First, it MUST <bcp14>MUST</bcp14> 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 which that are operating, but those devices, being in
              operation, are not performing onboarding operations, so this
              is not a critical patch.
            </t>
            <t>
              Devices in boxes (in warehouses) are vulnerable, 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 high-value
              devices (which typically have a &lt;4hr service window) may be to
              validate the device operation on a regular basis anyway.
            </t>
            <t>
              If the onboarding process includes attestations about firmware
              versions, then through that process 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 registrar (as listed above).
            </t>
            <t>
              <xref target="RFC8366" format="default"/> section 6.1 explains the
              The need for short-lived vouchers. vouchers is explained in <xref target="RFC8366" sectionFormat="comma" 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.
            </t>
            <t>
              A key operational recommendation is for manufacturers to sign
              nonceless, long-lived vouchers with a different key that they 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.
            </t>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Compromise of MASA web service</name> Web Service</name>
          <t>
            An attacker that takes over the MASA web service has can inflict a number of
            attacks.  The most obvious one is simply to take the database
            listing of customers and devices and to sell this the data to other
            attackers who will now know where to find potentially vulnerable
            devices.
          </t>
          <t>
            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 affect effect on
            the ability to deploy new services by customers, customers and would be a
            significant issue during disaster recovery.
          </t>
          <t>
            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), module (HSM)), then the
            key may well be safe, but control over it resides with the attacker.
          </t>
          <t>
            Such an attacker can issue vouchers for any device presently in
            service.
	    Said device still needs to be convinced to do go through a
            factory reset process before an attack.
          </t>
          <t>
            If the attacker has access to a key that is trusted for
            long-lived nonceless vouchers, then they could issue vouchers for
            devices which that are not yet in service.  This attack may be very
            hard to verify and as it would involve doing firmware updates
            on every device in warehouses (a potentially ruinously expensive
            process),
            process); a manufacturer might be reluctant to admit this
            possibility.
          </t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>YANG Module Security Considerations</name>
        <t>
          As described in the Security Considerations section Section <xref target="RFC8366" section="7.4" sectionFormat="bare"/> (Security Considerations) of <xref target="RFC8366" format="default"/> (section 7.4), format="default"/>, 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
          <xref target="RFC5652" format="default"/>. sectionFormat="of" section="5"/>.
          As such, all of the YANG modeled YANG-modeled data is protected from modification.
        </t>
        <t>
           The use of YANG to define data structures, via the 'yang-data' "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 <xref target="RFC6241" format="default"/> and RESTCONF <xref target="RFC8040" format="default"/>. For this
           reason, these guidelines do not follow the template described by
           Section 3.7 of
           <xref target="RFC8407" format="default"/>. sectionFormat="of" section="3.7"/>.
        </t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>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
      </t>
      <t>
        Significant reviews were done by Jari Arko, Christian Huitema and
        Russ Housley.
      </t>
      <t>
        Henk Birkholz contributed the CDDL for the audit log response.
      </t>
      <t>
        This document started it's life as a two-page idea from Steinthor
        Bjarnason.
      </t>
      <t>
        In addition, significant review comments were received by many IESG
        members, including Adam Roach, Alexey Melnikov, Alissa Cooper, Benjamin Kaduk, Eric Vyncke, Roman
        Danyliw, and Magnus Westerlund.
      </t>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-ace-coap-est" to="ACE-COAP-EST"/>
<displayreference target="I-D.richardson-anima-state-for-joinrouter" to="ANIMA-STATE"/>
<displayreference target="I-D.ietf-anima-constrained-voucher" to="ANIMA-CONSTRAINED-VOUCHER"/>
<displayreference target="I-D.ietf-netconf-keystore" to="YANG-KEYSTORE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3927.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7469.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8951.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>

<!-- [I-D.ietf-anima-autonomic-control-plane] part of C325 -->
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> anchor='RFC8994'>
<front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<title>An Autonomic Control Plane (ACP)</title>
<author initials='T' surname='Eckert' fullname='Toerless Eckert' role="editor">
    <organization />
</author>
<author initials='M' surname='Behringer' fullname='Michael Behringer' role="editor">
    <organization />
</author>
<author initials='S' surname='Bjarnason' fullname='Steinthor Bjarnason'>
    <organization />
</author>
<date month='May' year='2021' />
</front>
<seriesInfo name="RFC" value="2119"/> value="8994"/>
<seriesInfo name="BCP" value="14"/> name="DOI" value="10.17487/RFC8994"/>
</reference>

<!-- [I-D.ietf-anima-grasp] part of C325 -->
<reference anchor='RFC8990'>
<front>
<title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/> initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>
<author initials='B' surname='Carpenter' fullname='Brian Carpenter' role="editor">
    <organization />
</author>
<author initials='B' surname='Liu' fullname='Bing Liu' role="editor">
    <organization />
</author>
<date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract> month='May' year='2021' />
</front>
<seriesInfo name="RFC" value="8990"/>
<seriesInfo name="DOI" value="10.17487/RFC8990"/>
</reference>

        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> anchor="ITU.X690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Ambiguity
            <title>Information Technology - ASN.1 encoding rules: Specification of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/> Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract> month="August" year="2015"/>
          </front>
	   <refcontent>ITU-T Recommendation X.690</refcontent>
	  <refcontent>ISO/IEC 8825-1:2015</refcontent>
        </reference>

	   <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"> anchor="IDevID" target="https://1.ieee802.org/security/802-1ar">
        <front>
            <title>The Base16, Base32,
          <title>IEEE Standard for Local and Base64 Data Encodings</title>
            <seriesInfo name="DOI" value="10.17487/RFC4648"/>
            <seriesInfo name="RFC" value="4648"/>
            <author initials="S." surname="Josefsson" fullname="S. Josefsson">
              <organization/>
            </author>
            <date year="2006" month="October"/>
            <abstract>
              <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7030" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml">
          <front>
            <title>Enrollment over Secure Transport</title>
            <seriesInfo name="DOI" value="10.17487/RFC7030"/>
            <seriesInfo name="RFC" value="7030"/>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin" role="editor">
              <organization/>
            </author>
            <author initials="P." surname="Yee" fullname="P. Yee" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Harkins" fullname="D. Harkins" role="editor">
              <organization/>
            </author>
            <date year="2013" month="October"/>
            <abstract>
              <t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5652"/>
            <seriesInfo name="RFC" value="5652"/>
            <seriesInfo name="STD" value="70"/>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization/>
            </author>
            <date year="2009" month="September"/>
            <abstract>
              <t>This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <seriesInfo name="DOI" value="10.17487/RFC8446"/>
            <seriesInfo name="RFC" value="8446"/>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <seriesInfo name="DOI" value="10.17487/RFC5280"/>
            <seriesInfo name="RFC" value="5280"/>
            <author initials="D." surname="Cooper" fullname="D. Cooper">
              <organization/>
            </author>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization/>
            </author>
            <author initials="S." surname="Farrell" fullname="S. Farrell">
              <organization/>
            </author>
            <author initials="S." surname="Boeyen" fullname="S. Boeyen">
              <organization/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization/>
            </author>
            <author initials="W." surname="Polk" fullname="W. Polk">
              <organization/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5272" target="https://www.rfc-editor.org/info/rfc5272" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml">
          <front>
            <title>Certificate Management over CMS (CMC)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5272"/>
            <seriesInfo name="RFC" value="5272"/>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization/>
            </author>
            <author initials="M." surname="Myers" fullname="M. Myers">
              <organization/>
            </author>
            <date year="2008" month="June"/>
            <abstract>
              <t>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</t>
              <t>1.  The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t>
              <t>2.  The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t>
              <t>CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="STD" value="90"/>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <seriesInfo name="DOI" value="10.17487/RFC7950"/>
            <seriesInfo name="RFC" value="7950"/>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml">
          <front>
            <title>JSON Encoding of Data Modeled with YANG</title>
            <seriesInfo name="DOI" value="10.17487/RFC7951"/>
            <seriesInfo name="RFC" value="7951"/>
            <author initials="L." surname="Lhotka" fullname="L. Lhotka">
              <organization/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4519" target="https://www.rfc-editor.org/info/rfc4519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4519.xml">
          <front>
            <title>Lightweight Directory Access Protocol (LDAP): Schema for User Applications</title>
            <seriesInfo name="DOI" value="10.17487/RFC4519"/>
            <seriesInfo name="RFC" value="4519"/>
            <author initials="A." surname="Sciberras" fullname="A. Sciberras" role="editor">
              <organization/>
            </author>
            <date year="2006" month="June"/>
            <abstract>
              <t>This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification.  It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages.  These objects are widely used as a basis for the schema in many LDAP directories.  This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6762" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
          <front>
            <title>Multicast DNS</title>
            <seriesInfo name="DOI" value="10.17487/RFC6762"/>
            <seriesInfo name="RFC" value="6762"/>
            <author initials="S." surname="Cheshire" fullname="S. Cheshire">
              <organization/>
            </author>
            <author initials="M." surname="Krochmal" fullname="M. Krochmal">
              <organization/>
            </author>
            <date year="2013" month="February"/>
            <abstract>
              <t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important.  In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t>
              <t>Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server.  In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t>
              <t>The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6763" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
          <front>
            <title>DNS-Based Service Discovery</title>
            <seriesInfo name="DOI" value="10.17487/RFC6763"/>
            <seriesInfo name="RFC" value="6763"/>
            <author initials="S." surname="Cheshire" fullname="S. Cheshire">
              <organization/>
            </author>
            <author initials="M." surname="Krochmal" fullname="M. Krochmal">
              <organization/>
            </author>
            <date year="2013" month="February"/>
            <abstract>
              <t>This document specifies how DNS resource records are named and structured to facilitate service discovery.  Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3927" target="https://www.rfc-editor.org/info/rfc3927" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3927.xml">
          <front>
            <title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
            <seriesInfo name="DOI" value="10.17487/RFC3927"/>
            <seriesInfo name="RFC" value="3927"/>
            <author initials="S." surname="Cheshire" fullname="S. Cheshire">
              <organization/>
            </author>
            <author initials="B." surname="Aboba" fullname="B. Aboba">
              <organization/>
            </author>
            <author initials="E." surname="Guttman" fullname="E. Guttman">
              <organization/>
            </author>
            <date year="2005" month="May"/>
            <abstract>
              <t>To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server.  Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available.  This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.</t>
              <t>IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).  This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml">
          <front>
            <title>Date and Time on the Internet: Timestamps</title>
            <seriesInfo name="DOI" value="10.17487/RFC3339"/>
            <seriesInfo name="RFC" value="3339"/>
            <author initials="G." surname="Klyne" fullname="G. Klyne">
              <organization/>
            </author>
            <author initials="C." surname="Newman" fullname="C. Newman">
              <organization/>
            </author>
            <date year="2002" month="July"/>
            <abstract>
              <t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">
          <front>
            <title>Randomness Requirements for Security</title>
            <seriesInfo name="DOI" value="10.17487/RFC4086"/>
            <seriesInfo name="RFC" value="4086"/>
            <seriesInfo name="BCP" value="106"/>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization/>
            </author>
            <author initials="J." surname="Schiller" fullname="J. Schiller">
              <organization/>
            </author>
            <author initials="S." surname="Crocker" fullname="S. Crocker">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <abstract>
              <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
          <front>
            <title>IPv6 Stateless Address Autoconfiguration</title>
            <seriesInfo name="DOI" value="10.17487/RFC4862"/>
            <seriesInfo name="RFC" value="4862"/>
            <author initials="S." surname="Thomson" fullname="S. Thomson">
              <organization/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <author initials="T." surname="Jinmei" fullname="T. Jinmei">
              <organization/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6.  The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4941" target="https://www.rfc-editor.org/info/rfc4941" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4941.xml">
          <front>
            <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <seriesInfo name="DOI" value="10.17487/RFC4941"/>
            <seriesInfo name="RFC" value="4941"/>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <author initials="R." surname="Draves" fullname="R. Draves">
              <organization/>
            </author>
            <author initials="S." surname="Krishnan" fullname="S. Krishnan">
              <organization/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t>Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers.  Addresses are formed by combining network prefixes with an interface identifier.  On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it.  On other interface types, the interface identifier is generated through other means, for example, via random number generation.  This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier.  Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier.  Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3748" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml">
          <front>
            <title>Extensible Authentication Protocol (EAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3748"/>
            <seriesInfo name="RFC" value="3748"/>
            <author initials="B." surname="Aboba" fullname="B. Aboba">
              <organization/>
            </author>
            <author initials="L." surname="Blunk" fullname="L. Blunk">
              <organization/>
            </author>
            <author initials="J." surname="Vollbrecht" fullname="J. Vollbrecht">
              <organization/>
            </author>
            <author initials="J." surname="Carlson" fullname="J. Carlson">
              <organization/>
            </author>
            <author initials="H." surname="Levkowetz" fullname="H. Levkowetz" role="editor">
              <organization/>
            </author>
            <date year="2004" month="June"/>
            <abstract>
              <t>This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods.  EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.  Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.  This document obsoletes RFC 2284.  A summary of the changes between this document and RFC 2284 is available in Appendix A.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6125" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml">
          <front>
            <title>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)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6125"/>
            <seriesInfo name="RFC" value="6125"/>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization/>
            </author>
            <author initials="J." surname="Hodges" fullname="J. Hodges">
              <organization/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7230" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
            <seriesInfo name="DOI" value="10.17487/RFC7230"/>
            <seriesInfo name="RFC" value="7230"/>
            <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7231" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <seriesInfo name="DOI" value="10.17487/RFC7231"/>
            <seriesInfo name="RFC" value="7231"/>
            <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7469" target="https://www.rfc-editor.org/info/rfc7469" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7469.xml">
          <front>
            <title>Public Key Pinning Extension for HTTP</title>
            <seriesInfo name="DOI" value="10.17487/RFC7469"/>
            <seriesInfo name="RFC" value="7469"/>
            <author initials="C." surname="Evans" fullname="C. Evans">
              <organization/>
            </author>
            <author initials="C." surname="Palmer" fullname="C. Palmer">
              <organization/>
            </author>
            <author initials="R." surname="Sleevi" fullname="R. Sleevi">
              <organization/>
            </author>
            <date year="2015" month="April"/>
            <abstract>
              <t>This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time.  During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host.  By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-anima-autonomic-control-plane" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-autonomic-control-plane.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-autonomic-control-plane-28.txt">
          <front>
            <title>An Autonomic Control Plane (ACP)</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic-control-plane-28"/>
            <author initials="T" surname="Eckert" fullname="Toerless Eckert">
              <organization/>
            </author>
            <author initials="M" surname="Behringer" fullname="Michael Behringer">
              <organization/>
            </author>
            <author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnason">
              <organization/>
            </author>
            <date month="July" day="28" year="2020"/>
            <abstract>
              <t>Autonomic functions need a control plane to communicate, which depends on some addressing and routing.  This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration.  This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions.  It also serves as a "virtual out-of-band channel" for Operations, Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8366" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml">
          <front>
            <title>A Voucher Artifact for Bootstrapping Protocols</title>
            <seriesInfo name="DOI" value="10.17487/RFC8366"/>
            <seriesInfo name="RFC" value="8366"/>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <author initials="M." surname="Richardson" fullname="M. Richardson">
              <organization/>
            </author>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization/>
            </author>
            <author initials="T." surname="Eckert" fullname="T. Eckert">
              <organization/>
            </author>
            <date year="2018" month="May"/>
            <abstract>
              <t>This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer.  This artifact is known as a "voucher".</t>
              <t>This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure.  Other YANG-derived formats are possible.  The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).</t>
              <t>This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8368" target="https://www.rfc-editor.org/info/rfc8368" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml">
          <front>
            <title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8368"/>
            <seriesInfo name="RFC" value="8368"/>
            <author initials="T." surname="Eckert" fullname="T. Eckert" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization/>
            </author>
            <date year="2018" month="May"/>
            <abstract>
              <t>Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.</t>
              <t>Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on.  Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</t>
              <t>This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes.  This connectivity is not subject to the aforementioned circular dependencies.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-anima-grasp" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-grasp.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-grasp-15.txt">
          <front>
            <title>A Generic Autonomic Signaling Protocol (GRASP)</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-anima-grasp-15"/>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization/>
            </author>
            <author initials="B" surname="Carpenter" fullname="Brian Carpenter">
              <organization/>
            </author>
            <author initials="B" surname="Liu" fullname="Bing Liu">
              <organization/>
            </author>
            <date month="July" day="13" year="2017"/>
            <abstract>
              <t>This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other.  GRASP depends on an external security environment that is described elsewhere.  The technical objectives and parameters for specific application scenarios are to be described in separate documents.  Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <seriesInfo name="DOI" value="10.17487/RFC8610"/>
            <seriesInfo name="RFC" value="8610"/>
            <author initials="H." surname="Birkholz" fullname="H. Birkholz">
              <organization/>
            </author>
            <author initials="C." surname="Vigano" fullname="C. Vigano">
              <organization/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <date year="2019" month="June"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
          <front>
            <title>RESTCONF Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC8040"/>
            <seriesInfo name="RFC" value="8040"/>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6020"/>
            <seriesInfo name="RFC" value="6020"/>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <date year="2010" month="October"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6241"/>
            <seriesInfo name="RFC" value="6241"/>
            <author initials="R." surname="Enns" fullname="R. Enns" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
              <organization/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8407" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml">
          <front>
            <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
            <seriesInfo name="DOI" value="10.17487/RFC8407"/>
            <seriesInfo name="RFC" value="8407"/>
            <seriesInfo name="BCP" value="216"/>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization/>
            </author>
            <date year="2018" month="October"/>
            <abstract>
              <t>This memo provides guidelines for authors and reviewers of specifications containing YANG modules.  Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules.  This document obsoletes RFC 6087.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="ITU.X690.1994" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.ITU.X690.1994.xml">
          <front>
            <title>Information Technology metropolitan area networks - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <seriesInfo name="ITU-T" value="Recommendation X.690"/>
            <author>
              <organization>International Telecommunications Union</organization>
            </author>
            <date month="" year="1994"/>
          </front>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
          <front>
            <title>The IETF XML Registry</title>
            <seriesInfo name="DOI" value="10.17487/RFC3688"/>
            <seriesInfo name="RFC" value="3688"/>
            <seriesInfo name="BCP" value="81"/>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization/>
            </author>
            <date year="2004" month="January"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="IDevID" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
          <front>
            <title>IEEE 802.1AR Secure Device Identifier</title>
            <author surname="IEEE Standard"/>
            <date month="December" year="2009"/>
          </front>
        </reference>
        <reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">
          <front>
            <title>Architectural Styles and the Design of Network-based Software Architectures</title>
            <author initials="R.F." surname="Fielding" fullname="Roy Fielding">
              <organization>University of California, Irvine</organization>
            </author>
            <date year="2000"/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-anima-reference-model" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-reference-model.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-reference-model-10.txt">
          <front>
            <title>A Reference Model for Autonomic Networking</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-anima-reference-model-10"/>
            <author initials="M" surname="Behringer" fullname="Michael Behringer">
              <organization/>
            </author>
            <author initials="B" surname="Carpenter" fullname="Brian Carpenter">
              <organization/>
            </author>
            <author initials="T" surname="Eckert" fullname="Toerless Eckert">
              <organization/>
            </author>
            <author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia">
              <organization/>
            </author>
            <author initials="J" surname="Nobre" fullname="Jeferson Nobre">
              <organization/>
            </author>
            <date month="November" day="22" year="2018"/>
            <abstract>
              <t>This document describes a reference model for Autonomic Networking for managed networks.  It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7435" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml">
          <front>
            <title>Opportunistic Security: Some Protection Most of the Time</title>
            <seriesInfo name="DOI" value="10.17487/RFC7435"/>
            <seriesInfo name="RFC" value="7435"/>
            <author initials="V." surname="Dukhovni" fullname="V. Dukhovni">
              <organization/>
            </author>
            <date year="2014" month="December"/>
            <abstract>
              <t>This document defines the concept "Opportunistic Security" in the context of communications protocols.  Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7575" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml">
          <front>
            <title>Autonomic Networking: Definitions and Design Goals</title>
            <seriesInfo name="DOI" value="10.17487/RFC7575"/>
            <seriesInfo name="RFC" value="7575"/>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization/>
            </author>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization/>
            </author>
            <author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
              <organization/>
            </author>
            <author initials="A." surname="Clemm" fullname="A. Clemm">
              <organization/>
            </author>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization/>
            </author>
            <author initials="S." surname="Jiang" fullname="S. Jiang">
              <organization/>
            </author>
            <author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
              <organization/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t>Autonomic systems were first described in 2001.  The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection.  This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems.  It usually implies distribution across network elements.</t>
              <t>This document defines common language and outlines design goals (and what are not design goals) for autonomic functions.  A high-level reference model illustrates how functional elements in an Autonomic Network interact.  This document is a product of the IRTF's Network Management Research Group.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7228" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
          <front>
            <title>Terminology for Constrained-Node Networks</title>
            <seriesInfo name="DOI" value="10.17487/RFC7228"/>
            <seriesInfo name="RFC" value="7228"/>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <author initials="M." surname="Ersue" fullname="M. Ersue">
              <organization/>
            </author>
            <author initials="A." surname="Keranen" fullname="A. Keranen">
              <organization/>
            </author>
            <date year="2014" month="May"/>
            <abstract>
              <t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
          <front>
            <title>Pervasive Monitoring Is an Attack</title>
            <seriesInfo name="DOI" value="10.17487/RFC7258"/>
            <seriesInfo name="RFC" value="7258"/>
            <seriesInfo name="BCP" value="188"/>
            <author initials="S." surname="Farrell" fullname="S. Farrell">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <date year="2014" month="May"/>
            <abstract>
              <t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5785" target="https://www.rfc-editor.org/info/rfc5785" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5785.xml">
          <front>
            <title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5785"/>
            <seriesInfo name="RFC" value="5785"/>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham">
              <organization/>
            </author>
            <author initials="E." surname="Hammer-Lahav" fullname="E. Hammer-Lahav">
              <organization/>
            </author>
            <date year="2010" month="April"/>
            <abstract>
              <t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC2663" target="https://www.rfc-editor.org/info/rfc2663" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml">
          <front>
            <title>IP Network Address Translator (NAT) Terminology and Considerations</title>
            <seriesInfo name="DOI" value="10.17487/RFC2663"/>
            <seriesInfo name="RFC" value="2663"/>
            <author initials="P." surname="Srisuresh" fullname="P. Srisuresh">
              <organization/>
            </author>
            <author initials="M." surname="Holdrege" fullname="M. Holdrege">
              <organization/>
            </author>
            <date year="1999" month="August"/>
            <abstract>
              <t>This document attempts to describe the operation of NAT devices and the associated considerations in general, Identity
	  </title>
          <author>
            <organization>IEEE</organization>
          </author>
        </front>
	<refcontent>IEEE 802.1AR</refcontent>
      </reference>

        <reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">
          <front>
            <title>Architectural Styles and to define the terminology used to identify various flavors Design of NAT.  This memo provides information for the Internet community.</t>
            </abstract> Network-based Software Architectures</title>
            <author initials="R.F." surname="Fielding" fullname="Roy Fielding">
              <organization>University of California, Irvine</organization>
            </author>
            <date year="2000"/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6961.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>

<!-- [I-D.ietf-anima-reference-model-10] part of C325 -->
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6960" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"> anchor='RFC8993' target='https://www.rfc-editor.org/info/rfc8993'>
<front>
            <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
            <seriesInfo name="DOI" value="10.17487/RFC6960"/>
            <seriesInfo name="RFC" value="6960"/>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization/>
            </author>
<title>A Reference Model for Autonomic Networking</title>
<author initials="M." surname="Myers" fullname="M. Myers">
              <organization/> initials='M' surname='Behringer' fullname='Michael Behringer' role='editor'>
    <organization />
</author>
<author initials="R." surname="Ankney" fullname="R. Ankney">
              <organization/> initials='B' surname='Carpenter' fullname='Brian Carpenter'>
    <organization />
</author>
<author initials="A." surname="Malpani" fullname="A. Malpani">
              <organization/> initials='T' surname='Eckert' fullname='Toerless Eckert'>
    <organization />
</author>
<author initials="S." surname="Galperin" fullname="S. Galperin">
              <organization/> initials='L' surname='Ciavaglia' fullname='Laurent Ciavaglia'>
    <organization />
</author>
<author initials="C." surname="Adams" fullname="C. Adams">
              <organization/> initials='J' surname='Nobre' fullname='Jeferson Nobre'>
    <organization />
</author>
<date year="2013" month="June"/>
            <abstract>
              <t>This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents.  This document obsoletes RFCs 2560 and 6277.  It also updates RFC 5912.</t>
            </abstract> month='May' year='2021' />
</front>
        </reference>
        <reference anchor="RFC6961" target="https://www.rfc-editor.org/info/rfc6961" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6961.xml">
          <front>
            <title>The Transport Layer Security (TLS) Multiple Certificate Status Request Extension</title>
<seriesInfo name="DOI" value="10.17487/RFC6961"/>
            <seriesInfo name="RFC" value="6961"/>
            <author initials="Y." surname="Pettersen" fullname="Y. Pettersen">
              <organization/>
            </author>
            <date year="2013" month="June"/>
            <abstract>
              <t>This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods.  (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".)  Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.</t>
            </abstract>
          </front> name='RFC' value='8993' />
<seriesInfo name='DOI' value='10.17487/RFC8993' />
</reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
          <front>
            <title>YANG Tree Diagrams</title>
            <seriesInfo name="DOI" value="10.17487/RFC8340"/>
            <seriesInfo name="RFC" value="8340"/>
            <seriesInfo name="BCP" value="215"/>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              <organization/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t>This document captures the current syntax used

<!-- [I-D.ietf-ace-coap-est] in YANG module tree diagrams.  The purpose MISSREF state as of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on 2021-05-07 -->
<!--Note that the evolution of output was wrong and needed to format it the YANG language.</t>
            </abstract>
          </front>
        </reference> long way.
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ace-coap-est.xml"/>-->
<reference anchor="I-D.ietf-ace-coap-est" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ace-coap-est.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-ace-coap-est-18.txt"> anchor="I-D.ietf-ace-coap-est">
   <front>
      <title>EST over secure CoAP (EST-coaps)</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18"/>
     <author initials="P" surname="Stok" surname="van der Stok" fullname="Peter van der Stok">
              <organization/>
	 <organization>Consultant</organization>
      </author>
      <author initials="P" surname="Kampanakis" fullname="Panos Kampanakis">
              <organization/>
	 <organization>Cisco Systems</organization>
      </author>
      <author initials="M" surname="Richardson" fullname="Michael Richardson">
              <organization/>
	 <organization>Sandelman Software Works</organization>
      </author>
      <author initials="S" surname="Raza" fullname="Shahid Raza">
              <organization/>
	 <organization>RISE SICS</organization>
      </author>
      <date month="January" day="6" year="2020"/>
            <abstract>
              <t>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS.  Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges.  This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t>
            </abstract> year="2020" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18" />
</reference>

<!-- not referenced anymore: <?rfc
           include="reference.I-D.ietf-anima-stable-connectivity" ?> [I-D.richardson-anima-state-for-joinrouter] Expired as of 2021-05-07 -->
<!---Note that the output was wrong and needed to format it the long way.
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.richardson-anima-state-for-joinrouter.xml"/>-->
<reference anchor="I-D.richardson-anima-state-for-joinrouter" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.richardson-anima-state-for-joinrouter.xml" target="http://www.ietf.org/internet-drafts/draft-richardson-anima-state-for-joinrouter-02.txt"> anchor="I-D.richardson-anima-state-for-joinrouter">
   <front>
      <title>Considerations for stateful vs stateless join router in ANIMA bootstrap</title>
            <seriesInfo name="Internet-Draft" value="draft-richardson-anima-state-for-joinrouter-02"/>
            <author initials="M" surname="Richardson" fullname="Michael Richardson">
              <organization/>
            </author>
            <date month="January" day="25" year="2018"/>
            <abstract>
              <t>This document explores a number of issues affecting the decision to use a stateful or stateless forwarding mechanism by the join router (aka join assistant) during the bootstrap process for ANIMA.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-anima-constrained-voucher" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-constrained-voucher-08.txt">
          <front>
            <title>Constrained Voucher Artifacts for Bootstrapping Protocols</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-08"/>
      <author initials="M" surname="Richardson" fullname="Michael Richardson">
              <organization/>
            </author>
            <author initials="P" surname="Stok" fullname="Peter van der Stok">
              <organization/>
            </author>
            <author initials="P" surname="Kampanakis" fullname="Panos Kampanakis">
              <organization/>
            </author>
            <date month="July" day="13" year="2020"/>
            <abstract>
              <t>This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer.  This artifact is known as a "voucher".  This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR.  Use with two signature technologies are described.  Additionally, this document explains how constrained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-est] protocol.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-netconf-keystore" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-keystore.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-netconf-keystore-19.txt">
          <front>
            <title>A YANG Data Model for a Keystore</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-keystore-19"/>
            <author initials="K" surname="Watsen" fullname="Kent Watsen">
              <organization/>
	 <organization>Sandelman Software Works</organization>
      </author>
      <date month="July" day="10" year="2020"/> month="September" day="22" year="2020" />
      <abstract>
              <t>This
	 <t>   This document defines explores a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys.  The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates.  Notifications are sent when certificates are about to expire.  Editorial Note (To be removed by RFC Editor)  This draft contains placeholder values that need to be replaced with finalized values at the time of publication.  This note summarizes all number of issues affecting the substitutions that are needed.  No other RFC Editor instructions are specified elsewhere in this document.  Artwork in this document contains shorthand references decision to drafts in progress.  Please apply the following replacements:  *  "AAAA" --&gt;
   use a stateful or stateless forwarding mechanism by the assigned RFC value for draft-ietf-netconf-crypto- types  *  "CCCC" --&gt; join router
   (aka join assistant) during the assigned RFC value for this draft  Artwork in this document contains placeholder values bootstrap process for the date of publication ANIMA.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-richardson-anima-state-for-joinrouter-03" />
</reference>

<!-- [I-D.ietf-anima-constrained-voucher] Active: IESG state I-D Exists as of this draft.  Please apply the following replacement:  *  "2020-07-10" --&gt; 2021-05-07 -->
<!---Note that the publication date of this draft  The following Appendix section is to be removed prior output was wrong and needed to publication:  *  Appendix A.  Change Log</t>
            </abstract> format it the long way.
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml"/>-->
<reference anchor="I-D.ietf-anima-constrained-voucher">
   <front>
      <title>Constrained Voucher Artifacts for Bootstrapping Protocols</title>
      <author fullname="Michael Richardson">
	 <organization>Sandelman Software Works</organization>
      </author>
      <author initials="P" surname="van der Stok" fullname="Peter van der Stok">
	 <organization>vanderstok consultancy</organization>
      </author>
      <author fullname="Panos Kampanakis">
	 <organization>Cisco Systems</organization>
      </author>
      <author fullname="Esko Dijk">
	 <organization>IoTconsultancy.nl</organization>
      </author>
      <date month="February" day="21" year="2021" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-10" />
</reference>

<!-- not referenced anywhere: <?rfc include="reference.RFC.8572" ?> [I-D.ietf-netconf-keystore] Active: IESG state I-D Exists as of 2021-05-07 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-keystore.xml"/>

      <reference anchor="W3C.WD-capability-urls-20140218" target="http://www.w3.org/TR/2014/WD-capability-urls-20140218" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.WD-capability-urls-20140218.xml"> anchor="W3C.capability-urls" target="https://www.w3.org/TR/2014/WD-capability-urls">
          <front>
            <title>Good Practices for Capability URLs</title>
            <seriesInfo name="World Wide Web Consortium WD" value="WD-capability-urls-20140218"/>
            <author initials="J." surname="Tennison" fullname="Jeni Tennison">
              <organization/>
            </author>
            <date month="February" day="18" year="2014"/>
          </front>
        </reference>
        <reference anchor="RFC5209" target="https://www.rfc-editor.org/info/rfc5209" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5209.xml">
          <front>
            <title>Network Endpoint Assessment (NEA): Overview and Requirements</title>
            <seriesInfo name="DOI" value="10.17487/RFC5209"/>
            <seriesInfo name="RFC" value="5209"/>
            <author initials="P." surname="Sangster" fullname="P. Sangster">
              <organization/>
            </author>
            <author initials="H." surname="Khosravi" fullname="H. Khosravi">
              <organization/>
            </author>
            <author initials="M." surname="Mani" fullname="M. Mani">
              <organization/>
            </author>
            <author initials="K." surname="Narayan" fullname="K. Narayan">
              <organization/>
            </author>
            <author initials="J." surname="Tardo" fullname="J. Tardo">
              <organization/>
            </author>
            <date year="2008" month="June"/>
            <abstract>
              <t>This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model.  NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system.  This may take place during the request for network access and/or subsequently at any time while connected to the network.  The learned posture information can then be applied to a variety of compliance-oriented decisions.  The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software.  In order to provide context for the requirements, a reference model and terminology are introduced.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
	  <refcontent>W3C First Public Working Draft</refcontent>
        </reference>

        <reference anchor="docsisroot" target="https://www.cablelabs.com/resources/digital-certificate-issuance-service/">
          <front>
            <title>CableLabs Digital Certificate Issuance Service</title>
            <author surname="CableLabs"/>
            <date month="February" year="2018"/>
          </front>
        </reference>

        <reference anchor="slowloris" target="https://en.wikipedia.org/wiki/Slowloris_(computer_security)/"> target="https://en.wikipedia.org/w/index.php?title=Slowloris_(computer_security)&amp;oldid=1001473290/">
          <front>
            <title>Slowloris (computer security)</title>
            <author surname="Wikipedia"/>
            <author><organization>Wikipedia</organization></author>
            <date month="February" year="2019"/> month="January" year="2021"/>
          </front>
        </reference>

        <reference anchor="openssl" target="https://www.openssl.org/docs/man1.1.1/man1/openssl-x509.html/">
          <front>
            <title>OpenSSL X509 utility</title>
            <author surname="Openssl"/> Utility</title>
            <author><organization>OpenSSL</organization></author>
            <date month="September" year="2019"/>
          </front>
        </reference>

        <reference anchor="TR069" target="https://www.broadband-forum.org/standards-and-software/technical-specifications/tr-069-files-tools"> target="https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf">
          <front>
            <title>TR-69: CPE
            <title>CPE WAN Management Protocol</title>
            <author surname="Broadband Forum"/>
            <author><organization>Broadband Forum</organization></author>
            <date month="February" month="March" year="2018"/>
          </front>
	  <refcontent>TR-069, Issue 1, Amendment 6</refcontent>
        </reference>

        <reference anchor="imprinting" target="https://en.wikipedia.org/wiki/Imprinting_(psychology)"> target="https://en.wikipedia.org/w/index.php?title=Imprinting_(psychology)&amp;=999211441">
          <front>
            <title>Wikipedia article: Imprinting</title>
            <author surname="Wikipedia"/>
            <title>Imprinting (psychology)</title>
            <author><organization>Wikipedia</organization></author>
            <date month="July" year="2015"/> month="January" year="2021"/>
          </front>
        </reference>

        <reference anchor="softwareescrow" target="https://en.wikipedia.org/wiki/Source_code_escrow"> target="https://en.wikipedia.org/w/index.php?title=Source_code_escrow)&amp;oldid=948073074">
          <front>
            <title>Wikipedia article: Software Escrow</title>
            <author surname="Wikipedia"/>
            <title>Source code escrow</title>
            <author><organization>Wikipedia</organization></author>
            <date month="October" year="2019"/> month="March" year="2020"/>
          </front>
        </reference>

        <reference anchor="IoTstrangeThings" target="https://www.welivesecurity.com/2017/03/03/internet-of-things-security-privacy-iot-update/">
          <front>
            <title>IoT of toys stranger than fiction: Cybersecurity and data
          privacy update (accessed 2018-12-02)</title>
            <author surname="Internet"/> update</title>
            <author><organization>ESET</organization></author>
            <date month="March" year="2017"/>
          </front>
        </reference>

        <reference anchor="livingwithIoT" target="https://www.siliconrepublic.com/machines/iot-smart-devices-reality">
          <front>
            <title>What is it actually like to live in a house filled with IoT
          devices? (accessed 2018-12-02)</title>
            <author surname="Internet"/>
          devices?</title>
             <author><organization>Silicon Republic</organization></author>
            <date month="February" year="2018"/>
          </front>
        </reference>

        <reference anchor="brewski" target="https://www.urbandictionary.com/define.php?term=brewski">
          <front>
            <title>Urban Dictionary: Brewski</title>
            <author surname="Internet"/>
            <title>brewski</title>
             <author><organization>Urban Dictionary</organization></author>
            <date month="October" year="2019"/> month="March" year="2003"/>
          </front>
        </reference>

        <reference anchor="cabforumaudit" target="https://cabforum.org/information-for-auditors-and-assessors/">
          <front>
            <title>Information for Auditors and Assessors</title>
            <author surname="CA/Browser Forum"/>
            <author><organization>CA/Browser Forum</organization></author>
            <date month="August" year="2019"/>
          </front>
        </reference>

        <reference anchor="dnssecroot" target="https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf"> target="https://www.iana.org/dnssec/procedures/zsk-operator/dps-zsk-operator-v2.1.pdf">
          <front>
            <title>DNSSEC Practice Statement for the Root Zone ZSK Operator</title>
            <author surname="Verisign"/>
            <date month="December" year="2017"/>
          </front>
        </reference>

        <reference anchor="Stajano99theresurrecting" target="https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf">
          <front>
            <title>The resurrecting duckling: security issues Resurrecting Duckling: Security Issues for ad-hoc
          wireless networks</title> Ad-hoc
          Wireless Networks</title>
            <author fullname="Frank Stajano" initials="F." surname="Stajano"/>
            <author fullname="Ross Anderson" initials="R." surname="Anderson"/>
            <date year="1999"/>
          </front>
        </reference>

        <reference anchor="minerva" target="https://minerva.sandelman.ca/">
          <front>
            <title>Minerva reference implementation for BRSKI</title>
            <author fullname="Michael Richardson" initials="M." surname="Richardsdon"/> surname="Richardson"/>
            <date year="2020"/>
          </front>
        </reference>

        <reference anchor="minervagithub" target="https://github.com/ANIMAgus-minerva">
          <front>
            <title>GITHUB hosting of
            <title>ANIMA Minerva reference code</title>
            <author fullname="Michael Richardson" initials="M." surname="Richardsdon"/>
            <date year="2020"/> toolkit</title>
            <author/>
            <date/>
          </front>
        </reference>

        <reference anchor="Dingledine2004" target="https://spec.torproject.org/tor-spec"> anchor="Dingledine" target="https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.pdf">
          <front>
            <title>Tor: the second-generation onion router</title> The Second-Generation Onion Router</title>
            <author initials="R." surname="Dingledine">
              <organization/>
            </author>
            <author initials="N." surname="Mathewson">
              <organization/>
            </author>
            <author initials="P." surname="Syverson">
              <organization/>
            </author>
            <date month="August" year="2004"/>
          </front>
        </reference>
      </references>
</references>

    <section anchor="IPv4operations" numbered="true" toc="default">
      <name>IPv4 and non-ANI operations</name> Non-ANI Operations</name>
      <t>
        The specification of BRSKI in <xref target="proxydetails" format="default"/>
        intentionally only covers only the mechanisms for an IPv6 pledge using
        Link-Local
        link-local addresses.  This section describes non-normative
        extensions that can be used in other environments.
      </t>
      <section numbered="true" toc="default">
        <name>IPv4 Link Local addresses</name> Link-Local Addresses</name>
        <t>Instead of an IPv6 link-local address, an IPv4 address may be
      generated using <xref target="RFC3927" format="default"/>  Dynamic "Dynamic Configuration of
      IPv4 Link-Local Addresses. Addresses" <xref target="RFC3927" format="default"/>.
        </t>
        <t> In the case that where an IPv4 Link-Local link-local address is formed, then the
      bootstrap process would continue continue, as in the an IPv6 case case, by looking for
      a (circuit) proxy.
        </t>
      </section>
      <section anchor="IPv4dhcp" numbered="true" toc="default">
        <name>Use of DHCPv4</name>
        <t>
        The Pledge MAY pledge <bcp14>MAY</bcp14> obtain an IP address via
        DHCP [RFC2131]. (<xref target="RFC2131" format="default"/>. The DHCP provided DHCP-provided parameters for the Domain Name
        System can be used to perform DNS operations if all
        local discovery attempts fail.
        </t>
      </section>
    </section>
    <section anchor="mdnsmethods" numbered="true" toc="default">
      <name>mDNS / DNSSD proxy discovery options</name> DNS-SD Proxy Discovery Options</name>
      <t>Pledge discovery of the proxy (<xref target="discovery" format="default"/>) MAY <bcp14>MAY</bcp14> be performed with DNS-based Service Discovery <xref target="RFC6763" format="default"/> over Multicast DNS <xref target="RFC6762" format="default"/> to discover the proxy at
      "_brski-proxy._tcp.local.". </t>
      <t>Proxy discovery of the registrar (<xref target="JRCgrasp" format="default"/>) MAY <bcp14>MAY</bcp14> be performed with DNS-based Service Discovery over Multicast DNS to discover registrars by searching for the service
        "_brski-registrar._tcp.local.".</t>
      <t>
        To prevent unaccceptable unacceptable levels of
        network traffic, when using mDNS, the congestion avoidance mechanisms
        specified in
        <xref target="RFC6762" format="default"/> section 7 MUST sectionFormat="comma" section="7"/> <bcp14>MUST</bcp14> be followed. The
        pledge SHOULD <bcp14>SHOULD</bcp14> listen for an unsolicited broadcast response as
        described in <xref target="RFC6762" format="default"/>. This allows devices
        to avoid announcing their presence via mDNS broadcasts and
        instead silently join a network by watching for periodic
        unsolicited broadcast responses.
      </t>
      <t>
        Discovery of the registrar MAY <bcp14>MAY</bcp14> also be performed with DNS-based
        service discovery
        Service Discovery by searching for the service "_brski-registrar._tcp.example.com".
        In this case case, the domain
        "example.com" is discovered as described in <xref target="RFC6763" format="default"/> section 11
sectionFormat="comma" section="11"/> (<xref target="IPv4dhcp" format="default"/> of this document
        suggests the use of DHCP parameters).
      </t>
      <t>
        If no local proxy or registrar service is located using the GRASP
        mechanisms or the above mentioned above-mentioned DNS-based Service Discovery
        methods, the pledge MAY <bcp14>MAY</bcp14> contact a well
        known manufacturer provided well-known
        manufacturer-provided bootstrapping server by performing a DNS
        lookup using a well known 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 <xref target="cloudregistrar" format="default"/>.
      </t>
      <t>
        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 work, then the second and third responses are tried.
          If these fail fail, the pledge moves on to normal DNS-based Service
          Discovery.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Example Vouchers</name>
      <t>
        Three entities are involved in a voucher: the MASA issues (signs)
        it, the registrar's public key is mentioned in the voucher, it, and the
        pledge validates it.  In order to provide reproduceable examples reproducible examples,
        the public and private keys for an example MASA and registrar are
        first listed.
        listed first.
      </t>
      <t>
        The keys come from an open source reference implementation of BRSKI,
        called "Minerva" <xref target="minerva" format="default"/>.
        It is available on github GitHub <xref target="minervagithub" format="default"/>.
        The keys presented here are used in the unit and integration tests.
        The MASA code is called "highway", the Registrar registrar code is called
        "fountain", and the example client is called "reach".
      </t>
      <t>
        The public key components of each are presented as both base64
        certificates, as well as being
        certificates and are decoded by openssl's x509
        utility so that the extensions can be seen.  This was version
        1.1.1c of the <xref target="openssl" format="default"/> library and utility. utility of <xref target="openssl" format="default"/>.
      </t>
      <section numbered="true" toc="default">
        <name>Keys involved</name> Involved</name>
        <t>
          The Manufacturer manufacturer has a Certificate Authority CA that signs the
          pledge's IDevID.  In addition 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.
        </t>
        <section numbered="true" toc="default">
          <name>Manufacturer Certificate Certification Authority for IDevID signatures</name> Signatures</name>
          <t>
            This private key is Certificate Authority the CA that signs IDevID certificates:
          </t>
          <sourcecode name="vendor.key" type="" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G
8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
juF8QkoAbT8pMrY83MS8y76wZ7AalNQ=
-----END EC PRIVATE KEY-----
]]></sourcecode>
          <t>
            This public key validates IDevID certificates:
          </t>

          <t keepWithPrevious="true">file: examples/vendor.key</t>
          <sourcecode name="vendor.cert" type="" type="example-crypto-material" markers="true"><![CDATA[
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 519772114 (0x1efb17d2) 1216069925 (0x487bc125)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA
        Validity
            Not Before: Feb 12 22:22:21 2019 Apr 13 20:34:24 2021 GMT
            Not After : Feb 11 22:22:21 2021 Apr 13 20:34:24 2023 GMT
        Subject: C = Canada, ST = Ontario, OU = Sandelman, 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
                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
                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:65:02:30:5f:21:fd:c6:ab:d6:94:a6:cd:ca:37:2c:81:33:
         87:fe:7b:e1:b5:1a:e8:6c:05:43:a6:8b:4e:22:b5:55:e9:48:
         0c:b5:97:f3:c9:1a:65:d9:97:4b:f0:21:86:0d:cb:26:02:31:
         00:e3:2d:0d:08:49:4d:a3:f5:dc:57:1f:a7:13:26:a4:e0:d6:
         3a:c2:d5:4a:50:83:62:26:2e:79:2b:d0:a5:ee:66:d5:bf:16:
         9a:33:75:b4:d1:8d:ba:d3:50:77:6b:92:df
         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-----
MIICTDCCAdKgAwIBAgIEHvsX0jAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjIyMVoX
DTIxMDIxMTIyMjIyMVowXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh
cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l
eGFtcGxlLmNvbSBDQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABC7n/KS0lsUuMwLz
uHtv7JOt4W4XwbB7AocviZLSvR1UBC5uoNRBxOuO+letcKlOiOIsLOCnx/ORxQOR
n0sP8z3QsOKmIs0g6Q+O4XxCSgBtPykytjzcxLzLvrBnsBqU1KNjMGEwDwYDVR0T
AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFF4MqVJajN+pDwMU
6ZbxgHaMU4oIMB8GA1UdIwQYMBaAFF4MqVJajN+pDwMU6ZbxgHaMU4oIMAoGCCqG
SM49BAMCA2gAMGUCMF8h/car1pSmzco3LIEzh/574bUa6GwFQ6aLTiK1VelIDLWX
88kaZdmXS/Ahhg3LJgIxAOMtDQhJTaP13FcfpxMmpODWOsLVSlCDYiYueSvQpe5m
1b8WmjN1tNGNutNQd2uS3w==
MIIB3TCCAWSgAwIBAgIESHvBJTAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo
d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjAzNDI0WhcNMjMwNDEz
MjAzNDI0WjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0Ew
djAQBgcqhkjOPQIBBgUrgQQAIgNiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
juF8QkoAbT8pMrY83MS8y76wZ7AalNSjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYD
VR0PAQH/BAQDAgEGMB0GA1UdDgQWBBReDKlSWozfqQ8DFOmW8YB2jFOKCDAfBgNV
HSMEGDAWgBReDKlSWozfqQ8DFOmW8YB2jFOKCDAKBggqhkjOPQQDAgNnADBkAjBg
N6BmiYAn4Q3lQ5pi8QK8D3JtqenLhKXGRNNBnl3OfUYWbhXe98zoPmH5A3wgxLcC
MH/p8xK7BsYkACtBqiFr2CXtgQcR72aPBr/IvvBYdCRFOU0E/DFpb8/b/mF7wyQx
/w==
-----END CERTIFICATE-----

]]></sourcecode>
        </section>
        <section numbered="true" toc="default">
          <name>MASA key pair Key Pair for voucher signatures</name> Voucher Signatures</name>
          <t>
            The MASA is the Manufacturer Authorized Signing Authority.  This
            keypair
            key pair signs vouchers.  An example TLS certificate (see <xref target="brskimasatls" format="default"/> format="default"/>)
            HTTP authentication is not provided as it is a
            common form.
          </t>
          <t>
            This private key signs the vouchers which that are presented below:
          </t>
          <sourcecode name="masa.key" type="" type="example-crypto-material" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49
AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+
gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ==
-----END EC PRIVATE KEY-----
]]></sourcecode>
          <t>
            This public key validates vouchers, and it has been signed by the
            CA above:
          </t>
          <t keepWithPrevious="true">file: examples/masa.key</t>
          <sourcecode name="masa.cert" type="" type="example-crypto-material" markers="true"><![CDATA[
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 463036244 (0x1b995f54) 193399345 (0xb870a31)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA
        Validity
            Not Before: Feb 12 22:22:41 2019 Apr 13 21:40:16 2021 GMT
            Not After : Feb 11 22:22:41 2021 Apr 13 21:40:16 2023 GMT
        Subject: C = Canada, ST = Ontario, OU = Sandelman, 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:bd:55:e5:9b:0e:fb:fc:5e:95:29:e3:81:b3:
         15:35:aa:93:18:a2:04:be:44:72:b2:51:7d:4d:6d:eb:d1:d5:
         c1:10:3a:b2:39:7b:57:3f:c5:cc:b0:a3:0e:e7:99:46:ba:02:
         31:00:f6:7f:44:7d:b7:14:fa:d1:67:6a:d4:11:c3:4b:ae:e6:
         fb:9a:98:56:fa:85:21:2e:5c:48:4c:f0:3f:f2:9b:3f:ae:88:
         20:a7:ae:f9:72:ff:5b:f9:78:68:cf:0f:48:c9
         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-----
MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX
DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh
cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l
eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5
4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf
WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA
vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6
AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP
D0jJ
MIIBcDCB9qADAgECAgQLhwoxMAoGCCqGSM49BAMCMCYxJDAiBgNVBAMMG2hpZ2h3
YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0yMTA0MTMyMTQwMTZaFw0yMzA0MTMy
MTQwMTZaMCgxJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBNQVNB
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S54kT4yfkbBxumdHOcHrps
qbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpaMQMA4w
DAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEArsthLdRcjW6GqgsGHcbT
YLoyczYl0yOFSYcczpQjeRqeQVUkHRUioUi7CsCrPBNzAjEAhjxns5Wi4uX5rfkd
nME0Mnj1z+rVRwOfAL/QWctRwpgEgSSKURNQsXWyL52otPS5
-----END CERTIFICATE-----
]]></sourcecode>
        </section>
        <section numbered="true" toc="default">
          <name>Registrar Certificate Certification Authority</name>
          <t>
            This Certificate Authority CA enrolls the pledge once it is
            authorized, and it also signs the Registrar's registrar's certificate.
          </t>
          <sourcecode name="ownerca_secp384r1.key" type="" type="example-crypto-material" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R
EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW
gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd
0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ=
-----END EC PRIVATE KEY-----
]]></sourcecode>
          <t>
            The public key is indicated in a pledge voucher-request to show proximity.
          </t>
          <t keepWithPrevious="true">file: examples/ownerca_secp384r1.key</t>
          <sourcecode name="ownerca_secp384r1.cert" type="" type="example-crypto-material" markers="true"><![CDATA[
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
                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
                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-----
]]></sourcecode>
        </section>
        <section numbered="true" toc="default">
          <name>Registrar key pair</name> Key Pair</name>
          <t>
            The Registrar registrar is the representative of the domain owner.
            This key signs registrar voucher-requests, voucher-requests and terminates
            the TLS connection from the pledge.
          </t>
          <sourcecode name="jrc_prime256v1.key" type="" type="example-crypto-material" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49
AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E
jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg==
-----END EC PRIVATE KEY-----
]]></sourcecode>
          <t>
            The public key is indicated in a pledge voucher-request to show proximity.
          </t>
          <sourcecode name="jrc_prime256v1.cert" type="" type="example-crypto-material" markers="true"><![CDATA[
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-----
]]></sourcecode>
        </section>
        <section numbered="true" toc="default">
          <name>Pledge key pair</name> Key Pair</name>
          <t>
            The pledge has an IDevID key pair built in at manufacturing time:
          </t>
          <sourcecode name="idevid_00-D0-E5-F2-00-02.key" type="" type="example-crypto-material" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49
AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx
FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw==
-----END EC PRIVATE KEY-----
]]></sourcecode>
          <t>
            The certificate is used by the registrar to find the MASA.
          </t>
          <sourcecode name="idevid_00-D0-E5-F2-00-02.cert" type="" type="example-crypto-material" markers="true"><![CDATA[
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 226876461 (0xd85dc2d) 521731815 (0x1f18fee7)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA
        Validity
            Not Before: Feb  3 06:47:20 2020 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
                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:23:e1:a9:2e:ef:22:12:34:5a:a5:c2:15:d6:28:
         bd:ed:3d:96:d6:ce:04:95:ef:a7:c8:dc:18:a8:31:c7:b8:04:
         34:f2:b7:4d:79:8a:67:22:24:03:4f:c5:cd:d6:06:ba:02:31:
         00:b3:8d:5c:0a:d0:fe:04:83:90:d3:4f:6d:72:97:b3:3e:02:
         ea:f1:c8:5a:32:72:58:b7:45:02:50:78:bc:04:1d:23:5e:22:
         6f:c3:7f:8c:7c:d7:9b:70:20:91:b4:e1:7f
         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-----
MIIB5jCCAWygAwIBAgIEDYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoY
DzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZ
MBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/g
QE5BefBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0G
A1UdDgQWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUF
BwEgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMC
A2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TXmKZyIk
A0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vAQdI14ib8N/
jHzXm3AgkbThfw==
MIIBrzCCATWgAwIBAgIEHxj+5zAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo
d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwIBcNMjEwNDI3MTgyOTMwWhgPMjk5OTEy
MzEwMDAwMDBaMBwxGjAYBgNVBAUTETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsT
SyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYE
FEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYd
aGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDaAAwZQIw
YirbvjT3G8uF3iaOQwD5DYjId6jdPAhAVLzsPbbccCvDf8oZIZqgq8VRjqrfNt6L
AjEAsl1Z+EfH7QOXqMDHqIH6qIbtZ2Q3UXpunKOCTW2tvPM1np1qom1/fyUcA+/w
uptx
-----END CERTIFICATE-----

]]></sourcecode>
        </section>
      </section>
      <section anchor="exampleprocess" numbered="true" toc="default">
        <name>Example process</name> Process</name>
        <t>
          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.
        </t>
        <t>

          For readability, the output of the asn1parse has been truncated at
          72
          68 columns rather than wrapped.
        </t>
        <section numbered="true" toc="default">
          <name>Pledge to Registrar</name>
          <t>
            As described in <xref target="RequestVoucherFromRegistrar" format="default"/>,
            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.
          </t>

          <sourcecode name="vr_00-D0-E5-F2-00-02.b64" type="" markers="true"><![CDATA[
MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGg
ggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94
aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLCJzZXJp
YWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6ImFNamd1ZUtVVC0yMndWaW1q
NnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1
aWJVakFLQmdncWhrak9QUVFEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdv
SmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJs
YzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVG
dzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsv
SXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFV
RUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VH
Q0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNCYitsSW5vRU1FZ2M3Um8rWFpDdGpB
STBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0Ex
VWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtq
T1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2
WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhT
OFhBUjVrMUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIE
DYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW8xEjAQ
BgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAX
DTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0w
MC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5B
efBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDgQWBBRFiMyW
lgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBwEgBB8MHWhpZ2h3YXktdGVzdC5l
eGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXv
p8jcGKgxx7gENPK3TXmKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4
vAQdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYD
VQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l
eGFtcGxlLmNvbSBDQQIEDYXcLTALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6IrwstHF
609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIBxwA1UlkIkuQDf/j7kZ
/MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bmiEUpefCEhxSv2xLYurGlugv0dfr/E=
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=
]]></sourcecode>

          <t>
            The ASN1 decoding of the artifact:
          </t>
          <t keepWithPrevious="true">file: examples/vr_00-D0-E5-F2-00-02.b64</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    0:d=0  hl=4 l=1759 l=1648 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
   15:d=1  hl=4 l=1744 l=1633 cons: cont [ 0 ]
   19:d=2  hl=4 l=1740 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= 490 434 cons: cont [ 0 ]
  954:d=4  hl=4 l= 486 430 cons: SEQUENCE
  958:d=5  hl=4 l= 364 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           :0D85DC2D           :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=  93  38 cons: SEQUENCE
  987:d=7  hl=2 l=  15 cons: SET
  989:d=8  hl=2 l=  13 cons: SEQUENCE
  991:d=9  hl=2 l=   3 prim: OBJECT            :countryName
  996:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
 1004:d=7  hl=2 l=  16 cons: SET
 1006:d=8  hl=2 l=  14 cons: SEQUENCE
 1008:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
 1013:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
 1022:d=7  hl=2 l=  18 cons: SET
 1024:d=8  hl=2 l=  16 cons: SEQUENCE
 1026:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
 1031:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
 1042:d=7  hl=2 l=  36 cons: SET
 1044:d=8
  989:d=8  hl=2 l=  34 cons: SEQUENCE
 1046:d=9
  991:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1051:d=9
  996:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
 1080:d=6
 1025:d=6  hl=2 l=  32 cons: SEQUENCE
 1082:d=7
 1027:d=7  hl=2 l=  13 prim: UTCTIME           :200203064720Z
 1097:d=7           :210413203739Z
 1042:d=7  hl=2 l=  15 prim: GENERALIZEDTIME   :29991231000000Z
 1114:d=6
 1059:d=6  hl=2 l=  28 cons: SEQUENCE
 1116:d=7
 1061:d=7  hl=2 l=  26 cons: SET
 1118:d=8
 1063:d=8  hl=2 l=  24 cons: SEQUENCE
 1120:d=9
 1065:d=9  hl=2 l=   3 prim: OBJECT            :serialNumber
 1125:d=9
 1070:d=9  hl=2 l=  17 prim: UTF8STRING        :00-D0-E5-F2-00-02
 1144:d=6
 1089:d=6  hl=2 l=  89 cons: SEQUENCE
 1146:d=7
 1091:d=7  hl=2 l=  19 cons: SEQUENCE
 1148:d=8
 1093:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
 1157:d=8
 1102:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
 1167:d=7
 1112:d=7  hl=2 l=  66 prim: BIT STRING
 1235:d=6
 1180:d=6  hl=2 l=  89 cons: cont [ 3 ]
 1237:d=7
 1182:d=7  hl=2 l=  87 cons: SEQUENCE
 1239:d=8
 1184:d=8  hl=2 l=  29 cons: SEQUENCE
 1241:d=9
 1186:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Ident
 1246:d=9
 1191:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:04144588CC9696
 1270:d=8
 1215:d=8  hl=2 l=   9 cons: SEQUENCE
 1272:d=9
 1217:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 1277:d=9
 1222:d=9  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
 1281:d=8
 1226:d=8  hl=2 l=  43 cons: SEQUENCE
 1283:d=9
 1228:d=9  hl=2 l=   8 prim: OBJECT            :1.3.6.1.5.5.7.1.32
 1293:d=9
 1238:d=9  hl=2 l=  31 prim: OCTET STRING      [HEX DUMP]:0C1D6869676877
 1326:d=5 DUMP]:161D6869676877
 1271:d=5  hl=2 l=  10 cons: SEQUENCE
 1328:d=6
 1273:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 1338:d=5
 1283:d=5  hl=2 l= 104 103 prim: BIT STRING
 1444:d=3
 1388:d=3  hl=4 l= 315 260 cons: SET
 1448:d=4
 1392:d=4  hl=4 l= 311 256 cons: SEQUENCE
 1452:d=5
 1396:d=5  hl=2 l=   1 prim: INTEGER           :01
 1455:d=5  hl=2 l= 101 cons: SEQUENCE
 1457:d=6  hl=2 l=  93 cons: SEQUENCE
 1459:d=7  hl=2 l=  15 cons: SET
 1461:d=8  hl=2 l=  13 cons: SEQUENCE
 1463:d=9  hl=2 l=   3 prim: OBJECT            :countryName
 1468:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
 1476:d=7  hl=2 l=  16 cons: SET
 1478:d=8
 1399:d=5  hl=2 l=  14  46 cons: SEQUENCE
 1480:d=9
 1401:d=6  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
 1485:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
 1494:d=7  hl=2 l=  18 cons: SET
 1496:d=8  hl=2 l=  16  38 cons: SEQUENCE
 1498:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
 1503:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
 1514:d=7
 1403:d=7  hl=2 l=  36 cons: SET
 1516:d=8
 1405:d=8  hl=2 l=  34 cons: SEQUENCE
 1518:d=9
 1407:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1523:d=9
 1412:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
 1552:d=6
 1441:d=6  hl=2 l=   4 prim: INTEGER           :0D85DC2D
 1558:d=5           :0D83AFD9
 1447:d=5  hl=2 l=  11 cons: SEQUENCE
 1560:d=6
 1449:d=6  hl=2 l=   9 prim: OBJECT            :sha256
 1571:d=5
 1460:d=5  hl=2 l= 105 cons: cont [ 0 ]
 1573:d=6
 1462:d=6  hl=2 l=  24 cons: SEQUENCE
 1575:d=7
 1464:d=7  hl=2 l=   9 prim: OBJECT            :contentType
 1586:d=7
 1475:d=7  hl=2 l=  11 cons: SET
 1588:d=8
 1477:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
 1599:d=6
 1488:d=6  hl=2 l=  28 cons: SEQUENCE
 1601:d=7
 1490:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
 1612:d=7
 1501:d=7  hl=2 l=  15 cons: SET
 1614:d=8
 1503:d=8  hl=2 l=  13 prim: UTCTIME           :200225230448Z
 1629:d=6           :210413214323Z
 1518:d=6  hl=2 l=  47 cons: SEQUENCE
 1631:d=7
 1520:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
 1642:d=7
 1531:d=7  hl=2 l=  34 cons: SET
 1644:d=8
 1533:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:B1E88AF0B2D1C5
 1678:d=5 DUMP]:49C21C9889B223
 1567:d=5  hl=2 l=  10 cons: SEQUENCE
 1680:d=6
 1569:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 1690:d=5
 1579:d=5  hl=2 l=  71 prim: OCTET STRING      [HEX DUMP]:304502201C7003 DUMP]:3045022100A662

]]></artwork>
          <t>
            The JSON contained in the voucher request: voucher-request:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="json">
{"ietf-voucher-request:voucher":{"assertion":"proximity","cr
eated-on":"2020-02-25T18:04:48.652-05:00","serial-number":"0
0-D0-E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","proximit
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="}}]]></artwork>
8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}}
</sourcecode>
        </section>
        <section numbered="true" toc="default">
          <name>Registrar to MASA</name>
          <t>
            As described in <xref target="RequestVoucherFromMASA" format="default"/> format="default"/>,
            the registrar will sign a registrar voucher-request, voucher-request and will
            include the pledge's voucher request voucher-request in the prior-signed-voucher-request.
          </t>
          <sourcecode name="parboiled_vr_00-D0-E5-F2-00-02.b64" type="" markers="true"><![CDATA[
MIIP9wYJKoZIhvcNAQcCoIIP6DCCD+QCAQExDTALBglghkgBZQMEAgEwggoMBgkqhkiG9w0BBwGg
ggn9BIIJ+XsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94
aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQyMzowNDo0OS4wNTRaIiwic2VyaWFsLW51
bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdR
IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6Ik1JSUczd1lKS29aSWh2Y05BUWNDb0lJ
RzBEQ0NCc3dDQVFFeERUQUxCZ2xnaGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042
QklJRGRuc2lhV1YwWmkxMmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxj
blJwYjI0aU9pSndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNQzB3TWkweU5W
UXhPRG93TkRvME9DNDJOVEl0TURVNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0UkRB
dFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJbUZOYW1kMVpVdFZWQzB5TW5kV2FXMXFObm95
TjFFaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9pSk5TVWxDTDBSRFEwRlpT
MmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFVVkZFUVdwQ2RFMVNTWGRGUVZsTFEx
cEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZUW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhw
WlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1kT1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5S
ZFZwWWFHaGlXRUp6V2xNMWFtSXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZi
VGwyWkVOQ1JGRlVRV1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVV
MVVUWGhPVkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O
SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFURlZSVUYz
ZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9kbUpVUWxwTlFrMUhR
bmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpLV214VlNFa3dkWEF2YkRObFdt
WTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdwQlNUQkRSREZtU21aS1VpOW9TWGw1Ukcx
SVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10NloxZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JL
VVVWQ0wzZFJUVTFCYjBkRFEzTkhRVkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpT
R2RFUVV0Q1oyZHhhR3RxVDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVp
czFlVUpMVGxKVVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cx
U2Eyb3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRPRmhC
VWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJnZ2dIcU1JSUI1
akNDQVd5Z0F3SUJBZ0lFRFlYY0xUQUtCZ2dxaGtqT1BRUURBakJkTVE4d0RRWURWUVFHRXdaRFlX
NWhaR0V4RURBT0JnTlZCQWdNQjA5dWRHRnlhVzh4RWpBUUJnTlZCQXNNQ1ZOaGJtUmxiRzFoYmpF
a01DSUdBMVVFQXd3YmFHbG5hSGRoZVMxMFpYTjBMbVY0WVcxd2JHVXVZMjl0SUVOQk1DQVhEVEl3
TURJd016QTJORGN5TUZvWUR6STVPVGt4TWpNeE1EQXdNREF3V2pBY01Sb3dHQVlEVlFRRkRCRXdN
QzFFTUMxRk5TMUdNaTB3TUMwd01qQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJB
T2pkVU9IczN6QUNwcUhuSzMyOURnVEhOUU1oQi9nUUU1QmVmQmJFMHNnY2JORW0wbGk4Ull3enJz
QWZZQ3hwOWs3RTFDYnBpZWxUOE9XZjB6K0lTZWpXVEJYTUIwR0ExVWREZ1FXQkJSRmlNeVdsZ0Jr
TjdDNkkyVmtaRlFJQm14V3JUQUpCZ05WSFJNRUFqQUFNQ3NHQ0NzR0FRVUZCd0VnQkI4TUhXaHBa
MmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlRvNU5EUXpNQW9HQ0NxR1NNNDlCQU1DQTJnQU1H
VUNNQ1BocVM3dkloSTBXcVhDRmRZb3ZlMDlsdGJPQkpYdnA4amNHS2d4eDdnRU5QSzNUWG1LWnlJ
a0EwL0Z6ZFlHdWdJeEFMT05YQXJRL2dTRGtOTlBiWEtYc3o0QzZ2SElXakp5V0xkRkFsQjR2QVFk
STE0aWI4Ti9qSHpYbTNBZ2tiVGhmekdDQVRzd2dnRTNBZ0VCTUdVd1hURVBNQTBHQTFVRUJoTUdR
MkZ1WVdSaE1SQXdEZ1lEVlFRSURBZFBiblJoY21sdk1SSXdFQVlEVlFRTERBbFRZVzVrWld4dFlX
NHhKREFpQmdOVkJBTU1HMmhwWjJoM1lYa3RkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJTQkRRUUlFRFlY
Y0xUQUxCZ2xnaGtnQlpRTUVBZ0dnYVRBWUJna3Foa2lHOXcwQkNRTXhDd1lKS29aSWh2Y05BUWNC
TUJ3R0NTcUdTSWIzRFFFSkJURVBGdzB5TURBeU1qVXlNekEwTkRoYU1DOEdDU3FHU0liM0RRRUpC
REVpQkNDeDZJcndzdEhGNjA5WTBFcURLNjJRS2J5NGR1eXlJV3VkdnMxNU0xNkJCVEFLQmdncWhr
ak9QUVFEQWdSSE1FVUNJQnh3QTFVbGtJa3VRRGYvajdrWi9NVmVmZ3IxNDEraEtCRmdybk5uZ2p3
cEFpRUF5OGFYdDBHU0I5bTFibWlFVXBlZkNFaHhTdjJ4TFl1ckdsdWd2MGRmci9FPSJ9faCCBG8w
ggH8MIIBgqADAgECAgQ/mJtSMAoGCCqGSM49BAMCMG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcG
CgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNv
bSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTIwMDIyNTIxMzE1NFoXDTIyMDIyNDIxMzE1
NFowUzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYD
VQQDDBlmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
lmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0VtEIf1/Jqt+TO
BfinTNOLOqMqMCgwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAxwwDgYDVR0PAQH/BAQDAgeAMAoGCCqG
SM49BAMCA2gAMGUCMGZPYExVSB6WB/jdH7nIEo1FNoebI8C8u/HLPSYVVm9fH7/VHA5qCa8bdpeZ
GSP9fgIxALysw0Gwug2vUvmcbnp/AB0jyGIBYbxLxcBHmTUKDHdhRAFKB1JwVwB1/74HDpjL5TCC
AmswggHyoAMCAQICBClrBlkwCgYIKoZIzj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK
CZImiZPyLGQBGRYJc2FuZGVsbWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29t
IFVuc3RydW5nIEZvdW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTQ1WhcNMjIwMjI0MjEzMTQ1
WjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNV
BAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTB2
MBAGByqGSM49AgEGBSuBBAAiA2IABBt/WboXwxq8Zo2MbODD+jFxD2X2IpG9t1aAB9vfuHqlRU15
ikaXGVmWMbGPaX0yvjzIPltjtUb2qNVvm/nA89O5FD9yR1Gkdt3S8L/1yo8wAX/4wl/T9SADRIuL
8gdstKNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLml9ssR
4QekSSynCMZ8ELyHs3QmMB8GA1UdIwQYMBaAFLml9ssR4QekSSynCMZ8ELyHs3QmMAoGCCqGSM49
BAMCA2cAMGQCMCCDBs6NmKRUemZMSjpwwlI2WlKNWX0gmyppFFiHONhVed39KTiVHpGTdrT1ZilE
tAIwbzj5rxLtMNWFKXyxFli9Z5FDxA0w+dgcrC8G3bzVBkIshKIE6gKkXxdRJvvZL9JcMYIBSzCC
AUcCAQEwdTBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4x
PDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9v
dCBDQQIEP5ibUjALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMDAyMjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCA9gYxR1sS0giII3PwvOK/N
5RUBwjSL/cDcrH/Bd+E1ajAKBggqhkjOPQQDAgRHMEUCIFieXZaO7P9eZMpCVn2laB4czw7I0s0P
s9+frcJtEBTTAiEAhCcB//qmgqcEA+90mquvVNENmFH9dxCH8Ihhz6SCVDI=
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==
]]></sourcecode>
          <t>
            The ASN1 decoding of the artifact:
          </t>
          <t keepWithPrevious="true">file: examples/parboiled_vr_00_D0-E5-02-00-2D.b64</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    0:d=0  hl=4 l=4087 l=3939 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
   15:d=1  hl=4 l=4072 l=3924 cons: cont [ 0 ]
   19:d=2  hl=4 l=4068 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=2572 l=2424 cons: SEQUENCE
   45:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
   56:d=4  hl=4 l=2557 l=2409 cons: cont [ 0 ]
   60:d=5  hl=4 l=2553 l=2405 prim: OCTET STRING      :{"ietf-voucher-request:v
 2617:d=3
 2469:d=3  hl=4 l=1135 cons: cont [ 0 ]
 2621:d=4
 2473:d=4  hl=4 l= 508 cons: SEQUENCE
 2625:d=5
 2477:d=5  hl=4 l= 386 cons: SEQUENCE
 2629:d=6
 2481:d=6  hl=2 l=   3 cons: cont [ 0 ]
 2631:d=7
 2483:d=7  hl=2 l=   1 prim: INTEGER           :02
 2634:d=6
 2486:d=6  hl=2 l=   4 prim: INTEGER           :3F989B52
 2640:d=6
 2492:d=6  hl=2 l=  10 cons: SEQUENCE
 2642:d=7
 2494:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 2652:d=6
 2504:d=6  hl=2 l= 109 cons: SEQUENCE
 2654:d=7
 2506:d=7  hl=2 l=  18 cons: SET
 2656:d=8
 2508:d=8  hl=2 l=  16 cons: SEQUENCE
 2658:d=9
 2510:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 2670:d=9
 2522:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 2674:d=7
 2526:d=7  hl=2 l=  25 cons: SET
 2676:d=8
 2528:d=8  hl=2 l=  23 cons: SEQUENCE
 2678:d=9
 2530:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 2690:d=9
 2542:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 2701:d=7
 2553:d=7  hl=2 l=  60 cons: SET
 2703:d=8
 2555:d=8  hl=2 l=  58 cons: SEQUENCE
 2705:d=9
 2557:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 2710:d=9
 2562:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
 2763:d=6
 2615:d=6  hl=2 l=  30 cons: SEQUENCE
 2765:d=7
 2617:d=7  hl=2 l=  13 prim: UTCTIME           :200225213154Z
 2780:d=7
 2632:d=7  hl=2 l=  13 prim: UTCTIME           :220224213154Z
 2795:d=6
 2647:d=6  hl=2 l=  83 cons: SEQUENCE
 2797:d=7
 2649:d=7  hl=2 l=  18 cons: SET
 2799:d=8
 2651:d=8  hl=2 l=  16 cons: SEQUENCE
 2801:d=9
 2653:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 2813:d=9
 2665:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 2817:d=7
 2669:d=7  hl=2 l=  25 cons: SET
 2819:d=8
 2671:d=8  hl=2 l=  23 cons: SEQUENCE
 2821:d=9
 2673:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 2833:d=9
 2685:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 2844:d=7
 2696:d=7  hl=2 l=  34 cons: SET
 2846:d=8
 2698:d=8  hl=2 l=  32 cons: SEQUENCE
 2848:d=9
 2700:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 2853:d=9
 2705:d=9  hl=2 l=  25 prim: UTF8STRING        :fountain-test.example.co
 2880:d=6
 2732:d=6  hl=2 l=  89 cons: SEQUENCE
 2882:d=7
 2734:d=7  hl=2 l=  19 cons: SEQUENCE
 2884:d=8
 2736:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
 2893:d=8
 2745:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
 2903:d=7
 2755:d=7  hl=2 l=  66 prim: BIT STRING
 2971:d=6
 2823:d=6  hl=2 l=  42 cons: cont [ 3 ]
 2973:d=7
 2825:d=7  hl=2 l=  40 cons: SEQUENCE
 2975:d=8
 2827:d=8  hl=2 l=  22 cons: SEQUENCE
 2977:d=9
 2829:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usag
 2982:d=9
 2834:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 2985:d=9
 2837:d=9  hl=2 l=  12 prim: OCTET STRING      [HEX DUMP]:300A06082B0601
 2999:d=8
 2851:d=8  hl=2 l=  14 cons: SEQUENCE
 3001:d=9
 2853:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
 3006:d=9
 2858:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 3009:d=9
 2861:d=9  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020780
 3015:d=5
 2867:d=5  hl=2 l=  10 cons: SEQUENCE
 3017:d=6
 2869:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 3027:d=5
 2879:d=5  hl=2 l= 104 prim: BIT STRING
 3133:d=4
 2985:d=4  hl=4 l= 619 cons: SEQUENCE
 3137:d=5
 2989:d=5  hl=4 l= 498 cons: SEQUENCE
 3141:d=6
 2993:d=6  hl=2 l=   3 cons: cont [ 0 ]
 3143:d=7
 2995:d=7  hl=2 l=   1 prim: INTEGER           :02
 3146:d=6
 2998:d=6  hl=2 l=   4 prim: INTEGER           :296B0659
 3152:d=6
 3004:d=6  hl=2 l=  10 cons: SEQUENCE
 3154:d=7
 3006:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 3164:d=6
 3016:d=6  hl=2 l= 109 cons: SEQUENCE
 3166:d=7
 3018:d=7  hl=2 l=  18 cons: SET
 3168:d=8
 3020:d=8  hl=2 l=  16 cons: SEQUENCE
 3170:d=9
 3022:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 3182:d=9
 3034:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 3186:d=7
 3038:d=7  hl=2 l=  25 cons: SET
 3188:d=8
 3040:d=8  hl=2 l=  23 cons: SEQUENCE
 3190:d=9
 3042:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 3202:d=9
 3054:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 3213:d=7
 3065:d=7  hl=2 l=  60 cons: SET
 3215:d=8
 3067:d=8  hl=2 l=  58 cons: SEQUENCE
 3217:d=9
 3069:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 3222:d=9
 3074:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
 3275:d=6
 3127:d=6  hl=2 l=  30 cons: SEQUENCE
 3277:d=7
 3129:d=7  hl=2 l=  13 prim: UTCTIME           :200225213145Z
 3292:d=7
 3144:d=7  hl=2 l=  13 prim: UTCTIME           :220224213145Z
 3307:d=6
 3159:d=6  hl=2 l= 109 cons: SEQUENCE
 3309:d=7
 3161:d=7  hl=2 l=  18 cons: SET
 3311:d=8
 3163:d=8  hl=2 l=  16 cons: SEQUENCE
 3313:d=9
 3165:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 3325:d=9
 3177:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 3329:d=7
 3181:d=7  hl=2 l=  25 cons: SET
 3331:d=8
 3183:d=8  hl=2 l=  23 cons: SEQUENCE
 3333:d=9
 3185:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 3345:d=9
 3197:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 3356:d=7
 3208:d=7  hl=2 l=  60 cons: SET
 3358:d=8
 3210:d=8  hl=2 l=  58 cons: SEQUENCE
 3360:d=9
 3212:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 3365:d=9
 3217:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
 3418:d=6
 3270:d=6  hl=2 l= 118 cons: SEQUENCE
 3420:d=7
 3272:d=7  hl=2 l=  16 cons: SEQUENCE
 3422:d=8
 3274:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
 3431:d=8
 3283:d=8  hl=2 l=   5 prim: OBJECT            :secp384r1
 3438:d=7
 3290:d=7  hl=2 l=  98 prim: BIT STRING
 3538:d=6
 3390:d=6  hl=2 l=  99 cons: cont [ 3 ]
 3540:d=7
 3392:d=7  hl=2 l=  97 cons: SEQUENCE
 3542:d=8
 3394:d=8  hl=2 l=  15 cons: SEQUENCE
 3544:d=9
 3396:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 3549:d=9
 3401:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 3552:d=9
 3404:d=9  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF
 3559:d=8
 3411:d=8  hl=2 l=  14 cons: SEQUENCE
 3561:d=9
 3413:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
 3566:d=9
 3418:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 3569:d=9
 3421:d=9  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020106
 3575:d=8
 3427:d=8  hl=2 l=  29 cons: SEQUENCE
 3577:d=9
 3429:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Ident
 3582:d=9
 3434:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:0414B9A5F6CB11
 3606:d=8
 3458:d=8  hl=2 l=  31 cons: SEQUENCE
 3608:d=9
 3460:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Ide
 3613:d=9
 3465:d=9  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:30168014B9A5F6
 3639:d=5
 3491:d=5  hl=2 l=  10 cons: SEQUENCE
 3641:d=6
 3493:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 3651:d=5
 3503:d=5  hl=2 l= 103 prim: BIT STRING
 3756:d=3
 3608:d=3  hl=4 l= 331 cons: SET
 3760:d=4
 3612:d=4  hl=4 l= 327 cons: SEQUENCE
 3764:d=5
 3616:d=5  hl=2 l=   1 prim: INTEGER           :01
 3767:d=5
 3619:d=5  hl=2 l= 117 cons: SEQUENCE
 3769:d=6
 3621:d=6  hl=2 l= 109 cons: SEQUENCE
 3771:d=7
 3623:d=7  hl=2 l=  18 cons: SET
 3773:d=8
 3625:d=8  hl=2 l=  16 cons: SEQUENCE
 3775:d=9
 3627:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 3787:d=9
 3639:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 3791:d=7
 3643:d=7  hl=2 l=  25 cons: SET
 3793:d=8
 3645:d=8  hl=2 l=  23 cons: SEQUENCE
 3795:d=9
 3647:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 3807:d=9
 3659:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 3818:d=7
 3670:d=7  hl=2 l=  60 cons: SET
 3820:d=8
 3672:d=8  hl=2 l=  58 cons: SEQUENCE
 3822:d=9
 3674:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 3827:d=9
 3679:d=9  hl=2 l=  51 prim: UTF8STRING        :fountain-test.example.co
 3880:d=6
 3732:d=6  hl=2 l=   4 prim: INTEGER           :3F989B52
 3886:d=5
 3738:d=5  hl=2 l=  11 cons: SEQUENCE
 3888:d=6
 3740:d=6  hl=2 l=   9 prim: OBJECT            :sha256
 3899:d=5
 3751:d=5  hl=2 l= 105 cons: cont [ 0 ]
 3901:d=6
 3753:d=6  hl=2 l=  24 cons: SEQUENCE
 3903:d=7
 3755:d=7  hl=2 l=   9 prim: OBJECT            :contentType
 3914:d=7
 3766:d=7  hl=2 l=  11 cons: SET
 3916:d=8
 3768:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
 3927:d=6
 3779:d=6  hl=2 l=  28 cons: SEQUENCE
 3929:d=7
 3781:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
 3940:d=7
 3792:d=7  hl=2 l=  15 cons: SET
 3942:d=8
 3794:d=8  hl=2 l=  13 prim: UTCTIME           :200225230449Z
 3957:d=6           :210413214323Z
 3809:d=6  hl=2 l=  47 cons: SEQUENCE
 3959:d=7
 3811:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
 3970:d=7
 3822:d=7  hl=2 l=  34 cons: SET
 3972:d=8
 3824:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:3D818C51D6C4B4
 4006:d=5 DUMP]:49CEADD5A3946E
 3858:d=5  hl=2 l=  10 cons: SEQUENCE
 4008:d=6
 3860:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 4018:d=5
 3870:d=5  hl=2 l=  71 prim: OCTET STRING      [HEX DUMP]:30450220589E5D DUMP]:3045022100C84E

]]></artwork>
          <t>
            The JSON contained in the voucher request. voucher-request. Note that the previous
            voucher request
            voucher-request is in the prior-signed-voucher-request attribute.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="json">
{"ietf-voucher-request:voucher":{"assertion":"proximity","cr
eated-on":"2020-02-25T23:04:49.054Z","serial-number":"00-D0-
E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","prior-signed-
voucher-request":"MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBg
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
JjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLC
JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Im
FNamd1ZUtVVC0yMndWaW1qNnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLW
JjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0MzoyMy43NDctMDQ6MDAiLC
JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Ii
1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFyLW
NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV
FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU
prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF
lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm
5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak
F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV
pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU
F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn
lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk
NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU
5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU
1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG
tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV
BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk
JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2
NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIEDYXcLTAKBg
gqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW
8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0Lm
V4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMD
AwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49Ag
EGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5BefBbE0
sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDg
QWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBw
EgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BA
MCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TX
mKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vA
QdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2
FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJD
AiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEDYXcLTALBg
lghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSI
b3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6Irwst
HF609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIB
xwA1UlkIkuQDf/j7kZ/MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bm
iEUpefCEhxSv2xLYurGlugv0dfr/E="}}]]></artwork>
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="}}
</sourcecode>
        </section>
        <section numbered="true" toc="default">
          <name>MASA to Registrar</name>
          <t>
            The MASA will return a voucher to the registrar, which is to be relayed to
            the pledge.
          </t>
          <sourcecode name="voucher_00-D0-E5-F2-00-02.b64" type="" markers="true"><![CDATA[
MIIGxwYJKoZIhvcNAQcCoIIGuDCCBrQCAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG9w0BBwGg
ggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoibG9nZ2VkIiwiY3Jl
YXRlZC1vbiI6IjIwMjAtMDItMjVUMTg6MDQ6NDkuMzAzLTA1OjAwIiwic2VyaWFsLW51bWJlciI6
IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdRIiwicGlu
bmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NBWUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFR
REFqQnRNUkl3RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6
WVc1a1pXeHRZVzR4UERBNkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpi
MjBnVlc1emRISjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5U
UmFGdzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJj
R0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05MWJuUmhhVzR0
ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFC
SlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt
SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqS2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0Nz
R0FRVUZCd01jTUE0R0ExVWREd0VCL3dRRUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJt
VDJCTVZVZ2VsZ2Y0M1IrNXlCS05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVht
UmtqL1g0Q01RQzhyTU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNn
ZFNjRmNBZGYrK0J3Nll5K1U9In19oIIB4zCCAd8wggFkoAMCAQICBBuZX1QwCgYIKoZIzj0EAwIw
XTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4x
JDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0xOTAyMTIyMjIyNDFaFw0y
MTAyMTEyMjIyNDFaMF8xDzANBgNVBAYTBkNhbmFkYTEQMA4GA1UECAwHT250YXJpbzESMBAGA1UE
CwwJU2FuZGVsbWFuMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gTUFTQTBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5GwcbpnRznB66bKmzqTCpojJZ96AdRwFt
uTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6WjEDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0E
AwIDaQAwZgIxAL1V5ZsO+/xelSnjgbMVNaqTGKIEvkRyslF9TW3r0dXBEDqyOXtXP8XMsKMO55lG
ugIxAPZ/RH23FPrRZ2rUEcNLrub7mphW+oUhLlxITPA/8ps/roggp675cv9b+Xhozw9IyTGCATsw
ggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlT
YW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEG5lfVDALBglg
hkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAy
MjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCCJQso4Z9msdaPk3bsDltTkVckX50DvOPuOR9Svi5M9
RDAKBggqhkjOPQQDAgRHMEUCIQCKESXfM3iV8hpkqcxAKA1veArA6GFpN0jzyns4El8uDgIgSRQi
9/MntuJhAM/tJCZBkfHBoAGX4PFAwwbs5LFZtAw=
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=
]]></sourcecode>
          <t>
            The ASN1 decoding of the artifact:
          </t>
          <t keepWithPrevious="true">file: examples/voucher_00-D0-E5-F2-00-02.b64</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    0:d=0  hl=4 l=1735 l=1570 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
   15:d=1  hl=4 l=1720 l=1555 cons: cont [ 0 ]
   19:d=2  hl=4 l=1716 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= 483 372 cons: cont [ 0 ]
  937:d=4  hl=4 l= 479 368 cons: SEQUENCE
  941:d=5  hl=4  hl=3 l= 356 246 cons: SEQUENCE
  945:d=6
  944:d=6  hl=2 l=   3 cons: cont [ 0 ]
  947:d=7
  946:d=7  hl=2 l=   1 prim: INTEGER           :02
  950:d=6
  949:d=6  hl=2 l=   4 prim: INTEGER           :1B995F54
  956:d=6           :0B870A31
  955:d=6  hl=2 l=  10 cons: SEQUENCE
  958:d=7
  957:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
  968:d=6  hl=2 l=  93 cons: SEQUENCE
  970:d=7  hl=2 l=  15 cons: SET
  972:d=8  hl=2 l=  13 cons: SEQUENCE
  974:d=9  hl=2 l=   3 prim: OBJECT            :countryName
  979:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
  987:d=7  hl=2 l=  16 cons: SET
  989:d=8  hl=2 l=  14 cons: SEQUENCE
  991:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
  996:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
 1005:d=7  hl=2 l=  18 cons: SET
 1007:d=8
  967:d=6  hl=2 l=  16  38 cons: SEQUENCE
 1009:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
 1014:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
 1025:d=7
  969:d=7  hl=2 l=  36 cons: SET
 1027:d=8
  971:d=8  hl=2 l=  34 cons: SEQUENCE
 1029:d=9
  973:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1034:d=9
  978:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
 1063:d=6
 1007:d=6  hl=2 l=  30 cons: SEQUENCE
 1065:d=7
 1009:d=7  hl=2 l=  13 prim: UTCTIME           :190212222241Z
 1080:d=7           :210413214016Z
 1024:d=7  hl=2 l=  13 prim: UTCTIME           :210211222241Z
 1095:d=6  hl=2 l=  95 cons: SEQUENCE
 1097:d=7  hl=2 l=  15 cons: SET
 1099:d=8  hl=2 l=  13 cons: SEQUENCE
 1101:d=9  hl=2 l=   3 prim: OBJECT            :countryName
 1106:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
 1114:d=7  hl=2 l=  16 cons: SET
 1116:d=8  hl=2 l=  14 cons: SEQUENCE
 1118:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
 1123:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
 1132:d=7  hl=2 l=  18 cons: SET
 1134:d=8           :230413214016Z
 1039:d=6  hl=2 l=  16  40 cons: SEQUENCE
 1136:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
 1141:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
 1152:d=7
 1041:d=7  hl=2 l=  38 cons: SET
 1154:d=8
 1043:d=8  hl=2 l=  36 cons: SEQUENCE
 1156:d=9
 1045:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1161:d=9
 1050:d=9  hl=2 l=  29 prim: UTF8STRING        :highway-test.example.com
 1192:d=6
 1081:d=6  hl=2 l=  89 cons: SEQUENCE
 1194:d=7
 1083:d=7  hl=2 l=  19 cons: SEQUENCE
 1196:d=8
 1085:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
 1205:d=8
 1094:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
 1215:d=7
 1104:d=7  hl=2 l=  66 prim: BIT STRING
 1283:d=6
 1172:d=6  hl=2 l=  16 cons: cont [ 3 ]
 1285:d=7
 1174:d=7  hl=2 l=  14 cons: SEQUENCE
 1287:d=8
 1176:d=8  hl=2 l=  12 cons: SEQUENCE
 1289:d=9
 1178:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 1294:d=9
 1183:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 1297:d=9
 1186:d=9  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
 1301:d=5
 1190:d=5  hl=2 l=  10 cons: SEQUENCE
 1303:d=6
 1192:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 1313:d=5
 1202:d=5  hl=2 l= 105 prim: BIT STRING
 1420:d=3
 1309:d=3  hl=4 l= 315 261 cons: SET
 1424:d=4
 1313:d=4  hl=4 l= 311 257 cons: SEQUENCE
 1428:d=5
 1317:d=5  hl=2 l=   1 prim: INTEGER           :01
 1431:d=5  hl=2 l= 101 cons: SEQUENCE
 1433:d=6  hl=2 l=  93 cons: SEQUENCE
 1435:d=7  hl=2 l=  15 cons: SET
 1437:d=8  hl=2 l=  13 cons: SEQUENCE
 1439:d=9  hl=2 l=   3 prim: OBJECT            :countryName
 1444:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
 1452:d=7  hl=2 l=  16 cons: SET
 1454:d=8
 1320:d=5  hl=2 l=  14  46 cons: SEQUENCE
 1456:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
 1461:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
 1470:d=7  hl=2 l=  18 cons: SET
 1472:d=8
 1322:d=6  hl=2 l=  16  38 cons: SEQUENCE
 1474:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
 1479:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
 1490:d=7
 1324:d=7  hl=2 l=  36 cons: SET
 1492:d=8
 1326:d=8  hl=2 l=  34 cons: SEQUENCE
 1494:d=9
 1328:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1499:d=9
 1333:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
 1528:d=6
 1362:d=6  hl=2 l=   4 prim: INTEGER           :1B995F54
 1534:d=5           :0B870A31
 1368:d=5  hl=2 l=  11 cons: SEQUENCE
 1536:d=6
 1370:d=6  hl=2 l=   9 prim: OBJECT            :sha256
 1547:d=5
 1381:d=5  hl=2 l= 105 cons: cont [ 0 ]
 1549:d=6
 1383:d=6  hl=2 l=  24 cons: SEQUENCE
 1551:d=7
 1385:d=7  hl=2 l=   9 prim: OBJECT            :contentType
 1562:d=7
 1396:d=7  hl=2 l=  11 cons: SET
 1564:d=8
 1398:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
 1575:d=6
 1409:d=6  hl=2 l=  28 cons: SEQUENCE
 1577:d=7
 1411:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
 1588:d=7
 1422:d=7  hl=2 l=  15 cons: SET
 1590:d=8
 1424:d=8  hl=2 l=  13 prim: UTCTIME           :200225230449Z
 1605:d=6           :210413214324Z
 1439:d=6  hl=2 l=  47 cons: SEQUENCE
 1607:d=7
 1441:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
 1618:d=7
 1452:d=7  hl=2 l=  34 cons: SET
 1620:d=8
 1454:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:8942CA3867D9AC
 1654:d=5 DUMP]:55148E0E166153
 1488:d=5  hl=2 l=  10 cons: SEQUENCE
 1656:d=6
 1490:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 1666:d=5
 1500:d=5  hl=2 l=  71  72 prim: OCTET STRING      [HEX DUMP]:30450221008A11 DUMP]:3046022100E854

 ]]></artwork>
	</section>
      </section>
    </section>
	     <section numbered="true" numbered="false" toc="default">
      <name>Additional References</name>
      <t>
        RFC EDITOR Please remove this section before publication.
        It exists just to include
        references
      <name>Acknowledgements</name>
      <t>We would like to thank the things various reviewers for their input, in
      particular
      <contact fullname="William Atwood"/>,
      <contact fullname="Brian Carpenter"/>,
      <contact fullname="Fuyu Eleven"/>,
      <contact fullname="Eliot Lear"/>,
      <contact fullname="Sergey Kasatkin"/>,
      <contact fullname="Anoop Kumar"/>,
      <contact fullname="Tom Petch"/>,
      <contact fullname="Markus Stenberg"/>,
      <contact fullname="Peter van der Stok"/>,
      and
      <contact fullname="Thomas Werner"/>.
      </t>
      <t>
        Significant reviews were done by <contact fullname="Jari Arkko"/>,
<contact fullname="Christian Huitema"/>, and <contact fullname="Russ Housley"/>.
      </t>
      <t>
        <contact fullname="Henk Birkholz"/> contributed the YANG descriptions which are not
        otherwise referenced in CDDL for the text so that xml2rfc will not complain. audit-log response.
      </t>
      <t>
        <xref target="ITU.X690.1994" format="default"/>
        This document started its life as a two-page idea from <contact
fullname="Steinthor Bjarnason"/>.
      </t>
      <t>
        In addition, significant review comments were provided by many IESG
        members, including <contact fullname="Adam Roach"/>, <contact
fullname="Alexey Melnikov"/>, <contact fullname="Alissa Cooper"/>, <contact
fullname="Benjamin Kaduk"/>, <contact fullname="Éric Vyncke"/>, <contact
fullname="Roman Danyliw"/>, and <contact fullname="Magnus Westerlund"/>.
      </t>
    </section>
        </section>
      </section>

  </back> </rfc>
<!--
    Local Variables:
    mode: xml
    End:
-->