rfc8995.original.xml   rfc8995.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-anima-bootstrapping-keyinfra-43" ipr="trust200902" obsoletes="" updates="" su <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
bmissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="tru docName="draft-ietf-anima-bootstrapping-keyinfra-45" ipr="trust200902"
e" version="3"> obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3" number="8995" consensus="yes">
<!-- xml2rfc v2v3 conversion 2.46.0 --> <!-- xml2rfc v2v3 conversion 2.46.0 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front> <front>
<title abbrev="BRSKI">Bootstrapping Remote Secure Key Infrastructures <title abbrev="BRSKI">Bootstrapping Remote Secure Key Infrastructure
(BRSKI)</title> (BRSKI)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-bootstrapping-keyi nfra-43"/> <seriesInfo name="RFC" value="8995"/>
<author fullname="Max Pritikin" initials="M." surname="Pritikin"> <author fullname="Max Pritikin" initials="M." surname="Pritikin">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>pritikin@cisco.com</email> <email>pritikin@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Michael C. Richardson" initials="M." surname="Richardson"> <author fullname="Michael C. Richardson" initials="M." surname="Richardson">
<organization abbrev="Sandelman">Sandelman Software Works</organization> <organization abbrev="Sandelman Software Works">Sandelman Software Works</ organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/</uri> <uri>http://www.sandelman.ca/</uri>
</address> </address>
</author> </author>
<author fullname="Toerless Eckert" initials="T.T.E." surname="Eckert"> <author fullname="Toerless Eckert" initials="T." surname="Eckert">
<organization abbrev="Futurewei USA"> <organization abbrev="Futurewei USA">
Futurewei Technologies Inc. USA</organization> Futurewei Technologies Inc. USA</organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expy</street> <street>2330 Central Expy</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region> <region>CA</region>
<code>95050</code> <code>95050</code>
<country>USA</country> <country>USA</country>
</postal> </postal>
<email>tte+ietf@cs.fau.de</email> <email>tte+ietf@cs.fau.de</email>
</address> </address>
</author> </author>
<author fullname="Michael H. Behringer" initials="M.H." surname="Behringer"> <author fullname="Michael H. Behringer" initials="M." surname="Behringer">
<address> <address>
<email>Michael.H.Behringer@gmail.com</email> <email>Michael.H.Behringer@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Kent Watsen" initials="K.W." surname="Watsen"> <author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization>Watsen Networks</organization> <organization>Watsen Networks</organization>
<address> <address>
<email>kent+ietf@watsen.net</email> <email>kent+ietf@watsen.net</email>
</address> </address>
</author> </author>
<date year="2020"/> <date year="2021" month="May"/>
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>ANIMA WG</workgroup> <workgroup>ANIMA</workgroup>
<abstract> <abstract>
<t> <t>
This document specifies automated bootstrapping of an Autonomic This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is Control Plane. To do this, a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed bootstrapped. This is done using manufacturer-installed
X.509 certificates, in combination with a manufacturer's authorizing X.509 certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a Bootstrapping a new device can occur when using a routable address and a
cloud service, or using only link-local connectivity, or on cloud service, only link-local connectivity, or
limited/disconnected networks. Support for deployment models limited/disconnected networks. Support for deployment models
with less stringent security requirements is included. with less stringent security requirements is included.
Bootstrapping is complete when the cryptographic identity of the new Bootstrapping is complete when the cryptographic identity of the new
key infrastructure is successfully deployed to the device. The key infrastructure is successfully deployed to the device. The
established secure connection can be used to deploy a locally issued established secure connection can be used to deploy a locally issued
certificate to the device as well. certificate to the device as well.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
provides a solution for secure zero-touch (automated) bootstrap of provides a solution for secure zero-touch (automated) bootstrap of
new (unconfigured) devices that are called pledges in this new (unconfigured) devices that are called "pledges" in this
document. Pledges have an IDevID installed in them at the factory. document. Pledges have an Initial Device Identifier (IDevID) installed
in them at the factory.
</t> </t>
<t> <t>
"BRSKI" is pronounced like "brewski", a colloquial term for beer in "BRSKI", pronounced like "brewski", is a colloquial term for beer in
Canada and parts of the US-midwest. <xref target="brewski" format="defau Canada and parts of the Midwestern United States <xref target="brewski"
lt"/> format="default"/>.
</t> </t>
<t> <t>
This document primarily provides for the needs of This document primarily provides for the needs of
the ISP and Enterprise focused ANIMA the ISP and enterprise-focused Autonomic Networking Integrated Model and
<xref target="I-D.ietf-anima-autonomic-control-plane" format="default">A Approach (ANIMA)
utonomic Autonomic Control Plane (ACP) <xref target="RFC8994" format="default"/>.
Control Plane (ACP)</xref>. This bootstrap process satisfies
the <xref target="RFC7575" format="default"/> requirements of section 3. This bootstrap process satisfies
3 of making all operations the requirement of making all operations
secure by default. Other users of the BRSKI protocol secure by default per <xref target="RFC7575" sectionFormat="of" section=
"3.3"/>.
Other users of the BRSKI protocol
will need to provide separate applicability statements that will need to provide separate applicability statements that
include privacy and security considerations appropriate to that include privacy and security considerations appropriate to that
deployment. <xref target="acpapplicability" format="default"/> explains the detailed deployment. <xref target="acpapplicability" format="default"/> explains the detailed
applicability for this the ACP usage. applicability for this ACP usage.
</t> </t>
<t> <t>
The BRSKI protocol requires a significant amount of communication The BRSKI protocol requires a significant amount of communication
between manufacturer and owner: in its default modes it provides a between manufacturer and owner: in its default modes, it provides a
cryptographic transfer of control to the initial owner. In its cryptographic transfer of control to the initial owner. In its
strongest modes, it leverages sales channel information to identify strongest modes, it leverages sales channel information to identify
the owner in advance. Resale of devices is possible, provided that the owner in advance. Resale of devices is possible, provided that
the manufacturer is willing to authorize the transfer. Mechanisms the manufacturer is willing to authorize the transfer. Mechanisms
to enable transfers of ownership without manufacturer authorization to enable transfers of ownership without manufacturer authorization
are not included in this version of the protocol, but could be are not included in this version of the protocol, but it could be
designed into future versions. designed into future versions.
</t> </t>
<t> <t>
This document describes how pledges discover (or are discovered by) an This document describes how a pledge discovers (or are discovered by) an
element of the network domain to which the pledge belongs that will perf element of the network domain that it will belong to and that will perfo
orm rm
the bootstrap. This element (device) is called the its bootstrap. This element (device) is called the
registrar. Before any other operation, pledge and registrar need to "registrar". Before any other operation, the pledge and registrar need
to
establish mutual trust: establish mutual trust:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Registrar authenticating the pledge: "Who is this device? What is <li>Registrar authenticating the pledge: "Who is this device? What is
its identity?"</li> its identity?"</li>
<li>Registrar authorizing the pledge: "Is it mine? Do I want it? <li>Registrar authorizing the pledge: "Is it mine? Do I want it?
What are the chances it has been compromised?"</li> What are the chances it has been compromised?"</li>
<li>Pledge authenticating the registrar: "What is this <li>Pledge authenticating the registrar: "What is this
registrar's identity?"</li> registrar's identity?"</li>
<li>Pledge authorizing the registrar: "Should I join this network?"</li> <li>Pledge authorizing the registrar: "Should I join this network?"</li>
</ol> </ol>
<t> <t>
This document details protocols and messages to answer the above quest ions. This document details protocols and messages to answer the above quest ions.
It uses a TLS connection and an PKIX-shaped (X.509v3) certificate (an It uses a TLS connection and a PKIX-shaped (X.509v3) certificate (an I
IEEE EEE
802.1AR <xref target="IDevID" format="default"/> IDevID) of the pledge 802.1AR IDevID <xref target="IDevID" format="default"/>) of the pledge
to answer to answer
points 1 and 2. points 1 and 2.
It uses a new artifact called a "voucher" that the registrar It uses a new artifact called a "voucher" that the registrar
receives from a "Manufacturer Authorized Signing Authority" (MASA) and receives from a Manufacturer Authorized Signing Authority (MASA) and
passes to the pledge to answer points 3 and 4. passes it to the pledge to answer points 3 and 4.
</t> </t>
<t> <t>
A proxy provides very limited connectivity between the pledge and A proxy provides very limited connectivity between the pledge and
the registrar. the registrar.
</t> </t>
<t>The syntactic details of vouchers are described in detail in <xref targ et="RFC8366" format="default"/>. This document details automated <t>The syntactic details of vouchers are described in detail in <xref targ et="RFC8366" format="default"/>. This document details automated
protocol mechanisms to obtain vouchers, including the definition protocol mechanisms to obtain vouchers, including the definition
of a 'voucher-request' message that is a minor extension of a "voucher-request" message that is a minor extension
to the voucher format (see <xref target="voucher-request" format="default" to the voucher format (see <xref target="voucher-request" format="default"
/>) defined />) as defined
by <xref target="RFC8366" format="default"/>.</t> by <xref target="RFC8366" format="default"/>.</t>
<t>BRSKI results in the pledge storing an X.509 root <t>BRSKI results in the pledge storing an X.509 root
certificate sufficient for verifying the registrar identity. In the certificate sufficient for verifying the registrar identity. In the
process a TLS connection is established that can be directly used for process, a TLS connection is established that can be directly used for
Enrollment over Secure Transport (EST). In effect BRSKI provides Enrollment over Secure Transport (EST).
an automated mechanism for the "Bootstrap Distribution of CA Certificates"
described in <xref target="RFC7030" format="default"/> Section 4.1.1 wherein In effect, BRSKI provides
the pledge "MUST [...] engage a human user to authorize the CA certificate u an automated mechanism for "Bootstrap Distribution of CA Certificates"
sing described in <xref target="RFC7030" sectionFormat="comma" section="4.1.1"/>,
out-of-band" information. With BRSKI the pledge now can automate wherein
the pledge "<bcp14>MUST</bcp14> [...] engage a human user to authorize the C
A certificate using
out-of-band data". With BRSKI, the pledge now can automate
this process using the voucher. Integration with a complete EST this process using the voucher. Integration with a complete EST
enrollment is optional but trivial.</t> enrollment is optional but trivial.</t>
<t>BRSKI is agile enough to support <t>BRSKI is agile enough to support
bootstrapping alternative key infrastructures, such as a symmetric key bootstrapping alternative key infrastructures, such as a symmetric key
solutions, but no such system is described in this document.</t> solution, but no such system is described in this document.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Prior Bootstrapping Approaches</name> <name>Prior Bootstrapping Approaches</name>
<t>To literally "pull yourself up by the bootstraps" is an impossible <t>To literally "pull yourself up by the bootstraps" is an impossible
action. Similarly the secure establishment of a key infrastructure action. Similarly, the secure establishment of a key infrastructure
without external help is also an impossibility. Today it is commonly without external help is also an impossibility. Today, it is commonly
accepted that the initial connections between nodes are insecure, until accepted that the initial connections between nodes are insecure, until
key distribution is complete, or that domain-specific keying material key distribution is complete, or that domain-specific keying material
(often pre-shared keys, including mechanisms like SIM cards) (often pre-shared keys, including mechanisms like Subscriber Identificat ion Module (SIM) cards)
is pre-provisioned on each new device in a costly and non-scalable is pre-provisioned on each new device in a costly and non-scalable
manner. Existing automated mechanisms are known as non-secured 'Trust on manner.
First Use' (TOFU) <xref target="RFC7435" format="default"/>, 'resurrecti
ng duckling' Existing automated mechanisms are known as non-secured "Trust on
<xref target="Stajano99theresurrecting" format="default"/> or 'pre-stagi First Use (TOFU)" <xref target="RFC7435" format="default"/>, "resurrecti
ng'.</t> ng duckling"
<xref target="Stajano99theresurrecting" format="default"/>, or "pre-stag
ing".</t>
<t>Another prior approach has been to try and <t>Another prior approach has been to try and
minimize user actions during bootstrapping, but not eliminate all minimize user actions during bootstrapping, but not eliminate all
user-actions. user actions.
The original EST protocol <xref target="RFC7030" format="default"/> does The original EST protocol <xref target="RFC7030" format="default"/> does
reduce user actions during bootstrap reduce user actions during bootstrapping
but does not provide solutions for how the following protocol steps but does not provide solutions for how the following protocol steps
can be made autonomic (not involving user actions): can be made autonomic (not involving user actions):
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>using the Implicit Trust Anchor <xref target="RFC7030" format="def <li>using the Implicit Trust Anchor (TA) <xref target="RFC7030" format
ault"/> database to authenticate ="default"/> database to authenticate
an owner specific service (not an autonomic solution because an owner-specific service (not an autonomic solution because
the URL must be securely distributed),</li> the URL must be securely distributed),</li>
<li>engaging a human user to authorize the CA certificate using <li>engaging a human user to authorize the CA certificate using
out-of-band data (not an autonomic solution because the human user out-of-band data (not an autonomic solution because the human user
is involved),</li> is involved),</li>
<li>using a configured Explicit TA database (not an autonomic <li>using a configured Explicit TA database (not an autonomic
solution because the distribution of an explicit TA database i s solution because the distribution of an explicit TA database i s
not autonomic),</li> not autonomic), and</li>
<li>and using a Certificate-Less TLS mutual authentication method <li>using a certificate-less TLS mutual authentication method
(not an autonomic solution because the distribution of symmetr ic (not an autonomic solution because the distribution of symmetr ic
key material is not autonomic). key material is not autonomic).
</li> </li>
</ul> </ul>
<t> <t>
These "touch" methods do not meet the requirements for These "touch" methods do not meet the requirements for
zero-touch. zero-touch.
</t> </t>
<t>There are "call home" technologies where the pledge first <t>There are "call home" technologies where the pledge first
establishes a connection to a well known manufacturer service usin g a common establishes a connection to a well-known manufacturer service usin g a common
client-server authentication model. After mutual authentication, client-server authentication model. After mutual authentication,
appropriate credentials to authenticate the target domain are appropriate credentials to authenticate the target domain are
transferred to the pledge. This creates several problems and transferred to the pledge. This creates several problems and
limitations:</t> limitations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the pledge requires realtime connectivity to the manufacturer <li>the pledge requires real-time connectivity to the manufacturer
service,</li> service,</li>
<li>the domain identity is exposed to the manufacturer service (this i s a <li>the domain identity is exposed to the manufacturer service (this i s a
privacy concern),</li> privacy concern), and</li>
<li>the manufacturer is responsible for making the authorization <li>the manufacturer is responsible for making the authorization
decisions (this is a liability concern),</li> decisions (this is a liability concern).</li>
</ul> </ul>
<t>BRSKI addresses these issues by defining extensions to the EST protoc ol <t>BRSKI addresses these issues by defining extensions to the EST protoc ol
for the automated distribution of vouchers. for the automated distribution of vouchers.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119" format="default"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC8174" format="default"/> when, and only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here. be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
<t>The following terms are defined for clarity:</t> <t>The following terms are defined for clarity:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>ANI:</dt> <dt>ANI:</dt>
<dd>The Autonomic Network Infrastructure as <dd>The Autonomic Networking Infrastructure as
defined by <xref target="I-D.ietf-anima-reference-model" format="def defined by <xref target="RFC8993" format="default"/>.
ault"/>.
<xref target="acpapplicability" format="default"/> details specific requirements for pledges, <xref target="acpapplicability" format="default"/> details specific requirements for pledges,
proxies and registrars when they are part of an ANI.</dd> proxies, and registrars when they are part of an ANI.</dd>
<dt>Circuit Proxy:</dt> <dt>Circuit Proxy:</dt>
<dd>A stateful implementation <dd>A stateful implementation
of the join proxy. This is the assumed type of proxy.</dd> of the Join Proxy. This is the assumed type of proxy.</dd>
<dt>drop-ship:</dt> <dt>drop-ship:</dt>
<dd>The physical distribution of equipment <dd>The physical distribution of equipment
containing the "factory default" configuration to a final containing the "factory default" configuration to a final
destination. In zero-touch scenarios there is no staging or destination. In zero-touch scenarios, there is no staging or
pre-configuration during drop-ship.</dd> preconfiguration during drop-ship.</dd>
<dt>Domain:</dt> <dt>Domain:</dt>
<dd>The set of entities that share a common local <dd>The set of entities that share a common local
trust anchor. This includes the proxy, registrar, trust anchor. This includes the proxy, registrar,
Domain Certificate Authority, Management components and any domain CA, management components, and any
existing entity that is already a member of the domain.</dd> existing entity that is already a member of the domain.</dd>
<dt>domainID:</dt> <dt>Domain CA:</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 calcu
lated.
</dd>
<dt>Domain CA:</dt>
<dd>The domain Certification Authority (CA) <dd>The domain Certification Authority (CA)
provides certification functionalities to the domain. At a minimum provides certification functionalities to the domain. At a minimum,
it provides certification functionalities to a registrar and it provides certification functionalities to a registrar and
manages the private key that defines the domain. Optionally, it manages the private key that defines the domain. Optionally, it
certifies all elements.</dd> 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 calcu
lated.
</dd>
<dt>enrollment:</dt> <dt>enrollment:</dt>
<dd>The process where a device presents key <dd>The process where a device presents key
material to a network and acquires a network-specific identity. material to a network and acquires a network-specific identity.
For example when a certificate signing request is presented to a For example, when a certificate signing request is presented to a
certification authority and a certificate is obtained in CA, and a certificate is obtained in
response.</dd> 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> <dt>imprint:</dt>
<dd>The process where a device obtains the <dd>The process where a device obtains the
cryptographic key material to identify and trust future cryptographic key material to identify and trust future
interactions with a network. This term is taken from Konrad interactions with a network. This term is taken from Konrad
Lorenz's work in biology with new ducklings: during a critical Lorenz's work in biology with new ducklings: during a critical
period, the duckling would assume that anything that looks like a period, the duckling would assume that anything that looks like a
mother duck is in fact their mother. An equivalent for a device is mother duck is in fact their mother. An equivalent for a device is
to obtain the fingerprint of the network's root certification to obtain the fingerprint of the network's root CA certificate. A de
authority certificate. A device that imprints on an attacker vice that imprints on an attacker
suffers a similar fate to a duckling that imprints on a hungry suffers a similar fate to a duckling that imprints on a hungry
wolf. Securely imprinting is a primary focus of this wolf. Securely imprinting is a primary focus of this
document <xref target="imprinting" format="default"/>. The analogy t o document <xref target="imprinting" format="default"/>. The analogy t o
Lorenz's work was first noted in <xref target="Stajano99theresurrect ing" format="default"/>.</dd> Lorenz's work was first noted in <xref target="Stajano99theresurrect ing" 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> <dt>IPIP Proxy:</dt>
<dd>A stateless proxy alternative.</dd> <dd>A stateless proxy alternative.</dd>
<dt>Join Proxy:</dt> <dt>Join Proxy:</dt>
<dd>A domain entity that helps the pledge join <dd>A domain entity that helps the pledge join
the domain. A join proxy facilitates communication for devices that the domain. A Join Proxy facilitates communication for devices that
find themselves in an environment where they are not provided find themselves in an environment where they are not provided
connectivity until after they are validated as members of the connectivity until after they are validated as members of the
domain. For simplicity this document sometimes uses the domain. For simplicity, this document sometimes uses the
term of 'proxy' to indicate the join proxy. The pledge term of "proxy" to indicate the Join Proxy. The pledge
is unaware that they are communicating with a is unaware that they are communicating with a
proxy rather than directly with a registrar.</dd> proxy rather than directly with a registrar.</dd>
<dt>Join Registrar (and Coordinator):</dt> <dt>Join Registrar (and Coordinator):</dt>
<dd>A representative of the domain that is <dd>A representative of the domain that is
configured, perhaps autonomically, to decide whether a new device configured, perhaps autonomically, to decide whether a new device
is allowed to join the domain. The administrator of the domain is allowed to join the domain. The administrator of the domain
interfaces with a "join registrar (and coordinator)" to control this interfaces with a "Join Registrar (and Coordinator)" to control this
process. Typically a process. Typically, a
join registrar is "inside" its domain. For simplicity this document Join Registrar is "inside" its domain. For simplicity, this document
often refers to this as just "registrar". Within <xref target="I-D.i often refers to this as just "registrar". Within <xref target="RFC89
etf-anima-reference-model" format="default"/> this is 93" format="default"/>, it is
referred to as the "join registrar autonomic service agent". referred to as the "Join Registrar Autonomic Service Agent (ASA)".
Other communities use the abbreviation "JRC". Other communities use the abbreviation "JRC".
</dd> </dd>
<dt>LDevID:</dt> <dt>LDevID:</dt>
<dd>A Local Device Identity X.509 certificate <dd>A Local Device Identifier X.509 certificate
installed by the owner of the equipment. This is a term from installed by the owner of the equipment. This is a term from
802.1AR <xref target="IDevID" format="default"/></dd> 802.1AR <xref target="IDevID" format="default"/>.</dd>
<dt>manufacturer:</dt> <dt>manufacturer:</dt>
<dd>the term manufacturer is used <dd>The term manufacturer is used
throughout this document to be the entity that created the throughout this document as the entity that created the
device. This is typically the "original equipment manufacturer" device. This is typically the original equipment manufacturer
or OEM, but in more complex situations it could be a "value added (OEM), but in more complex situations, it could be a value added
retailer" (VAR), or possibly even a systems integrator. In retailer (VAR), or possibly even a systems integrator. In
general, it a goal of BRSKI to eliminate small distinctions general, a goal of BRSKI is to eliminate small distinctions
between different sales channels. The reason for this is between different sales channels. The reason for this is
that it permits a single device, with a uniform firmware load, to that it permits a single device, with a uniform firmware load, to
be shipped directly to all customers. This eliminates costs be shipped directly to all customers. This eliminates costs
for the manufacturer. This also reduces the number of products for the manufacturer. This also reduces the number of products
supported in the field increasing the chance that firmware will supported in the field, increasing the chance that firmware will
be more up to date. be more up to date.
</dd> </dd>
<dt>MASA Audit-Log:</dt> <dt>MASA Audit-Log:</dt>
<dd>An anonymized list of previous owners <dd>An anonymized list of previous owners
maintained by the MASA on a per device (per pledge) maintained by the MASA on a per-device (per-pledge)
basis. Described in <xref target="MASAauditlog" format="default"/>. basis, as described in <xref target="MASAauditlog" format="default"/
>.
</dd> </dd>
<dt>MASA Service:</dt> <dt>MASA Service:</dt>
<dd>A third-party Manufacturer Authorized <dd>A third-party MASA service on the global Internet. The MASA
Signing Authority (MASA) service on the global Internet. The MASA
signs vouchers. It also provides a repository for audit-log signs vouchers. It also provides a repository for audit-log
information of privacy protected bootstrapping events. It does information of privacy-protected bootstrapping events. It does
not track ownership. </dd> not track ownership. </dd>
<dt>nonced:</dt> <dt>nonced:</dt>
<dd>a voucher (or request) that contains a nonce (the normal <dd>A voucher (or request) that contains a nonce (the normal
case).</dd> case).</dd>
<dt>nonceless:</dt> <dt>nonceless:</dt>
<dd>a voucher (or request) that does not <dd>A voucher (or request) that does not
contain a nonce, relying upon accurate clocks for expiration, or contain a nonce and either relies upon accurate clocks for expiratio
which does not expire.</dd> n or
does not expire.</dd>
<dt>offline:</dt> <dt>offline:</dt>
<dd>When an architectural component cannot <dd>When an architectural component cannot
perform realtime communications with a peer, either due to perform real-time communications with a peer, due to
network connectivity or because the peer is turned off, the either network connectivity or the peer being turned off, the
operation is said to be occurring offline.</dd> operation is said to be occurring offline.</dd>
<dt>Ownership Tracker:</dt> <dt>Ownership Tracker:</dt>
<dd>An Ownership Tracker service on <dd>An Ownership Tracker service on
the global Internet. The Ownership Tracker uses business processes the global Internet. The Ownership Tracker uses business processes
to accurately track ownership of all devices shipped against to accurately track ownership of all devices shipped against
domains that have purchased them. Although optional, this component domains that have purchased them. Although optional, this component
allows vendors to provide additional value in cases where their allows vendors to provide additional value in cases where their
sales and distribution channels allow for accurate tracking of sales and distribution channels allow for accurate tracking of
such ownership. Ownership tracking information is indicated in such ownership.
vouchers as described in <xref target="RFC8366" format="default"/></ Tracking information about ownership is indicated in
dd> vouchers, as described in <xref target="RFC8366" format="default"/>.
</dd>
<dt>Pledge:</dt> <dt>Pledge:</dt>
<dd>The prospective (unconfigured) device, which has an <dd>The prospective (unconfigured) device, which has an
identity installed at the factory.</dd> identity installed at the factory.</dd>
<dt>(Public) Key Infrastructure:</dt> <dt>(Public) Key Infrastructure:</dt>
<dd> The collection of systems and <dd> The collection of systems and
processes that sustain the activities of a public key system. processes that sustains the activities of a public key system.
The registrar acts as an The registrar acts as a "Registration Authority"; see
<xref target="RFC5280" format="default"/> and <xref target="RFC5272" <xref target="RFC5280" format="default"/> and <xref
format="default"/> (see target="RFC5272" sectionFormat="of" section="7"/>.</dd>
section 7) "Registration Authority".</dd>
<dt>TOFU:</dt> <dt>TOFU:</dt>
<dd>Trust on First Use. Used similarly to <xref target="RFC7435" forma t="default"/>. This is where a pledge <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 device makes no security decisions but rather simply trusts the
first registrar it is contacted by. This is also known as the first registrar it is contacted by. This is also known as the
"resurrecting duckling" model.</dd> "resurrecting duckling" model.</dd>
<dt>Voucher:</dt> <dt>Voucher:</dt>
<dd>A signed artifact from the MASA <dd>A signed artifact from the MASA
that indicates to a pledge the cryptographic identity of the that indicates the cryptographic identity of the
registrar it should trust. There are different types of vouchers registrar it should trust to a pledge. There are different types of
vouchers
depending on how that trust is asserted. Multiple voucher types are depending on how that trust is asserted. Multiple voucher types are
defined in <xref target="RFC8366" format="default"/></dd> defined in <xref target="RFC8366" format="default"/>.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Scope of solution</name> <name>Scope of Solution</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Support environment</name> <name>Support Environment</name>
<t> <t>
This solution (BRSKI) can support large router This solution (BRSKI) can support large router
platforms with multi-gigabit inter-connections, mounted in controlled platforms with multi-gigabit inter-connections, mounted in controlled
access data centers. But this solution is not exclusive to large equipme nt: access data centers. But this solution is not exclusive to large equipme nt:
it is intended to scale to thousands of devices located in hostile it is intended to scale to thousands of devices located in hostile
environments, such as ISP provided CPE devices which are drop-shipped environments, such as ISP-provided Customer Premises Equipment (CPE) dev
to the end user. The situation where an order is fulfilled from ices 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 distributed warehouse from a common stock and shipped directly to the
target location at the request of a domain owner is explicitly target location at the request of a domain owner is explicitly
supported. That stock ("SKU") could be provided to a number of supported. That stock ("SKU") could be provided to a number of
potential domain owners, and the eventual domain owner will not know potential domain owners, and the eventual domain owner will not know
a-priori which device will go to which location. a priori which device will go to which location.
</t> </t>
<t> <t>
The bootstrapping process can take minutes to complete depending on The bootstrapping process can take minutes to complete depending on
the network infrastructure and device processing speed. The network the network infrastructure and device processing speed. The network
communication itself is not optimized for speed; for privacy reasons, communication itself is not optimized for speed; for privacy reasons,
the discovery process allows for the pledge to avoid announcing its the discovery process allows for the pledge to avoid announcing its
presence through broadcasting. presence through broadcasting.
</t> </t>
<t> <t>
Nomadic or mobile devices often need to acquire credentials to Nomadic or mobile devices often need to acquire credentials to
access the network at the new location. An example of this is access the network at the new location. An example of this is
mobile phone roaming among network operators, or even between mobile phone roaming among network operators, or even between
cell towers. This is usually called handoff. cell towers. This is usually called "handoff".
BRSKI does not provide a low-latency handoff which is usually a BRSKI does not provide a low-latency handoff, which is usually a
requirement in such situations. requirement in such situations.
For these solutions BRSKI can be used to create a relationship For these solutions, BRSKI can be used to create a relationship
(an LDevID) with the "home" domain owner. The resulting credentials (an LDevID) with the "home" domain owner. The resulting credentials
are then used to provide credentials more appropriate for a are then used to provide credentials more appropriate for a
low-latency handoff. low-latency handoff.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Constrained environments</name> <name>Constrained Environments</name>
<t>Questions have been posed as to whether this solution is suitable <t>Questions have been posed as to whether this solution is suitable
in general for Internet of Things (IoT) networks. This depends on the 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> 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 <t>The solution described in this document is aimed in general at
non-constrained (i.e., class 2+ <xref target="RFC7228" format="default"/ >) devices operating on a non-Challenged non-constrained (i.e., Class 2+ <xref target="RFC7228" format="default"/ >) devices operating on a non-challenged
network. The entire solution as described here is not intended to be network. The entire solution as described here is not intended to be
useable as-is by constrained devices operating on challenged networks usable as is by constrained devices operating on challenged networks
(such as 802.15.4 Low-power Lossy Networks (LLN)s).</t> (such as 802.15.4 Low-Power and Lossy Networks (LLNs)).</t>
<t>Specifically, there are protocol aspects described here that might <t>Specifically, there are protocol aspects described here that might
result in congestion collapse or energy-exhaustion of intermediate result in congestion collapse or energy exhaustion of intermediate
battery powered routers in an LLN. Those types of networks should not battery-powered routers in an LLN. Those types of networks should not
use this solution. These limitations are predominately related to the use this solution. These limitations are predominately related to the
large credential and key sizes required for device authentication. large credential and key sizes required for device authentication.
Defining symmetric key techniques that meet the operational Defining symmetric key techniques that meet the operational
requirements is out-of-scope but the underlying protocol operations requirements is out of scope, but the underlying protocol operations
(TLS handshake and signing structures) have sufficient algorithm (TLS handshake and signing structures) have sufficient algorithm
agility to support such techniques when defined.</t> agility to support such techniques when defined.</t>
<t>The imprint protocol described here could, however, be used by <t>The imprint protocol described here could, however, be used by
non-energy constrained devices joining a non-constrained network (for non-energy constrained devices joining a non-constrained network (for
instance, smart light bulbs are usually mains powered, and speak instance, smart light bulbs are usually mains powered and use
802.11). It could also be used by non-constrained devices across a 802.11 wireless technology). It could also be used by non-constrained de
non-energy constrained, but challenged network (such as 802.15.4). The vices across a
non-energy constrained, but challenged, network (such as 802.15.4). The
certificate contents, and the process by which the four certificate contents, and the process by which the four
questions above are resolved do apply to constrained devices. It is questions above are resolved, do apply to constrained devices. It is
simply the actual on-the-wire imprint protocol that could be simply the actual on-the-wire imprint protocol that could be
inappropriate.</t> inappropriate.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Network Access Controls</name> <name>Network Access Controls</name>
<t>This document presumes that network access control has either <t>This document presumes that network access control has
already occurred, is not required, or is integrated by the proxy 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 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 be aware of the details. Although the use of an X.509 IDevID is consiste
Device Identity is consistent with IEEE 802.1AR <xref target="IDevID" fo nt with IEEE 802.1AR <xref target="IDevID" format="default"/>, and allows for al
rmat="default"/>, and allows for alignment with 802.1X ignment with 802.1X
network access control methods, its use here is for pledge network access control methods, its use here is for pledge
authentication rather than network access control. Integrating authentication rather than network access control. Integrating
this protocol with network access control, perhaps as an this protocol with network access control, perhaps as an
Extensible Authentication Protocol (EAP) method Extensible Authentication Protocol (EAP) method
(see <xref target="RFC3748" format="default"/>), is out-of-scope.</t> (see <xref target="RFC3748" format="default"/>), is out of scope for thi s document.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Bootstrapping is not Booting</name> <name>Bootstrapping is Not Booting</name>
<t>This document describes "bootstrapping" as the protocol <t>This document describes "bootstrapping" as the protocol
used to obtain a local trust anchor. It is expected that this used to obtain a local trust anchor. It is expected that this
trust anchor, along with any additional configuration trust anchor, along with any additional configuration
information subsequently installed, is persisted on the device information subsequently installed, is persisted on the device
across system restarts ("booting"). Bootstrapping occurs only across system restarts ("booting"). Bootstrapping occurs only
infrequently such as when a device is transferred to a new infrequently such as when a device is transferred to a new
owner or has been reset to factory default settings.</t> owner or has been reset to factory default settings.</t>
</section> </section>
</section> </section>
<section anchor="PostEnrollment" numbered="true" toc="default"> <section anchor="PostEnrollment" numbered="true" toc="default">
<name>Leveraging the new key infrastructure / next steps</name> <name>Leveraging the New Key Infrastructure / Next Steps</name>
<t> <t>
As a result of the protocol described herein, the bootstrapped devices As a result of the protocol described herein, bootstrapped devices
have the Domain CA trust anchor in common. An end entity certificate h have the domain CA trust anchor in common. An end-entity (EE) certific
as ate has
optionally been issued from the Domain CA. This makes it possible optionally been issued from the domain CA. This makes it possible
to securely deploy functionalities across the domain, e.g:</t> to securely deploy functionalities across the domain; for example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Device management.</li> <li>Device management</li>
<li>Routing authentication.</li> <li>Routing authentication</li>
<li>Service discovery.</li> <li>Service discovery</li>
</ul> </ul>
<t> <t>
The major intended benefit is that it possible to use the credentials The major intended benefit is the ability to use the credentials
deployed by this protocol to secure the Autonomic Control Plane deployed by this protocol to secure the
(ACP) (<xref target="I-D.ietf-anima-autonomic-control-plane" format="d Autonomic Control Plane (ACP) <xref target="RFC8994" format="default"/
efault"/>). >.
</t> </t>
</section> </section>
<section anchor="ANIrequirements" numbered="true" toc="default"> <section anchor="ANIrequirements" numbered="true" toc="default">
<name>Requirements for Autonomic Network Infrastructure (ANI) devices</n ame> <name>Requirements for Autonomic Networking Infrastructure (ANI) Devices </name>
<t> <t>
The BRSKI protocol can be used in a number of environments. Some of The BRSKI protocol can be used in a number of environments. Some of
the options in this document are the result of requirements that the options in this document are the result of requirements that
are out of the ANI scope. This section defines the base are out of the ANI scope. This section defines the base
requirements for ANI devices. requirements for ANI devices.
</t> </t>
<t> <t>
For devices that intend to become part of an Autonomic Network For devices that intend to become part of an ANI
Infrastructure (ANI) <xref target="RFC8993" format="default"/> that includes an
(<xref target="I-D.ietf-anima-reference-model" format="default"/>) tha
t includes an
Autonomic Control Plane Autonomic Control Plane
(<xref target="I-D.ietf-anima-autonomic-control-plane" format="default <xref target="RFC8994" format="default"/>, the
"/>), the BRSKI protocol <bcp14>MUST</bcp14> be implemented.
BRSKI protocol MUST be implemented.
</t> </t>
<t> <t>
The pledge must perform discovery of the proxy as described in The pledge must perform discovery of the proxy as described in
<xref target="discovery" format="default"/> using Generic Autonomic Si <xref target="discovery" format="default"/> using the Discovery Unsoli
gnaling cited
Protocol (GRASP)'s DULL <xref target="I-D.ietf-anima-grasp" format="de Link-Local (DULL) <xref target="RFC8990" format="default"/> M_FLOOD announcem
fault"/> ents of the GeneRic Autonomic Signaling Protocol (GRASP).
M_FLOOD announcements.
</t> </t>
<t> <t>
Upon successfully validating a voucher artifact, a status telemetry Upon successfully validating a voucher artifact, a status telemetry
MUST be returned. See <xref target="pledgestatus" format="default"/>. <bcp14>MUST</bcp14> be returned; see <xref target="pledgestatus" forma t="default"/>.
</t> </t>
<t> <t>
An ANIMA ANI pledge MUST implement the EST automation An ANIMA ANI pledge <bcp14>MUST</bcp14> implement the EST automation
extensions described in <xref target="ESTintegration" format="default" />. extensions described in <xref target="ESTintegration" format="default" />.
They supplement the <xref target="RFC7030" format="default"/> EST to b etter They supplement the EST <xref target="RFC7030" format="default"/> to b etter
support automated devices that do not have an end user. support automated devices that do not have an end user.
</t> </t>
<t> <t>
The ANI Join Registrar Autonomic Service Agent (ASA) MUST support all The ANI Join Registrar ASA <bcp14>MUST</bcp14> support all the BRSKI a
the BRSKI and above listed nd above-listed EST operations.
EST operations.
</t> </t>
<t> <t>
All ANI devices SHOULD support the BRSKI proxy function, using All ANI devices <bcp14>SHOULD</bcp14> support the BRSKI proxy function
circuit proxies over the ACP. (See <xref target="JRCgrasp" format="def , using
ault"/>) Circuit Proxies over the Autonomic Control Plane (ACP) (see <xref targ
et="JRCgrasp" format="default"/>).
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Architectural Overview</name> <name>Architectural Overview</name>
<t>The logical elements of the bootstrapping framework are described in <t>The logical elements of the bootstrapping framework are described in
this section. <xref target="architecturefigure" format="default"/> provide s a simplified overview of the components. this section. <xref target="architecturefigure" format="default"/> provide s a simplified overview of the components.
</t> </t>
<figure anchor="architecturefigure"> <figure anchor="architecturefigure">
<name>Architecture Overview</name> <name>Architecture Overview</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------+ +------------------------+
+--------------Drop Ship----------------| Vendor Service | +--------------Drop-Ship----------------| Vendor Service |
| +------------------------+ | +------------------------+
| | M anufacturer| | | | M anufacturer| |
| | A uthorized |Ownership| | | A uthorized |Ownership|
| | S igning |Tracker | | | S igning |Tracker |
| | A uthority | | | | A uthority | |
| +--------------+---------+ | +--------------+---------+
| ^ | ^
| | BRSKI- | | BRSKI-
V | MASA V | MASA
+-------+ ............................................|... +-------+ ............................................|...
| | . | . | | . | .
| | . +------------+ +-----------+ | . | | . +------------+ +-----------+ | .
| | . | | | | | . | | . | | | | | .
|Pledge | . | Join | | Domain <-------+ . |Pledge | . | Join | | Domain <-------+ .
| | . | Proxy | | Registrar | . | | . | Proxy | | Registrar | .
| <-------->............<-------> (PKI RA) | . | <-------->............<-------> (PKI RA) | .
| | | BRSKI-EST | | . | | | BRSKI-EST | | .
| | . | | +-----+-----+ . | | . | | +-----+-----+ .
|IDevID | . +------------+ | e.g. RFC7030 . |IDevID | . +------------+ | e.g., RFC 7030 .
| | . +-----------------+----------+ . | | . +-----------------+----------+ .
| | . | Key Infrastructure | . | | . | Key Infrastructure | .
| | . | (e.g., PKI Certificate | . | | . | (e.g., PKI CA) | .
+-------+ . | Authority) | . +-------+ . | | .
. +----------------------------+ . . +----------------------------+ .
-------+ . | | .
. . . .
................................................ ................................................
"Domain" components "Domain" Components
]]></artwork> ]]></artwork>
</figure> </figure>
<t>We assume a multi-vendor network. In such an environment there could <t>We assume a multivendor network. In such an environment, there could
be a Manufacturer Service for each manufacturer that supports devices foll be a manufacturer service for each manufacturer that supports devices foll
owing this owing this
document's specification, or an integrator could provide a generic document's specification, or an integrator could provide a generic
service authorized by multiple manufacturers. It is unlikely that an service authorized by multiple manufacturers. It is unlikely that an
integrator could provide Ownership Tracking services for multiple integrator could provide ownership tracking services for multiple
manufacturers due to the required sales channel integrations necessary to manufacturers due to the required sales channel integrations necessary to
track ownership.</t> track ownership.</t>
<t>The domain is the managed network infrastructure with a Key Infrastruct
ure the pledge is <t>The domain is the managed network infrastructure with a key infrastruct
ure that the pledge is
joining. The domain provides initial device connectivity joining. The domain provides initial device connectivity
sufficient for bootstrapping through a proxy. The domain sufficient for bootstrapping through a proxy. The domain
registrar authenticates the pledge, makes authorization decisions, and dis tributes registrar authenticates the pledge, makes authorization decisions, and dis tributes
vouchers obtained from the Manufacturer Service. Optionally the registrar vouchers obtained from the manufacturer service. Optionally, the registrar
also acts as a PKI Certification Authority.</t> also acts as a PKI CA.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Behavior of a Pledge</name> <name>Behavior of a Pledge</name>
<t>The pledge goes through a series of steps, which are outlined here <t>The pledge goes through a series of steps, which are outlined here
at a high level.</t> at a high level.</t>
<figure anchor="pledgestatusfigure"> <figure anchor="pledgestatusfigure">
<name>Pledge State Diagram</name> <name>Pledge State Diagram</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
------------ ------------
/ Factory \ / Factory \
\ default / \ default /
skipping to change at line 602 skipping to change at line 617
| | (3) Request | | | (3) Request |
| | Join | | | Join |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (4) Imprint | | | (4) Imprint |
^------------+ | ^------------+ |
| Bad MASA +------+-------+ | Bad MASA +------+-------+
| response | send Voucher Status Telemetry | response | send Voucher Status Telemetry
| +------v-------+ | +------v-------+
| | (5) Enroll |<---+ (non-error HTTP codes ) | | (5) Enroll |<---+ (non-error HTTP codes)
^------------+ |\___/ (e.g. 202 'Retry-After') ^------------+ |\___/ (e.g., 202 "Retry-After")
| Enroll +------+-------+ | Enroll +------+-------+
| Failure | | failure |
| -----v------ | -----v------
| / Enrolled \ | / Enrolled \
^------------+ | ^------------+ |
Factory \------------/ Factory \------------/
reset reset
]]></artwork> ]]></artwork>
</figure> </figure>
<t>State descriptions for the pledge are as follows:</t> <t>State descriptions for the pledge are as follows:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Discover a communication channel to a registrar.</li> <li>Discover a communication channel to a registrar.</li>
<li>Identify itself. This is done by presenting an X.509 IDevID <li>Identify itself. This is done by presenting an X.509 IDevID
credential to the discovered registrar (via the proxy) in a TLS credential to the discovered registrar (via the proxy) in a TLS
handshake. (The registrar credentials are only provisionally handshake. (The registrar credentials are only provisionally
accepted at this time).</li> accepted at this time.)</li>
<li>Request to join the discovered registrar. A unique nonce is <li>Request to join the discovered registrar. A unique nonce is
included ensuring that any responses can be associated with this included, ensuring that any responses can be associated with thi s
particular bootstrapping attempt.</li> particular bootstrapping attempt.</li>
<li>Imprint on the registrar. This requires verification of the <li>Imprint on the registrar. This requires verification of the
manufacturer-service-provided voucher. A voucher contains suffic ient manufacturer-service-provided voucher. A voucher contains suffic ient
information for the pledge to complete authentication of a information for the pledge to complete authentication of a
registrar. This document details this step in depth. registrar. This document details this step in depth.
</li> </li>
<li>Enroll. After imprint an authenticated TLS (HTTPS) connection exis <li>Enroll. After imprint, an authenticated TLS (HTTPS) connection exi
ts sts
between pledge and registrar. between the pledge and registrar.
Enrollment over Secure Transport (EST) <xref target="RFC7030" format EST <xref target="RFC7030" format="default"/> can then be used to ob
="default"/> can then be used to obtain a domain tain a domain
certificate from a registrar.</li> certificate from a registrar.</li>
</ol> </ol>
<t> <t>
The pledge is now a member of, and can be managed by, the The pledge is now a member of, and can be managed by, the
domain and will only repeat the discovery aspects of bootstrapping domain and will only repeat the discovery aspects of bootstrapping
if it is returned to factory default settings. if it is returned to factory default settings.
</t> </t>
<t> <t>
This specification details integration with EST enrollment so that ple dges can This specification details integration with EST enrollment so that ple dges can
optionally obtain a locally issued certificate, although any optionally obtain a locally issued certificate, although any
Representational State Transfer (REST) (see <xref target="REST" format ="default"/>) Representational State Transfer (REST) (see <xref target="REST" format ="default"/>)
interface could be integrated in future work. interface could be integrated in future work.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Secure Imprinting using Vouchers</name> <name>Secure Imprinting Using Vouchers</name>
<t>A voucher is a cryptographically protected artifact (using a digital signature) to the pledge <t>A voucher is a cryptographically protected artifact (using a digital signature) to the pledge
device authorizing a zero-touch imprint on the registrar device authorizing a zero-touch imprint on the registrar
domain. </t> domain. </t>
<t>The format and cryptographic mechanism of vouchers is described in <t>The format and cryptographic mechanism of vouchers is described in
detail in <xref target="RFC8366" format="default"/>.</t> detail in <xref target="RFC8366" format="default"/>.</t>
<t>Vouchers provide a flexible mechanism to secure imprinting: the <t>Vouchers provide a flexible mechanism to secure imprinting: the
pledge device only imprints when a voucher can be validated. pledge device only imprints when a voucher can be validated.
At the lowest security levels the MASA can indiscriminately issue At the lowest security levels, the MASA can indiscriminately issue
vouchers and log claims of ownership by domains. At the highest securit y vouchers and log claims of ownership by domains. At the highest securit y
levels issuance of vouchers can be integrated with complex sales channel levels, issuance of vouchers can be integrated with complex sales channe l
integrations that are beyond the scope of this document. The sales integrations that are beyond the scope of this document. The sales
channel integration would verify actual (legal) ownership of the channel integration would verify actual (legal) ownership of the
pledge by the domain. pledge by the domain.
This This
provides the flexibility for a number of use cases via a single provides the flexibility for a number of use cases via a single
common protocol mechanism on the pledge and registrar devices that common protocol mechanism on the pledge and registrar devices that
are to be widely deployed in the field. The MASA services have are to be widely deployed in the field. The MASA services have
the flexibility to leverage either the currently defined claim the flexibility to either leverage the currently defined claim
mechanisms or to experiment with higher or lower security levels. mechanisms or experiment with higher or lower security levels.
</t> </t>
<t> <t>
Vouchers provide a signed but non-encrypted communication channel amon g Vouchers provide a signed but non-encrypted communication channel amon g
the pledge, the MASA, and the registrar. The registrar maintains the pledge, the MASA, and the registrar. The registrar maintains
control over the transport and policy decisions, allowing the control over the transport and policy decisions, allowing the
local security policy of the domain network to be enforced. local security policy of the domain network to be enforced.
</t> </t>
</section> </section>
<section anchor="IDevIDextension" numbered="true" toc="default"> <section anchor="IDevIDextension" numbered="true" toc="default">
<name>Initial Device Identifier</name> <name>Initial Device Identifier</name>
<t> <t>
Pledge authentication and pledge voucher-request signing is via Pledge authentication and pledge voucher-request signing is via
a PKIX-shaped certificate installed a PKIX-shaped certificate installed
during the manufacturing process. This is the 802.1AR Initial during the manufacturing process. This is the 802.1AR
Device Identifier (IDevID), and it IDevID, and it
provides a basis for authenticating the pledge during provides a basis for authenticating the pledge during
the protocol exchanges described here. the protocol exchanges described here.
There is no requirement for a common root PKI hierarchy. There is no requirement for a common root PKI hierarchy.
Each device manufacturer can generate its own root certificate. Each device manufacturer can generate its own root certificate.
Specifically, the IDevID enables: Specifically, the IDevID enables:
</t> </t>
<ol spacing="normal" type="1"> <ul>
<li> <li>
Uniquely identifying the pledge by the Distinguished Name (DN) Uniquely identifying the pledge by the Distinguished Name (DN)
and subjectAltName (SAN) parameters in the IDevID. The and subjectAltName (SAN) parameters in the IDevID. The
unique identification of a pledge in the voucher objects are deriv ed unique identification of a pledge in the voucher objects are deriv ed
from those parameters as described below. <xref target="idevidpriv acy" format="default"/> discusses privacy implications of the identifier. from those parameters as described below. <xref target="idevidpriv acy" format="default"/> discusses privacy implications of the identifier.
</li> </li>
<li> <li>
Provides a cryptographic authentication of the pledge to the Providing a cryptographic authentication of the pledge to the
Registrar (see <xref target="pledgeauthorization" format="default" registrar (see <xref target="pledgeauthorization" format="default"
/>). />).
</li> </li>
<li> <li>
Secure auto-discovery of the pledge's MASA by the registrar Securing auto-discovery of the pledge's MASA by the registrar
(see <xref target="obtainmasaurl" format="default"/>). (see <xref target="obtainmasaurl" format="default"/>).
</li> </li>
<li> <li>
Signing of voucher-request by the pledge's IDevID Signing of a voucher-request by the pledge's IDevID
(see <xref target="voucher-request" format="default"/>). (see <xref target="voucher-request" format="default"/>).
</li> </li>
<li> <li>
Provides a cryptographic authentication of the pledge to the Providing a cryptographic authentication of the pledge to the
MASA (see <xref target="MASAassertion" format="default"/>). MASA (see <xref target="MASAassertion" format="default"/>).
</li> </li>
</ol> </ul>
<t> <t>
Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of Sections 7.2.13 (2009 edition) and 8.10.3 (2018 edition) of
<xref target="IDevID" format="default"/> discusses keyUsage and <xref target="IDevID" format="default"/> discuss keyUsage and
extendedKeyUsage extensions in the IDevID certificate. extendedKeyUsage extensions in the IDevID certificate.
<xref target="IDevID" format="default"/> acknowledges that adding rest rictions <xref target="IDevID" format="default"/> acknowledges that adding rest rictions
in the certificate limits applicability of these long-lived in the certificate limits applicability of these long-lived
certificates. This specification emphasizes this point, and certificates. This specification emphasizes this point and
therefore RECOMMENDS that no key usage restrictions be included. therefore RECOMMENDS that no key usage restrictions be included.
This is consistent with <xref target="RFC5280" format="default"/> sect This is consistent with <xref target="RFC5280" sectionFormat="comma"
ion 4.2.1.3, section="4.2.1.3"/>,
which does not which does not
require key usage restrictions for end entity certificates. require key usage restrictions for end-entity certificates.
</t> </t>
<section anchor="PledgeIdentification" numbered="true" toc="default"> <section anchor="PledgeIdentification" numbered="true" toc="default">
<name>Identification of the Pledge</name> <name>Identification of the Pledge</name>
<t> <t>
In the context of BRSKI, pledges have a 1:1 relationship In the context of BRSKI, pledges have a 1:1 relationship
with a "serial-number". with a "serial-number".
This serial-number is used both in the "serial-number" This serial-number is used both in the serial-number
field of voucher or voucher-requests (see <xref target="voucher-requ field of a voucher or voucher-requests (see <xref target="voucher-re
est" format="default"/>) quest" format="default"/>)
and in local policies on registrar or MASA and in local policies on the registrar or MASA
(see <xref target="ProtocolDetails" format="default"/>). (see <xref target="ProtocolDetails" format="default"/>).
</t> </t>
<t>
There is a (certificate) serialNumber field defined in <xref target="RFC5280"
sectionFormat="comma"
section="4.1.2.2"/>. In ASN.1, this is referred to as the
CertificateSerialNumber. This field is NOT relevant to this
specification. Do not confuse this field with the serial-number
defined by this document, or by <xref target="IDevID" format="default"/> and
<xref target="RFC4519" sectionFormat="comma" section="2.31"/>.
</t>
<t>
The device serial number is defined in <xref target="RFC5280" section="A.1" sect
ionFormat="of"/> as the X520SerialNumber, with the OID tag id-at-serialNumber.
</t>
<t>
The device <em>serialNumber</em> field (X520SerialNumber) is used as follows
by the pledge to build the <strong>serial-number</strong> that is placed in t
he
voucher-request. In order to build it, the fields need to be
converted into a serial-number of "type string".
</t>
<t> <t>
The serialNumber field is defined in <xref target="RFC5280" format=" An example of a printable form of the serialNumber field
default"/>. is provided in <xref target="RFC4519" sectionFormat="comma" section=
That specification allows for the field to be omitted if there is "2.31"/> ("WI-3005").
a good technical reason. IDevID certificates for use
with this protocol are REQUIRED to include the "serialNumber" attrib
ute with the device's
unique serial number
(from <xref target="IDevID" format="default"/> section 7.2.8, and
<xref target="RFC5280" format="default"/> section 4.1.2.2's list of
standard
attributes).
</t>
<t>
The serialNumber field is used as follows by the pledge to build the
"serial-number" that is placed in the voucher-request.
In order to build it, the fields need to be converted into a
serial-number of "type string".
</t>
<t>
An example of a printable form of the "serialNumber" field
is provided in <xref target="RFC4519" format="default"/> section 2.3
1 ("WI-3005").
That section further provides equality and syntax attributes. That section further provides equality and syntax attributes.
</t> </t>
<t> <t>
Due to the reality of existing device identity provisioning Due to the reality of existing device identity provisioning
processes, some processes, some
manufacturers have stored serial-numbers in other manufacturers have stored serial-numbers in other
fields. Registrar's SHOULD be configurable, on a per-manufacturer fields.
Registrars <bcp14>SHOULD</bcp14> be configurable, on a per-manufactur
er
basis, to look for serial-number equivalents in other fields. basis, to look for serial-number equivalents in other fields.
</t> </t>
<t> <t>
As explained in <xref target="RequestVoucherFromMASA" format="defaul As explained in <xref target="RequestVoucherFromMASA" format="defaul
t"/> the Registrar MUST extract the t"/>, the registrar <bcp14>MUST</bcp14> again extract the
serial-number again itself from the pledge's TLS certificate. It serialNumber itself from the pledge's TLS certificate. It
can consult the serial-number in the pledge-request if there are can consult the serial-number in the pledge request if there is
any possible confusion about the source of the serial-number. any possible confusion about the source of the serial-number.
</t> </t>
</section> </section>
<section anchor="MASAURL" numbered="true" toc="default"> <section anchor="MASAURL" numbered="true" toc="default">
<name>MASA URI extension</name> <name>MASA URI Extension</name>
<t> <t>
This document defines a new PKIX non-critical certificate This document defines a new PKIX non-critical certificate
extension to carry the MASA URI. extension to carry the MASA URI.
This extension is intended to be used in the IDevID certificate. This extension is intended to be used in the IDevID certificate.
The URI is represented as described in Section 7.4 of <xref target=" The URI is represented as described in <xref
RFC5280" format="default"/>. target="RFC5280" sectionFormat="of" section="7.4"/>.
</t> </t>
<t> <t>
The URI provides the authority information. The URI provides the authority information.
The BRSKI "/.well-known" tree (<xref target="RFC5785" format="defaul t"/>) is The BRSKI "/.well-known" tree <xref target="RFC8615" format="default "/> is
described in <xref target="ProtocolDetails" format="default"/>. described in <xref target="ProtocolDetails" format="default"/>.
</t> </t>
<t> <t>
A complete URI MAY be in this extension, including the 'scheme', 'au thority', and 'path', A complete URI <bcp14>MAY</bcp14> be in this extension, including th e "scheme", "authority", and "path".
The complete URI will typically be used in diagnostic or The complete URI will typically be used in diagnostic or
experimental situations. experimental situations.
Typically, (and in consideration to constrained systems), this
SHOULD be reduced to only the 'authority', in which Typically (and in consideration to constrained systems), this
<bcp14>SHOULD</bcp14> be reduced to only the "authority", in which
case a scheme of "https://" case a scheme of "https://"
(<xref target="RFC7230" format="default"/> section 2.7.3) (see <xref target="RFC7230" sectionFormat="comma" section="2.7.3"/>)
and 'path' of "/.well-known/est" is to be and a "path" of "/.well-known/brski" is to be
assumed. assumed.
</t> </t>
<t> <t>
The registrar can assume that only the 'authority' is present in The registrar can assume that only the "authority" is present in
the extension, if there are no slash ("/") characters in the the extension, if there are no slash ("/") characters in the
extension. extension.
</t> </t>
<t> <t>
Section 7.4 of <xref target="RFC5280" format="default"/> calls out v <xref target="RFC5280" sectionFormat="of" section="7.4"/> calls out
arious various
schemes that MUST be supported, including LDAP, HTTP and FTP. schemes that <bcp14>MUST</bcp14> be supported, including the Lightwe
However, the registrar MUST use HTTPS for the BRSKI-MASA connection. ight Directory Access Protocol (LDAP), HTTP, and FTP.
However, the registrar <bcp14>MUST</bcp14> use HTTPS for the BRSKI-M
ASA connection.
</t> </t>
<t>The new extension is identified as follows:</t> <t>The new extension is identified as follows:</t>
<figure anchor="masaurlmodule"> <figure anchor="masaurlmodule">
<name>MASAURL ASN.1 Module</name> <name>MASAURL ASN.1 Module</name>
<sourcecode name="" type="" markers="true"><![CDATA[
<sourcecode name="" type="asn.1" markers="true"><![CDATA[
MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-MASAURLExtn2016(TBD) } id-mod(0) id-mod-MASAURLExtn2016(96) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
EXTENSION EXTENSION
FROM PKIX-CommonTypes-2009 FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
skipping to change at line 832 skipping to change at line 858
id-pe FROM PKIX1Explicit-2009 id-pe FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ; id-mod-pkix1-explicit-02(51) } ;
MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } MASACertExtensions EXTENSION ::= { ext-MASAURL, ... }
ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax
IDENTIFIED BY id-pe-masa-url } IDENTIFIED BY id-pe-masa-url }
id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe 32 }
MASAURLSyntax ::= IA5String MASAURLSyntax ::= IA5String
END END
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The choice of id-pe is based on guidance found in Section 4.2.2 of
[RFC5280], "These extensions may be used to direct applications to on- <t>The choice of id-pe is based on guidance found in <xref
line 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 precisel y information about the issuer or the subject". The MASA URL is precisel y
that: online information about the particular subject. </t> that: online information about the particular subject. </t>
</section> </section>
</section> </section>
<section anchor="flow" numbered="true" toc="default"> <section anchor="flow" numbered="true" toc="default">
<name>Protocol Flow</name> <name>Protocol Flow</name>
<t>A representative flow is shown in <t>A representative flow is shown in
<xref target="protocoltimesequencefigure" format="default"/></t> <xref target="protocoltimesequencefigure" format="default"/>.</t>
<figure anchor="protocoltimesequencefigure"> <figure anchor="protocoltimesequencefigure">
<name>Protocol Time Sequence Diagram</name> <name>Protocol Time Sequence Diagram</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Vendor | | Pledge | | Circuit | | Domain | | Vendor |
| | | Join | | Registrar | | Service | | | | Join | | Registrar | | Service |
| | | Proxy | | (JRC) | | (MASA) | | | | Proxy | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| | | Internet | | | | Internet |
[discover] | | | [discover] | | |
|<-RFC4862 IPv6 addr | | | |<-RFC 4862 IPv6 addr | | |
|<-RFC3927 IPv4 addr | Appendix A | Legend | |<-RFC 3927 IPv4 addr | Appendix A | Legend |
|-++++++++++++++++++->| | C - circuit | |-++++++++++++++++++->| | C - Circuit |
| optional: mDNS query| Appendix B | join proxy | | optional: mDNS query| Appendix B | Join Proxy |
| RFC6763/RFC6762 (+) | | P - provisional | | RFCs 6763/6762 (+) | | P - Provisional TLS|
|<-++++++++++++++++++-| | TLS connection | |<-++++++++++++++++++-| | Connection |
| GRASP M_FLOOD | | | | GRASP M_FLOOD | | |
| periodic broadcast| | | | periodic broadcast| | |
[identity] | | | [identity] | | |
|<------------------->C<----------------->| | |<------------------->C<----------------->| |
| TLS via the Join Proxy | | | TLS via the Join Proxy | |
|<--Registrar TLS server authentication---| | |<--Registrar TLS server authentication---| |
[PROVISIONAL accept of server cert] | | [PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| | P---X.509 client authentication---------->| |
[request join] | | [request join] | |
P---Voucher Request(w/nonce for voucher)->| | P---Voucher-Request(w/nonce for voucher)->| |
P /------------------- | | P /------------------- | |
P | [accept device?] | P | [accept device?] |
P | [contact Vendor] | P | [contact vendor] |
P | |--Pledge ID-------->| P | |--Pledge ID-------->|
P | |--Domain ID-------->| P | |--Domain ID-------->|
P | |--optional:nonce--->| P | |--optional:nonce--->|
P optional: | [extract DomainID] P optional: | [extract DomainID]
P can occur in advance | [update audit log] P can occur in advance | [update audit-log]
P if nonceleess | | P if nonceless | |
P | |<- voucher ---------| P | |<- voucher ---------|
P \------------------- | w/nonce if provided| P \------------------- | w/nonce if provided|
P<------voucher---------------------------| | P<------voucher---------------------------| |
[imprint] | | [imprint] | |
|-------voucher status telemetry--------->| | |-------voucher status telemetry--------->| |
| |<-device audit log--| | |<-device audit-log--|
| [verify audit log and voucher] | | [verify audit-log and voucher] |
|<--------------------------------------->| | |<--------------------------------------->| |
[enroll] | | [enroll] | |
| Continue with RFC7030 enrollment | | | Continue with enrollment using now | |
| using now bidirectionally authenticated | | | bidirectionally authenticated TLS | |
| TLS session. | | | session per RFC 7030. | |
[enrolled] | | [enrolled] | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
On initial bootstrap, a new device (the pledge) uses a local service On initial bootstrap, a new device (the pledge) uses a local service
autodiscovery (GRASP or mDNS) to locate a join proxy. The auto-discovery (the GeneRic Autonomic Signaling Protocol (GRASP) or Mu
join proxy connects the pledge to a local registrar (the JRC). lticast DNS (mDNS)) to locate a Join Proxy. The
Join Proxy connects the pledge to a local registrar (the JRC).
</t> </t>
<t> <t>
Having found a candidate registrar, the fledgling pledge sends Having found a candidate registrar, the fledgling pledge sends
some information about itself to the registrar, including its some information about itself to the registrar, including its
serial number in the form of a voucher request and its device identity serial number in the form of a voucher-request and its
certificate (IDevID) as part of the TLS session. IDevID certificate as part of the TLS session.
</t> </t>
<t> <t>
The registrar can determine whether it expected such a device to The registrar can determine whether it expected such a device to
appear, and locates a MASA. The location of the MASA is usually found in 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 an extension in the IDevID. Having determined that the MASA is
suitable, the entire information from the initial voucher request suitable, the entire information from the initial voucher-request
(including device serial number) is transmitted over the internet in a (including the device's serial number) is transmitted over the Interne
TLS protected channel to the manufacturer, along with information abou t in a
t TLS-protected channel to the manufacturer, along with information abou
t
the registrar/owner. the registrar/owner.
</t> </t>
<t> <t>
The manufacturer can then apply policy based on the provided The manufacturer can then apply policy based on the provided
information, as well as other sources of information (such as sales information, as well as other sources of information (such as sales
records), to decide whether records), to decide whether
to approve the claim by the registrar to own the device; if the claim 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 is accepted, a voucher is issued that directs the device to accept its
new owner. new owner.
</t> </t>
<t> <t>
The voucher is returned to the registrar, but not immediately to The voucher is returned to the registrar, but not immediately to
the device -- the registrar has an opportunity to examine the the device -- the registrar has an opportunity to examine the
voucher, the MASA's audit-logs, and other sources of information to voucher, the MASA's audit-logs, and other sources of information to
determine whether the device has been tampered with, and whether determine whether the device has been tampered with and whether
the bootstrap should be accepted. the bootstrap should be accepted.
</t> </t>
<t> <t>
No filtering of information is possible in the signed voucher, so No filtering of information is possible in the signed voucher, so
this is a binary yes-or-no decision. If the registrar accepts this is a binary yes-or-no decision. After the registrar has applied
the voucher as a proper one for its device, the voucher is returned any local policy to the voucher, if it accepts the voucher, then the voucher is
to the pledge for imprinting. returned to the pledge for imprinting.
</t> </t>
<t> <t>
The voucher also includes a trust anchor that the pledge uses as The voucher also includes a trust anchor that the pledge uses to
representing the owner. This is used to successfully bootstrap from a represent the owner.
n environment This is used to successfully bootstrap from an environment
where only the manufacturer has built-in trust by the where only the manufacturer has built-in trust by the
device into an environment where the owner now has a PKI footprint on the device to an environment where the owner now has a PKI footprint on th e
device. device.
</t> </t>
<t> <t>
When BRSKI is followed with EST this single footprint is further When BRSKI is followed with EST, this single footprint is further
leveraged into the full owner's PKI and a LDevID for the leveraged into the full owner's PKI and an LDevID for the
device. Subsequent reporting steps provide flows of information to device. Subsequent reporting steps provide flows of information to
indicate success/failure of the process. indicate success/failure of the process.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Architectural Components</name> <name>Architectural Components</name>
<section anchor="pledge-overview" numbered="true" toc="default"> <section anchor="pledge-overview" numbered="true" toc="default">
<name>Pledge</name> <name>Pledge</name>
<t> <t>
The pledge is the device that is attempting to join. The pledge is the device that is attempting to join. It is assumed t
The pledge is assumed to talk to the Join Proxy using link-local net hat
work the pledge talks to the Join Proxy using link-local network
connectivity. In most cases, the pledge has no other connectivity. In most cases, the pledge has no other
connectivity until the pledge completes the enrollment process connectivity until the pledge completes the enrollment process
and receives some kind of network credential. and receives some kind of network credential.
</t> </t>
</section> </section>
<section anchor="proxy-overview" numbered="true" toc="default"> <section anchor="proxy-overview" numbered="true" toc="default">
<name>Join Proxy</name> <name>Join Proxy</name>
<t> <t>
The join proxy provides HTTPS connectivity between the The Join Proxy provides HTTPS connectivity between the
pledge and the registrar. A circuit proxy mechanism is pledge and the registrar. A Circuit Proxy mechanism is
described in <xref target="proxydetails" format="default"/>. Additio nal described in <xref target="proxydetails" format="default"/>. Additio nal
mechanisms, including a CoAP mechanism and a stateless mechanisms, including a Constrained Application Protocol (CoAP) mech
IPIP mechanism are the subject of future work. anism and a stateless
IP in IP (IPIP) mechanism, are the subject of future work.
</t> </t>
</section> </section>
<section anchor="registrar-overview" numbered="true" toc="default"> <section anchor="registrar-overview" numbered="true" toc="default">
<name>Domain Registrar</name> <name>Domain Registrar</name>
<t> <t>
The domain's registrar operates as the BRSKI-MASA client when The domain's registrar operates as the BRSKI-MASA client when
requesting vouchers from the MASA (see <xref target="brskimasatls" f ormat="default"/>). The registrar requesting vouchers from the MASA (see <xref target="brskimasatls" f ormat="default"/>). The registrar
operates as the BRSKI-EST server when pledges request operates as the BRSKI-EST server when pledges request
vouchers (see <xref target="brskiesttls" format="default"/>). The re gistrar operates as the BRSKI-EST server vouchers (see <xref target="brskiesttls" format="default"/>). The re gistrar operates as the BRSKI-EST server
"Registration Authority" if the pledge requests an end entity certif icate "Registration Authority" if the pledge requests an end-entity certif icate
over the BRSKI-EST connection (see <xref target="ESTintegration" forma t="default"/>). over the BRSKI-EST connection (see <xref target="ESTintegration" forma t="default"/>).
</t> </t>
<t> <t>
The registrar uses an Implicit Trust Anchor database for The registrar uses an Implicit Trust Anchor database for
authenticating the BRSKI-MASA connection's MASA TLS Server Certifica authenticating the BRSKI-MASA connection's MASA TLS server certifica
te. te.
Configuration or distribution of trust anchors is out-of-scope Configuration or distribution of trust anchors is out of scope
for this specification. for this specification.
</t> </t>
<t> <t>
The registrar uses a different Implicit Trust Anchor database for The registrar uses a different Implicit Trust Anchor database for
authenticating the BRSKI-EST connection's Pledge TLS Client Certific ate. authenticating the BRSKI-EST connection's pledge TLS Client Certific ate.
Configuration or distribution of the BRSKI-EST client trust Configuration or distribution of the BRSKI-EST client trust
anchors is out-of-scope of this specification. Note that the anchors is out of scope of this specification. Note that the
trust anchors trust anchors
in/excluded from the database will affect which manufacturers' devic in / excluded from the database will affect which manufacturers' dev
es are ices are
acceptable to the registrar as pledges, and can also be used to limi acceptable to the registrar as pledges, and they can also be used to
t the limit the
set of MASAs that are trusted for enrollment. set of MASAs that are trusted for enrollment.
</t> </t>
</section> </section>
<section anchor="masa-overview" numbered="true" toc="default"> <section anchor="masa-overview" numbered="true" toc="default">
<name>Manufacturer Service</name> <name>Manufacturer Service</name>
<t> <t>
The Manufacturer Service provides two logically separate functions: The manufacturer service provides two logically separate functions:
the Manufacturer Authorized Signing Authority (MASA) described in the MASA as described in Sections
<xref target="RequestVoucherFromMASA" format="default"/> and <xref target="RequestVoucherFromMASA" format="counter"/> and
<xref target="VoucherResponse" format="default"/>, <xref target="VoucherResponse" format="counter"/>
and an ownership tracking/auditing function described and an ownership tracking/auditing function as described
in <xref target="pledgestatus" format="default"/> in Sections <xref target="pledgestatus" format="counter"/>
and <xref target="authzLogRequest" format="default"/>. and <xref target="authzLogRequest" format="counter"/>.
</t> </t>
</section> </section>
<section anchor="pki-overview" numbered="true" toc="default"> <section anchor="pki-overview" numbered="true" toc="default">
<name>Public Key Infrastructure (PKI)</name> <name>Public Key Infrastructure (PKI)</name>
<t> <t>
The Public Key Infrastructure (PKI) administers certificates for the The Public Key Infrastructure (PKI) administers certificates for the
domain of concern, providing the trust anchor(s) for it and domain of concern, providing the trust anchor(s) for it and
allowing enrollment of pledges with domain certificates. allowing enrollment of pledges with domain certificates.
</t> </t>
<t> <t>
The voucher provides a method for the distribution of a The voucher provides a method for the distribution of a
single PKI trust anchor (as the "pinned-domain-cert"). A distributio n single PKI trust anchor (as the "pinned-domain-cert"). A distributio n
of the full set of current trust anchors is possible using the of the full set of current trust anchors is possible using the
optional EST integration. optional EST integration.
</t> </t>
<t> <t>
The domain's registrar acts as an <xref target="RFC5272" format="def The domain's registrar acts as a
ault"/> Registration Authority <xref target="RFC5272" format="default"/>, re
Registration Authority, requesting certificates for pledges from questing certificates for pledges from
the Key Infrastructure. the PKI.
</t> </t>
<t> <t>
The expectations of the PKI are unchanged from EST <xref target="RFC 7030" format="default"/>. This document does The expectations of the PKI are unchanged from EST <xref target="RFC 7030" format="default"/>. This document does
not place any additional architectural requirements on the Public Ke not place any additional architectural requirements on the PKI.
y
Infrastructure.
</t> </t>
</section> </section>
</section> </section>
<section anchor="certificatevalidaty" numbered="true" toc="default"> <section anchor="certificatevalidaty" numbered="true" toc="default">
<name>Certificate Time Validation</name> <name>Certificate Time Validation</name>
<section anchor="timeunknown" numbered="true" toc="default"> <section anchor="timeunknown" numbered="true" toc="default">
<name>Lack of realtime clock</name> <name>Lack of Real-Time Clock</name>
<t> <t>
Many devices when bootstrapping do not have knowledge of the When bootstrapping, many devices do not have knowledge of the
current time. Mechanisms such as Network Time Protocols cannot be current time. Mechanisms such as Network Time Protocols cannot be
secured until bootstrapping is complete. Therefore bootstrapping is secured until bootstrapping is complete. Therefore, bootstrapping is
defined with a framework that does not require knowledge of the curr ent defined with a framework that does not require knowledge of the curr ent
time. A pledge MAY ignore all time stamps in the voucher and time. A pledge <bcp14>MAY</bcp14> ignore all time stamps in the vou cher and
in the certificate validity periods if it does not know in the certificate validity periods if it does not know
the current time. the current time.
</t> </t>
<t> <t>
The pledge is exposed to dates in the following five places: The pledge is exposed to dates in the following five places:
registrar certificate notBefore, registrar certificate registrar certificate notBefore, registrar certificate
notAfter, notAfter,
voucher created-on, and voucher expires-on. voucher created-on, and voucher expires-on.
Additionally, CMS signatures contain a signingTime. Additionally, Cryptographic Message Syntax (CMS) signatures contain a signingTime.
</t> </t>
<t> <t>
A pledge with a real time clock in which it has confidence, A pledge with a real-time clock in which it has confidence
MUST check the above time fields in all certificates and <bcp14>MUST</bcp14> check the above time fields in all certificates
and
signatures that it processes. signatures that it processes.
</t> </t>
<t> <t>
If the voucher contains a nonce If the voucher contains a nonce,
then the pledge MUST confirm the nonce matches the original then the pledge <bcp14>MUST</bcp14> confirm the nonce matches the or
iginal
pledge voucher-request. This ensures the voucher is fresh. pledge voucher-request. This ensures the voucher is fresh.
See <xref target="RequestVoucherFromRegistrar" format="default"/>. See <xref target="RequestVoucherFromRegistrar" format="default"/>.
</t> </t>
</section> </section>
<section anchor="infinitelifetime" numbered="true" toc="default"> <section anchor="infinitelifetime" numbered="true" toc="default">
<name>Infinite Lifetime of IDevID</name> <name>Infinite Lifetime of IDevID</name>
<t> <t>
<xref target="RFC5280" format="default"/> explains that Long-lived pledge certificates "<bcp14>SHOULD</bcp14> be assigned th
long lived pledge certificates "SHOULD be assigned the e
GeneralizedTime value of 99991231235959Z" for the notAfter field. GeneralizedTime value of 99991231235959Z" for the notAfter field as
explained in <xref target="RFC5280" format="default"/>.
</t> </t>
<t> <t>
Some deployed IDevID management systems are not compliant Some deployed IDevID management systems are not compliant
with the 802.1AR requirement for infinite lifetimes, and with the 802.1AR requirement for infinite lifetimes and
put in typical &lt;= 3 year certificate lifetimes. are put in typical &lt;= 3 year certificate lifetimes.
Registrars SHOULD be configurable on a per-manufacturer basis Registrars <bcp14>SHOULD</bcp14> be configurable on a per-manufactur
to ignore pledge lifetimes when the pledge did not follow the RFC528 er basis
0 to ignore pledge lifetimes when the pledge does not follow the recom
recommendations. mendations in <xref
target="RFC5280"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="cloudregistrar" numbered="true" toc="default"> <section anchor="cloudregistrar" numbered="true" toc="default">
<name>Cloud Registrar</name> <name>Cloud Registrar</name>
<t> <t>
There exist operationally open networks wherein devices gain There exist operationally open networks wherein devices gain
unauthenticated access to the Internet at large. unauthenticated access to the Internet at large.
In these use cases the In these use cases, the
management domain for the device needs to be discovered within 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 larger Internet. The case where a device can boot and get access to
larger Internet are less likely within the ANIMA ACP scope but may a larger Internet is less likely within the ANIMA ACP scope but may
be more important in the future. In the ANIMA ACP scope, new be more important in the future. In the ANIMA ACP scope, new
devices will be quarantined behind a Join Proxy. devices will be quarantined behind a Join Proxy.
</t> </t>
<t> <t>
There are additionally some greenfield situations involving an Additionally, there are some greenfield situations involving an
entirely new installation where a device may have some kind of entirely new installation where a device may have some kind of
management uplink that it can use (such as via 3G network for management uplink that it can use (such as via a 3G network, for
instance). In such a future situation, the device might use instance). In such a future situation, the device might use
this management interface to learn that it should this management interface to learn that it should
configure itself to become the local registrar. configure itself to become the local registrar.
</t> </t>
<t> <t>
In order to support these scenarios, the pledge MAY contact a well In order to support these scenarios, the pledge <bcp14>MAY</bcp14> con
known URI of a cloud registrar if a tact a well-known
URI of a cloud registrar if a
local registrar cannot be discovered or if the pledge's target use local registrar cannot be discovered or if the pledge's target use
cases do not include a local registrar.</t> cases do not include a local registrar.</t>
<t>If the pledge uses a well known URI for contacting a cloud registrar
a manufacturer-assigned Implicit Trust Anchor database (see <xref <t>If the pledge uses a well-known URI for contacting a cloud registrar,
target="RFC7030" format="default"/>) MUST a manufacturer-assigned Implicit Trust Anchor database (see <xref
target="RFC7030" format="default"/>) <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 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 appropriate, and it may include wildcard components on the
left-mode side. This is left-mode side. This is
consistent with the human user configuration of an EST server URI consistent with the human-user configuration of an EST server URI
in in
<xref target="RFC7030" format="default"/> which also depends on RF <xref target="RFC7030" format="default"/>, which also depends on
C6125.</t> <xref target="RFC6125"/>.</t>
</section> </section>
<section anchor="obtainmasaurl" numbered="true" toc="default"> <section anchor="obtainmasaurl" numbered="true" toc="default">
<name>Determining the MASA to contact</name> <name>Determining the MASA to Contact</name>
<t>The registrar needs to be able to contact a MASA that is trusted by t <t>
he pledge in order to obtain vouchers. There are three mechanisms described:</t> The registrar needs to be able to contact a MASA that is trusted by the pledge i
<t>The device's Initial Device Identifier (IDevID) will normally contain n order to obtain vouchers.</t>
the MASA URL as detailed in <xref target="IDevIDextension" format="default"/>.
This is the RECOMMENDED <t>The device's IDevID will normally contain the MASA URL as detailed in
mechanism.</t> <xref target="IDevIDextension" format="default"/>. This is the <bcp14>RECOMMEND
<t>It can be operationally difficult to ensure the necessary X.509 exten ED</bcp14>
sions are in the pledge's IDevID due to the difficulty of aligning current pledg mechanism.</t>
e manufacturing with software releases and development. As a final fallback the
registrar MAY be manually configured or distributed with a MASA URL for each man <t>In some cases, it can be operationally difficult to ensure the necess
ufacturer. Note that the registrar can only select the configured MASA URL based ary X.509 extensions are in the pledge's IDevID due to the difficulty of alignin
on the trust anchor -- so manufacturers can only leverage this approach if they g current pledge manufacturing with software releases and development; thus, as
ensure a single MASA URL works for all pledges associated with each trust ancho a final fallback, the registrar <bcp14>MAY</bcp14> be manually configured or dis
r.</t> tributed 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 ca
n only leverage this approach if they ensure a single MASA URL works for all ple
dges associated with each trust anchor.</t>
</section> </section>
</section> </section>
<section anchor="voucher-request" numbered="true" toc="default"> <section anchor="voucher-request" numbered="true" toc="default">
<name>Voucher-Request artifact</name> <name>Voucher-Request Artifact</name>
<t> <t>
Voucher-requests are how vouchers are requested. Voucher-requests are how vouchers are requested.
The semantics of the voucher-request are described below, in the YANG mo del. The semantics of the voucher-request are described below, in the YANG mo dule.
</t> </t>
<t> <t>
A pledge forms the "pledge voucher-request", signs it with it's A pledge forms the "pledge voucher-request", signs it with its
IDevID and submits it to the registrar. IDevID, and submits it to the registrar.
</t> </t>
<t> <t>
The registrar in turn forms the "registrar voucher-request", In turn, the registrar forms the "registrar voucher-request",
signs it with it's Registrar keypair and submits it to the MASA. signs it with its registrar key pair, and submits it to the MASA.
</t> </t>
<t> <t>
The "proximity-registrar-cert" leaf is used in the pledge The "proximity-registrar-cert" leaf is used in the pledge
voucher-requests. This provides a method for the pledge to voucher-requests. This provides a method for the pledge to
assert the registrar's proximity. assert the registrar's proximity.
</t> </t>
<t> <t>
This network proximity results from the following properties in the This network proximity results from the following properties in the
ACP context: the pledge is connected to the Join Proxy ACP context: the pledge is connected to the Join Proxy
(<xref target="proxydetails" format="default"/>) using a Link-Local IPv6 connection. (<xref target="proxydetails" format="default"/>) using a link-local IPv6 connection.
While the Join Proxy does not participate in any meaningful sense in While the Join Proxy does not participate in any meaningful sense in
the cryptography of the TLS connection (such as via a Channel the cryptography of the TLS connection (such as via a Channel
Binding), the Registrar can observe that the connection is via the Binding), the registrar can observe that the connection is via the
private ACP (ULA) address of the join proxy, and could not come from private ACP (ULA) address of the Join Proxy, and it cannot come from
outside the ACP. The Pledge must therefore be at most one IPv6 outside the ACP. The pledge must therefore be at most one IPv6
Link-Local hop away from an existing node on the ACP. link-local hop away from an existing node on the ACP.
</t> </t>
<t> <t>
Other users of BRSKI will need to define other kinds of assertions if Other users of BRSKI will need to define other kinds of assertions if
the network proximity described above does not match their needs. the network proximity described above does not match their needs.
</t> </t>
<t> <t>
The "prior-signed-voucher-request" leaf is used in registrar The "prior-signed-voucher-request" leaf is used in registrar
voucher-requests. If present, it is the signed pledge voucher-request voucher-requests. If present, it is the signed pledge voucher-request
artifact. This provides a method for artifact. This provides a method for
the registrar to forward the pledge's signed request to the the registrar to forward the pledge's signed request to the
MASA. This completes transmission of the signed MASA. This completes transmission of the signed
"proximity-registrar-cert" leaf. proximity-registrar-cert leaf.
</t> </t>
<t> <t>
Unless otherwise signaled (outside the voucher-request artifact), the Unless otherwise signaled (outside the voucher-request artifact), the
signing structure is as defined for vouchers, see signing structure is as defined for vouchers; see
<xref target="RFC8366" format="default"/>. <xref target="RFC8366" format="default"/>.
</t> </t>
<section anchor="noncelessVoucherRequest" numbered="true" toc="default"> <section anchor="noncelessVoucherRequest" numbered="true" toc="default">
<name>Nonceless Voucher Requests</name> <name>Nonceless Voucher-Requests</name>
<t> <t>
A registrar MAY also retrieve nonceless vouchers by sending A registrar <bcp14>MAY</bcp14> also retrieve nonceless vouchers by s ending
nonceless voucher-requests to the MASA in order to obtain nonceless voucher-requests to the MASA in order to obtain
vouchers for use when the registrar does not have connectivity to th e vouchers for use when the registrar does not have connectivity to th e
MASA. MASA.
No "prior-signed-voucher-request" leaf No prior-signed-voucher-request leaf
would be included. The registrar will also need to know the serial number of 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 the pledge. This document does not provide a mechanism for the
registrar to learn that in an automated fashion. Typically this will registrar to learn that in an automated fashion. Typically, this wil
be done via scanning of bar-code or QR-code on packaging, or via l
be done via the scanning of a bar code or QR code on packaging, or v
ia
some sales channel integration. some sales channel integration.
</t> </t>
</section> </section>
<section anchor="voucher-request-tree-diagram" numbered="true" toc="defaul t"> <section anchor="voucher-request-tree-diagram" numbered="true" toc="defaul t">
<name>Tree Diagram</name> <name>Tree Diagram</name>
<t>The following tree diagram illustrates a high-level view of a <t>The following tree diagram illustrates a high-level view of a
voucher-request document. The voucher-request builds upon voucher-request document. The voucher-request builds upon
the voucher artifact described in <xref target="RFC8366" format= "default"/>. the voucher artifact described in <xref target="RFC8366" format= "default"/>.
The tree diagram is described in <xref target="RFC8340" format=" default"/>. The tree diagram is described in <xref target="RFC8340" format=" default"/>.
Each node in the diagram is Each node in the diagram is
skipping to change at line 1203 skipping to change at line 1233
<section anchor="voucher-request-tree-diagram" numbered="true" toc="defaul t"> <section anchor="voucher-request-tree-diagram" numbered="true" toc="defaul t">
<name>Tree Diagram</name> <name>Tree Diagram</name>
<t>The following tree diagram illustrates a high-level view of a <t>The following tree diagram illustrates a high-level view of a
voucher-request document. The voucher-request builds upon voucher-request document. The voucher-request builds upon
the voucher artifact described in <xref target="RFC8366" format= "default"/>. the voucher artifact described in <xref target="RFC8366" format= "default"/>.
The tree diagram is described in <xref target="RFC8340" format=" default"/>. The tree diagram is described in <xref target="RFC8340" format=" default"/>.
Each node in the diagram is Each node in the diagram is
fully described by the YANG module in <xref target="voucher-requ est-yang-module" format="default"/>. fully described by the YANG module in <xref target="voucher-requ est-yang-module" format="default"/>.
Please review the YANG module for a detailed description of the Please review the YANG module for a detailed description of the
voucher-request format.</t> voucher-request format.</t>
<figure anchor="voucherrequest_tree"> <figure anchor="voucherrequest_tree">
<name>YANG Tree diagram for Voucher-Request</name> <name>YANG Tree Diagram for a Voucher-Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork name="" type="yangtree" align="left" alt=""><![CDATA[
module: ietf-voucher-request module: ietf-voucher-request
grouping voucher-request-grouping grouping voucher-request-grouping
+---- voucher +-- voucher
+---- created-on? yang:date-and-time +-- created-on? yang:date-and-time
+---- expires-on? yang:date-and-time +-- expires-on? yang:date-and-time
+---- assertion? enumeration +-- assertion? enumeration
+---- serial-number string +-- serial-number string
+---- idevid-issuer? binary +-- idevid-issuer? binary
+---- pinned-domain-cert? binary +-- pinned-domain-cert? binary
+---- domain-cert-revocation-checks? boolean +-- domain-cert-revocation-checks? boolean
+---- nonce? binary +-- nonce? binary
+---- last-renewal-date? yang:date-and-time +-- last-renewal-date? yang:date-and-time
+---- prior-signed-voucher-request? binary +-- prior-signed-voucher-request? binary
+---- proximity-registrar-cert? binary +-- proximity-registrar-cert? binary
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<!-- tree diagram -->
<section anchor="voucher-request-examples" numbered="true" toc="default" > <section anchor="voucher-request-examples" numbered="true" toc="default" >
<name>Examples</name> <name>Examples</name>
<t>This section provides voucher-request examples for illustration <t>This section provides voucher-request examples for illustration
purposes. purposes.
These examples show the JSON prior to CMS wrapping. These examples show JSON prior to CMS wrapping.
JSON encoding rules specify that any binary JSON encoding rules specify that any binary
content be base64 encoded (<xref target="RFC4648" format="defaul content be base64 encoded (<xref target="RFC4648"
t"/> section 4). sectionFormat="comma" section="4"/>).
The contents of the (base64) encoded certificates have been elid ed The contents of the (base64) encoded certificates have been elid ed
to save space. For detailed examples, see <xref target="examplep rocess" format="default"/>. These examples conform to the encoding rules to save space. For detailed examples, see <xref target="examplep rocess" format="default"/>. These examples conform to the encoding rules
defined in <xref target="RFC7951" format="default"/>.</t> defined in <xref target="RFC7951" format="default"/>.</t>
<ol group="examples" spacing="normal" type="Example (%d)"> <ol group="examples" spacing="normal" type="Example (%d):">
<li>The following example illustrates a pledge voucher-request. The <li>The following example illustrates a pledge voucher-request. The
assertion leaf is indicated as 'proximity' and the registrar's TLS s assertion leaf is indicated as "proximity", and the registrar's TLS
erver server
certificate is included in the 'proximity-registrar-cert' leaf. See certificate is included in the proximity-registrar-cert leaf. See
<xref target="RequestVoucherFromRegistrar" format="default"/>.</li> <xref target="RequestVoucherFromRegistrar" format="default"/>.</li>
</ol> </ol>
<figure anchor="voucherrequest_example1"> <figure anchor="voucherrequest_example1">
<name>JSON representation of example Voucher-Request</name> <name>JSON Representation of an Example Voucher-Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"assertion": "proximity", "assertion": "proximity",
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"serial-number" : "JADA123456789", "serial-number" : "JADA123456789",
"created-on": "2017-01-01T00:00:00.000Z", "created-on": "2017-01-01T00:00:00.000Z",
"proximity-registrar-cert": "base64encodedvalue==" "proximity-registrar-cert": "base64encodedvalue=="
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<ol group="examples" spacing="normal" type="Example (%d)"> <ol group="examples" spacing="normal" type="Example (%d):">
<li>The following example illustrates a registrar voucher-request. <li>The following example illustrates a registrar voucher-request.
The 'prior-signed-voucher-request' leaf is populated with the pl edge's The prior-signed-voucher-request leaf is populated with the pled ge's
voucher-request (such as the prior example). The pledge's voucher-request (such as the prior example). The pledge's
voucher-request is a binary CMS signed object. In the JSON enco voucher-request is a binary CMS-signed object. In the JSON enco
ding used ding used
here it must be base64 encoded. The nonce and here, it must be base64 encoded. The nonce and
assertion have been carried forward from the pledge request to assertion have been carried forward from the pledge request to
the registrar request. the registrar request.
The serial-number is extracted from The serial-number is extracted from
the pledge's Client Certificate from the TLS connection. See the pledge's Client Certificate from the TLS connection. See
<xref target="RequestVoucherFromMASA" format="default"/>.</li> <xref target="RequestVoucherFromMASA" format="default"/>.</li>
</ol> </ol>
<figure anchor="voucherrequest_prior_example1"> <figure anchor="voucherrequest_prior_example1">
<name>JSON representation of example Prior-Signed Voucher-Request</nam <name>JSON Representation of an Example Prior-Signed Voucher-Request</
e> name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"assertion" : "proximity", "assertion" : "proximity",
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"idevid-issuer": "base64encodedvalue==", "idevid-issuer": "base64encodedvalue==",
"serial-number": "JADA123456789", "serial-number": "JADA123456789",
"prior-signed-voucher-request": "base64encodedvalue==" "prior-signed-voucher-request": "base64encodedvalue=="
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<ol group="examples" spacing="normal" type="Example (%d)"> <ol group="examples" spacing="normal" type="Example (%d):">
<li>The following example illustrates a registrar voucher-request. <li>The following example illustrates a registrar voucher-request.
The 'prior-signed-voucher-request' leaf is not populated with th e pledge's The prior-signed-voucher-request leaf is not populated with the pledge's
voucher-request nor is the nonce leaf. This form might be used b y a voucher-request nor is the nonce leaf. This form might be used b y a
registrar requesting a voucher when the pledge can not registrar requesting a voucher when the pledge cannot
communicate with the registrar (such as when it is powered communicate with the registrar (such as when it is powered
down, or still in packaging), down or still in packaging)
and therefore could not submit a nonce. and therefore cannot submit a nonce.
This scenario is most useful when the registrar is aware that This scenario is most useful when the registrar is aware that
it will not be able to reach the MASA during deployment. it will not be able to reach the MASA during deployment.
See See
<xref target="RequestVoucherFromMASA" format="default"/>.</li> <xref target="RequestVoucherFromMASA" format="default"/>.</li>
</ol> </ol>
<figure anchor="voucherrequest_offline_example1"> <figure anchor="voucherrequest_offline_example1">
<name>JSON representation of Offline Voucher-Request</name> <name>JSON Representation of an Offline Voucher-Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{ {
"ietf-voucher-request:voucher": { "ietf-voucher-request:voucher": {
"created-on": "2017-01-01T00:00:02.000Z", "created-on": "2017-01-01T00:00:02.000Z",
"idevid-issuer": "base64encodedvalue==", "idevid-issuer": "base64encodedvalue==",
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
</section> </section>
<!-- examples -->
<section anchor="voucher-request-yang-module" numbered="true" toc="defau lt"> <section anchor="voucher-request-yang-module" numbered="true" toc="defau lt">
<name>YANG Module</name> <name>YANG Module</name>
<t>Following is a YANG <xref target="RFC7950" format="default"/> module
formally <t>Following is a YANG module <xref target="RFC7950" format="default"/>
extending the <xref target="RFC8366" format="default"/> voucher into that formally
a voucher-request.</t> extends a voucher <xref target="RFC8366" format="default"/> into
<figure anchor="voucherrequest_yang"> a voucher-request. This YANG module references <xref target="ITU.X690"
<name>YANG module for Voucher-Request</name> format="default"/>. </t>
<sourcecode name="ietf-voucher-request@2018-02-14.yang" type="" marker
s="true"><![CDATA[ <figure anchor="voucherrequest_yang">
<name>YANG Module for Voucher-Request</name>
<sourcecode name="ietf-voucher-request@2021-04-10.yang" type="yang" ma
rkers="true"><![CDATA[
module ietf-voucher-request { module ietf-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
namespace prefix vcr;
"urn:ietf:params:xml:ns:yang:ietf-voucher-request";
prefix "vcr";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description "This import statement is only present to access description
"This import statement is only present to access
the yang-data extension defined in RFC 8040."; the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol"; reference
"RFC 8040: RESTCONF Protocol";
} }
import ietf-voucher { import ietf-voucher {
prefix vch; prefix vch;
description "This module defines the format for a voucher, description
which is produced by a pledge's manufacturer or "This module defines the format for a voucher,
delegate (MASA) to securely assign a pledge to which is produced by a pledge's manufacturer or
an 'owner', so that the pledge may establish a secure delegate (MASA) to securely assign a pledge to
connection to the owner's network infrastructure"; an 'owner', so that the pledge may establish a secure
connection to the owner's network infrastructure.";
reference "RFC 8366: Voucher Artifact for Bootstrapping Protocols"; reference
"RFC 8366: A Voucher Artifact for
Bootstrapping Protocols";
} }
organization organization
"IETF ANIMA Working Group"; "IETF ANIMA Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/anima/> "WG Web: <https://datatracker.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org> WG List: <mailto:anima@ietf.org>
Author: Kent Watsen Author: Kent Watsen
<mailto:kent+ietf@watsen.net> <mailto:kent+ietf@watsen.net>
Author: Michael H. Behringer Author: Michael H. Behringer
<mailto:Michael.H.Behringer@gmail.com> <mailto:Michael.H.Behringer@gmail.com>
Author: Toerless Eckert Author: Toerless Eckert
<mailto:tte+ietf@cs.fau.de> <mailto:tte+ietf@cs.fau.de>
Author: Max Pritikin Author: Max Pritikin
<mailto:pritikin@cisco.com> <mailto:pritikin@cisco.com>
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>"; <mailto:mcr+ietf@sandelman.ca>";
description description
"This module defines the format for a voucher request. "This module defines the format for a voucher-request.
It is a superset of the voucher itself. It is a superset of the voucher itself.
It provides content to the MASA for consideration It provides content to the MASA for consideration
during a voucher request. during a voucher-request.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or
modification, is permitted pursuant to, and subject to the license without modification, is permitted pursuant to, and subject
terms contained in, the Simplified BSD License set forth in Section to the license terms contained in, the Simplified BSD License
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents set forth in Section 4.c of the IETF Trust's Legal Provisions
(http://trustee.ietf.org/license-info). Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC 8995; see the
itself for full legal notices."; RFC itself for full legal notices.";
revision "2018-02-14" { revision 2021-04-10 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Bootstrapping Remote Secure Key Infrastructure"; "RFC 8995: Bootstrapping Remote Secure Key Infrastructure
(BRSKI)";
} }
// Top-level statement // Top-level statement
rc:yang-data voucher-request-artifact { rc:yang-data voucher-request-artifact {
uses voucher-request-grouping; uses voucher-request-grouping;
} }
// Grouping defined for future usage // Grouping defined for future usage
grouping voucher-request-grouping { grouping voucher-request-grouping {
description description
"Grouping to allow reuse/extensions in future work."; "Grouping to allow reuse/extensions in future work.";
uses vch:voucher-artifact-grouping { uses vch:voucher-artifact-grouping {
refine "voucher/created-on" { refine "voucher/created-on" {
mandatory false; mandatory false;
} }
refine "voucher/pinned-domain-cert" { refine "voucher/pinned-domain-cert" {
mandatory false; 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" { refine "voucher/domain-cert-revocation-checks" {
description "The domain-cert-revocation-checks field description
is not valid in a voucher request, and "The domain-cert-revocation-checks field is not valid in a
any occurence MUST be ignored"; voucher-request, and any occurrence MUST be ignored.";
} }
refine "voucher/assertion" { refine "voucher/assertion" {
mandatory false; mandatory false;
description "Any assertion included in registrar voucher description
requests SHOULD be ignored by the MASA."; "Any assertion included in registrar voucher-requests
SHOULD be ignored by the MASA.";
} }
augment "voucher" {
augment "voucher" {
description description
"Adds leaf nodes appropriate for requesting vouchers."; "Adds leaf nodes appropriate for requesting vouchers.";
leaf prior-signed-voucher-request { leaf prior-signed-voucher-request {
type binary; type binary;
description description
"If it is necessary to change a voucher, or re-sign and "If it is necessary to change a voucher, or re-sign and
forward a voucher that was previously provided along a forward a voucher that was previously provided along a
protocol path, then the previously signed voucher SHOULD be protocol path, then the previously signed voucher SHOULD
included in this field. be included in this field.
For example, a pledge might sign a voucher request For example, a pledge might sign a voucher-request
with a proximity-registrar-cert, and the registrar with a proximity-registrar-cert, and the registrar
then includes it as the prior-signed-voucher-request field. then includes it as the prior-signed-voucher-request
This is a simple mechanism for a chain of trusted field. This is a simple mechanism for a chain of
parties to change a voucher request, while trusted parties to change a voucher-request, while
maintaining the prior signature information. maintaining the prior signature information.
The Registrar and MASA MAY examine the prior signed The registrar and MASA MAY examine the prior-signed
voucher information for the voucher information for the
purposes of policy decisions. For example this information purposes of policy decisions. For example, this
could be useful to a MASA to determine that both pledge and information could be useful to a MASA to determine
registrar agree on proximity assertions. The MASA SHOULD that both the pledge and registrar agree on proximity
remove all prior-signed-voucher-request information when assertions. The MASA SHOULD remove all
signing a voucher for imprinting so as to minimize the prior-signed-voucher-request information when
final voucher size."; signing a voucher for imprinting so as to minimize
the final voucher size.";
} }
leaf proximity-registrar-cert { leaf proximity-registrar-cert {
type binary; type binary;
description description
"An X.509 v3 certificate structure as specified by RFC 5280, "An X.509 v3 certificate structure, as specified by
Section 4 encoded using the ASN.1 distinguished encoding RFC 5280, Section 4, encoded using the ASN.1
rules (DER), as specified in [ITU.X690.1994]. distinguished encoding rules (DER), as specified
in ITU X.690.
The first certificate in the Registrar TLS server The first certificate in the registrar TLS server
certificate_list sequence (the end-entity TLS certificate, certificate_list sequence (the end-entity TLS
see [RFC8446]) presented by the Registrar to the Pledge. certificate; see RFC 8446) presented by the registrar
This MUST be populated in a Pledge's voucher request when a to the pledge. This MUST be populated in a pledge's
proximity assertion is requested."; 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> ]]></sourcecode>
</figure> </figure>
</section> </section>
<!-- yang module -->
</section> </section>
<!-- voucher-request artifact -->
<section anchor="proxydetails" numbered="true" toc="default"> <section anchor="proxydetails" numbered="true" toc="default">
<name>Proxying details (Pledge - Proxy - Registrar)</name> <name>Proxying Details (Pledge -- Proxy -- Registrar)</name>
<t> <t>
This section is normative for uses with an ANIMA ACP. This section is normative for uses with an ANIMA ACP.
The use of the GRASP mechanism is part of the ACP. The use of the GRASP mechanism is part of the ACP.
Other users of BRSKI will need to define an equivalent proxy Other users of BRSKI will need to define an equivalent proxy
mechanism, and an equivalent mechanism to configure the proxy. mechanism and an equivalent mechanism to configure the proxy.
</t> </t>
<t> <t>
The role of the proxy is to facilitate communications. The proxy The role of the proxy is to facilitate communications. The proxy
forwards packets between the pledge and a registrar that has been forwards packets between the pledge and a registrar that has been
provisioned to the proxy via full GRASP ACP discovery. provisioned to the proxy via full GRASP ACP discovery.
</t> </t>
<t> <t>
This section defines a stateful proxy mechanism which is referred This section defines a stateful proxy mechanism that is referred
to as a "circuit" proxy. This is a form of Application Level Gateway to as a "circuit" proxy. This is a form of Application Level Gateway
(<xref target="RFC2663" format="default"/> section 2.9). (see <xref target="RFC2663" sectionFormat="comma" section="2.9"/>).
</t> </t>
<t> <t>
The proxy does not terminate the TLS handshake: it passes streams The proxy does not terminate the TLS handshake: it passes streams
of bytes onward without examination. of bytes onward without examination.
A proxy MUST NOT assume any specific TLS version. Please see A proxy <bcp14>MUST NOT</bcp14> assume any specific TLS version. Please
<xref target="RFC8446" format="default"/> section 9.3 for details on TLS see
invariants. <xref target="RFC8446" sectionFormat="comma" section="9.3"/> for
details on TLS invariants.
</t> </t>
<t> <t>
A Registrar can directly provide the proxy announcements A registrar can directly provide the proxy announcements
described below, in which case the described below, in which case the
announced port can point directly to the Registrar itself. In this announced port can point directly to the registrar itself. In this
scenario the pledge is unaware that there is no proxying occurring. scenario, the pledge is unaware that there is no proxying occurring.
This is useful for Registrars which are servicing pledges on directly This is useful for registrars that are servicing pledges on directly
connected networks. connected networks.
</t> </t>
<t> <t>
As a result of the proxy Discovery process in <xref target="brskigrasp" format="default"/>, As a result of the proxy discovery process in <xref target="brskigrasp" format="default"/>,
the port number exposed by the proxy the port number exposed by the proxy
does not need to be well known, or require an IANA allocation. does not need to be well known or require an IANA allocation.
</t> </t>
<t> <t>
During the discovery of the Registrar by the Join Proxy, the During the discovery of the registrar by the Join Proxy, the
Join Proxy will also learn which kinds of proxy mechanisms are Join Proxy will also learn which kinds of proxy mechanisms are
available. This will allow the Join Proxy to use the lowest impact available. This will allow the Join Proxy to use the lowest impact
mechanism which the Join Proxy and Registrar have in common. mechanism that the Join Proxy and registrar have in common.
</t> </t>
<t> <t>
In order to permit the proxy functionality to be implemented on the In order to permit the proxy functionality to be implemented on the
maximum variety of devices the chosen mechanism should use the minimum maximum variety of devices, the chosen mechanism should use the minimum
amount of state on the proxy device. While many devices in the ANIMA amount of state on the proxy device. While many devices in the ANIMA
target space will be rather large routers, the proxy function is target space will be rather large routers, the proxy function is
likely to be implemented in the control plane CPU of such a device, likely to be implemented in the control-plane CPU of such a device,
with available capabilities for the proxy function similar to many with available capabilities for the proxy function similar to many
class 2 IoT devices. class 2 IoT devices.
</t> </t>
<t> <t>
The document <xref target="I-D.richardson-anima-state-for-joinrouter" fo rmat="default"/> provides a The document <xref target="I-D.richardson-anima-state-for-joinrouter" fo rmat="default"/> provides a
more extensive analysis and background of the alternative proxy methods. more extensive analysis and background of the alternative proxy methods.
</t> </t>
<section anchor="discovery" numbered="true" toc="default"> <section anchor="discovery" numbered="true" toc="default">
<name>Pledge discovery of Proxy</name> <name>Pledge Discovery of Proxy</name>
<t> <t>
The result of discovery is a logical communication with a The result of discovery is a logical communication with a
registrar, through a proxy. registrar, through a proxy.
The proxy is transparent to the pledge. The communication The proxy is transparent to the pledge. The communication
between the pledge and Join Proxy is over IPv6 Link-Local addresse s. between the pledge and Join Proxy is over IPv6 link-local addresse s.
</t> </t>
<t>To discover the proxy the pledge performs the following <t>To discover the proxy, the pledge performs the following
actions:</t> actions:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>MUST: Obtains a local address using IPv6 <li><bcp14>MUST</bcp14>: Obtain a local address using IPv6
methods as described in <xref target="RFC4862" format="defau methods as described in "IPv6
lt"/> IPv6 Stateless Address Autoconfiguration" <xref target="RFC4862"
Stateless Address AutoConfiguration. format="default"/>.
Use of <xref target="RFC4941" format="default"/> temporary a Use of temporary addresses <xref target="RFC8981" format="de
ddresses is fault"/> is
encouraged. To limit pervasive monitoring ( encouraged. To limit pervasive monitoring
<xref target="RFC7258" format="default"/>), a new temporary <xref target="RFC7258" format="default"/>, a new temporary a
address MAY ddress <bcp14>MAY</bcp14>
use a short lifetime (that is, set TEMP_PREFERRED_LIFETIME use a short lifetime (that is, set TEMP_PREFERRED_LIFETIME
to be short). to be short).
Pledges will generally prefer use of IPv6 Link-Local Pledges will generally prefer use of IPv6 link-local
addresses, and discovery of proxy will be by Link-Local addresses, and discovery of the proxy will be by link-local
mechanisms. mechanisms.
IPv4 methods are described in <xref target="IPv4operations" IPv4 methods are described in <xref target="IPv4operations"
format="default"/></li> format="default"/>.</li>
<li>MUST: Listen for GRASP M_FLOOD
(<xref target="I-D.ietf-anima-grasp" format="default"/>) <li><bcp14>MUST</bcp14>: Listen for GRASP M_FLOOD
<xref target="RFC8990" format="default"/>
announcements of the objective: "AN_Proxy". announcements of the objective: "AN_Proxy".
See section <xref target="brskigrasp" format="default"/> for See <xref target="brskigrasp" format="default"/> for the det
the details of ails of
the objective. The pledge MAY listen concurrently for the objective. The pledge <bcp14>MAY</bcp14> listen concurr
other sources of information, see <xref target="mdnsmethods" ently for
format="default"/>. other sources of information; see <xref target="mdnsmethods"
format="default"/>.
</li> </li>
</ol> </ol>
<t> <t>
Once a proxy is Once a proxy is
discovered the pledge communicates with a registrar through the discovered, the pledge communicates with a registrar through the
proxy using the bootstrapping protocol defined in <xref target="Prot ocolDetails" format="default"/>. proxy using the bootstrapping protocol defined in <xref target="Prot ocolDetails" format="default"/>.
</t> </t>
<t> <t>
While the GRASP M_FLOOD mechanism is passive for the pledge, the While the GRASP M_FLOOD mechanism is passive for the pledge, the
non-normative other methods (mDNS, and IPv4 methods) described in non-normative other methods (mDNS and IPv4 methods) described in
<xref target="mdnsmethods" format="default"/> are active. <xref target="mdnsmethods" format="default"/> are active.
The pledge SHOULD run those methods in parallel with listening The pledge <bcp14>SHOULD</bcp14> run those methods in parallel wit
to for the M_FLOOD. The active methods SHOULD h listening
back-off by doubling to a maximum of one hour to avoid overloading for the M_FLOOD. The active methods <bcp14>SHOULD</bcp14>
the back off by doubling to a maximum of one hour to avoid overloading
network with discovery attempts. Detection of change of the
physical link status (Ethernet carrier for instance) SHOULD network with discovery attempts. Detection of
reset the back off timers. physical link status change (Ethernet carrier, for instance) <bcp1
4>SHOULD</bcp14>
reset the back-off timers.
</t> </t>
<t> <t>
The pledge could discover more than one proxy on a given physical The pledge could discover more than one proxy on a given physical
interface. The pledge can have a multitude of physical interface. The pledge can have a multitude of physical
interfaces as well: a layer-2/3 Ethernet switch may have interfaces as well: a Layer 2/3 Ethernet switch may have
hundreds of physical ports. hundreds of physical ports.
</t> </t>
<t> <t>
Each possible proxy offer SHOULD be attempted up to the point Each possible proxy offer <bcp14>SHOULD</bcp14> be attempted up to the point
where a valid voucher is received: while there are many ways in wh ich where a valid voucher is received: while there are many ways in wh ich
the attempt may fail, it does not succeed until the voucher has the attempt may fail, it does not succeed until the voucher has
been validated. been validated.
</t> </t>
<t> <t>
The connection attempts via a single proxy SHOULD exponentially The connection attempts via a single proxy <bcp14>SHOULD</bcp14> e
back-off to a maximum of one hour to avoid overloading the network xponentially
infrastructure. The back-off timer for each MUST be back off to a maximum of one hour to avoid overloading the network
infrastructure. The back-off timer for each <bcp14>MUST</bcp14>
be
independent of other connection attempts. independent of other connection attempts.
</t> </t>
<t> <t>
Connection attempts SHOULD be run in Connection attempts <bcp14>SHOULD</bcp14> be run in
parallel to avoid head of queue problems wherein an attacker parallel to avoid head-of-queue problems wherein an attacker
running a fake proxy or registrar could perform protocol running a fake proxy or registrar could intentionally perform pr
actions intentionally slowly. Connection attempts to otocol
different proxies SHOULD be sent with an interval of 3 to actions slowly. Connection attempts to
5s. The pledge SHOULD continue to different proxies <bcp14>SHOULD</bcp14> be sent with an interval
listen to for additional GRASP M_FLOOD messages during of 3 to
5s. The pledge <bcp14>SHOULD</bcp14> continue to
listen for additional GRASP M_FLOOD messages during
the connection attempts. the connection attempts.
</t> </t>
<t> <t>
Each connection attempt through a distinct Join Proxy MUST Each connection attempt through a distinct Join Proxy <bcp14>MUST< /bcp14>
have a unique nonce in the voucher-request. have a unique nonce in the voucher-request.
</t> </t>
<t> <t>
Once a connection to a Once a connection to a
registrar is established (e.g. establishment of a TLS session key) registrar is established (e.g., establishment of a TLS session key
there are expectations of more timely responses, see <xref target= ),
"RequestVoucherFromRegistrar" format="default"/>. there are expectations of more timely responses; see <xref target=
"RequestVoucherFromRegistrar" format="default"/>.
</t> </t>
<t> <t>
Once all discovered services are attempted (assuming that none Once all discovered services are attempted (assuming that none
succeeded) the device MUST return to listening for GRASP M_FLOOD. succeeded), the device <bcp14>MUST</bcp14> return to listening for
It SHOULD periodically retry any manufacturer-specific mechanisms. GRASP M_FLOOD.
The pledge MAY prioritize selection order as It <bcp14>SHOULD</bcp14> periodically retry any manufacturer-speci
fic mechanisms.
The pledge <bcp14>MAY</bcp14> prioritize selection order as
appropriate for the anticipated environment. appropriate for the anticipated environment.
</t> </t>
<section anchor="brskigrasp" numbered="true" toc="default"> <section anchor="brskigrasp" numbered="true" toc="default">
<name>Proxy GRASP announcements</name> <name>Proxy GRASP Announcements</name>
<t> <t>
A proxy uses the DULL GRASP M_FLOOD mechanism to announce A proxy uses the DULL GRASP M_FLOOD mechanism to announce
itself. itself.
This announcement can be within the same message as the ACP This announcement can be within the same message as the ACP
announcement detailed in announcement detailed in
<xref target="I-D.ietf-anima-autonomic-control-plane" format="def ault"/>. <xref target="RFC8994" format="default"/>.
</t> </t>
<t> <t>
The formal Concise Data Definition Language (CDDL) <xref target=" The formal Concise Data Definition Language (CDDL) <xref
RFC8610" format="default"/> definition is: target="RFC8610" format="default"/> definition is:
</t> </t>
<figure anchor="proxy_discovery_cddl"> <figure anchor="proxy_discovery_cddl">
<name>CDDL definition of Proxy Discovery message</name> <name>CDDL Definition of Proxy Discovery Message</name>
<sourcecode name="proxygrasp.cddl" type="" markers="true"><![CDATA[
<sourcecode name="proxygrasp.cddl" type="CDDL" markers="true"><![CDA
TA[
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_Proxy", objective-flags, loop-count, objective = ["AN_Proxy", objective-flags, loop-count,
objective-value] objective-value]
ttl = 180000 ; 180,000 ms (3 minutes) ttl = 180000 ; 180,000 ms (3 minutes)
initiator = ACP address to contact Registrar initiator = ACP address to contact registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in the GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires
; synchronization
loop-count = 1 ; one hop only loop-count = 1 ; one hop only
objective-value = any ; none objective-value = any ; none
locator-option = [ O_IPv6_LOCATOR, ipv6-address, locator-option = [ O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number ] transport-proto, port-number ]
ipv6-address = the v6 LL of the Proxy ipv6-address = the v6 LL of the Proxy
$transport-proto /= IPPROTO_TCP ; note this can be any value from the $transport-proto /= IPPROTO_TCP ; note that this can be any value
; IANA protocol registry, as per ; from the IANA protocol registry,
; [GRASP] section 2.9.5.1, note 3. ; as per RFC 8990, Section 2.9.5.1,
; Note 3.
port-number = selected by Proxy port-number = selected by Proxy
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t> <t>
Here is an example M_FLOOD announcing a proxy at fe80::1, Here is an example M_FLOOD announcing a proxy at fe80::1,
on TCP port 4443. on TCP port 4443.
</t> </t>
<figure anchor="proxy_discovery_mflood"> <figure anchor="proxy_discovery_mflood">
<name>Example of Proxy Discovery message</name> <name>Example of Proxy Discovery Message</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, ""], [["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]] h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]]
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
On a small network the Registrar MAY include the GRASP On a small network, the registrar <bcp14>MAY</bcp14> include the GRASP
M_FLOOD announcements to locally connected networks. M_FLOOD announcements to locally connected networks.
</t> </t>
<t> <t>
The $transport-proto above indicates the method that the The $transport-proto above indicates the method that the
pledge-proxy-registrar will use. The TCP method described pledge-proxy-registrar will use. The TCP method described
here is mandatory, and other proxy methods, such as CoAP here is mandatory, and other proxy methods, such as CoAP
methods not defined in this document are optional. Other methods not defined in this document, are optional. Other
methods MUST NOT be enabled unless the Join Registrar ASA methods <bcp14>MUST NOT</bcp14> be enabled unless the Join Regist
indicates support for them in it's own announcement. rar ASA
indicates support for them in its own announcement.
</t> </t>
</section> </section>
</section> </section>
<section anchor="coapconnection" numbered="true" toc="default"> <section anchor="coapconnection" numbered="true" toc="default">
<name>CoAP connection to Registrar</name> <name>CoAP Connection to Registrar</name>
<t> <t>
The use of CoAP to connect from pledge to registrar The use of CoAP to connect from pledge to registrar
is out of scope for this document, and is described in future is out of scope for this document and is described in future
work. See <xref target="I-D.ietf-anima-constrained-voucher" format="de fault"/>. work. See <xref target="I-D.ietf-anima-constrained-voucher" format="de fault"/>.
</t> </t>
</section> </section>
<section anchor="JRCgrasp" numbered="true" toc="default"> <section anchor="JRCgrasp" numbered="true" toc="default">
<name>Proxy discovery and communication of Registrar</name> <name>Proxy Discovery and Communication of Registrar</name>
<t> The registrar SHOULD announce itself so that proxies can find it <t> The registrar <bcp14>SHOULD</bcp14> announce itself so that proxies
can find it
and determine what kind of connections can be terminated. and determine what kind of connections can be terminated.
</t> </t>
<t> <t>
The registrar announces itself using ACP instance of GRASP using The registrar announces itself using GRASP M_FLOOD messages,
M_FLOOD messages. A registrar may announce any convenient port with the "AN_join_registrar" objective, within the ACP instance.
number, including using a stock port 443. A registrar may announce any convenient port
ANI proxies MUST support GRASP discovery of registrars. number, including use of stock port 443.
</t> ANI proxies <bcp14>MUST</bcp14> support GRASP discovery of registrars.
</t>
<t> <t>
The M_FLOOD is formatted as follows: The M_FLOOD is formatted as follows:
</t> </t>
<figure anchor="registrar_discovery_example1"> <figure anchor="registrar_discovery_example1">
<name>An example of a Registrar announcement message</name> <name>An Example of a Registrar Announcement Message</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000, [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
[["AN_join_registrar", 4, 255, "EST-TLS"], [["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]] h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]]
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The formal CDDL definition is: The formal CDDL definition is:
</t> </t>
<figure anchor="registrar_discovery_cddl"> <figure anchor="registrar_discovery_cddl">
<name>CDDL definition for Registrar announcement message</name> <name>CDDL Definition for Registrar Announcement Message</name>
<sourcecode name="jrcgrasp.cddl" type="" markers="true"><![CDATA[
<sourcecode name="jrcgrasp.cddl" type="CDDL" markers="true"><![CDATA[
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_join_registrar", objective-flags, loop-count, objective = ["AN_join_registrar", objective-flags, loop-count,
objective-value] objective-value]
initiator = ACP address to contact Registrar initiator = ACP address to contact registrar
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in the GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires
; synchronization
loop-count = 255 ; mandatory maximum loop-count = 255 ; mandatory maximum
objective-value = text ; name of the (list of) of supported objective-value = text ; name of the (list of) supported
; protocols: "EST-TLS" for RFC7030. ; protocols: "EST-TLS" for RFC 7030.
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t> <t>
The M_FLOOD message MUST be sent periodically. The default period SHO The M_FLOOD message <bcp14>MUST</bcp14> be sent periodically. The def
ULD be ault period <bcp14>SHOULD</bcp14> be
60 seconds, the value SHOULD be operator configurable but SHOULD 60 seconds, and the value <bcp14>SHOULD</bcp14> be operator configurab
NOT be smaller than 60 seconds. The frequency of sending MUST be such le but <bcp14>SHOULD
NOT</bcp14> be smaller than 60 seconds. The frequency of sending <bcp
14>MUST</bcp14> be such
that the aggregate amount of periodic M_FLOODs from all flooding that the aggregate amount of periodic M_FLOODs from all flooding
sources cause only negligible traffic across the ACP. sources causes only negligible traffic across the ACP.
</t> </t>
<t> <t>
Here are some examples of locators for illustrative purposes. Here are some examples of locators for illustrative purposes.
Only the first one ($transport-protocol = 6, TCP) is defined in Only the first one ($transport-protocol = 6, TCP) is defined in
this document and is mandatory to implement. this document and is mandatory to implement.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]
locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork> locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
<t> <t>
A protocol of 6 indicates that TCP proxying on the A protocol of 6 indicates that TCP proxying on the
indicated port is desired. indicated port is desired.
</t> </t>
<t> <t>
Registrars MUST announce the set of protocols that they Registrars <bcp14>MUST</bcp14> announce the set of protocols that
support. They MUST support TCP traffic. they
support, and they <bcp14>MUST</bcp14> support TCP traffic.
</t> </t>
<t> <t>
Registrars MUST accept HTTPS/EST traffic on the TCP ports Registrars <bcp14>MUST</bcp14> accept HTTPS/EST traffic on the TC P ports
indicated. indicated.
</t> </t>
<t> <t>
Registrars MUST support ANI TLS circuit proxy and Registrars <bcp14>MUST</bcp14> support the ANI TLS Circuit Proxy and
therefore BRSKI across HTTPS/TLS native across the ACP. therefore BRSKI across HTTPS/TLS native across the ACP.
</t> </t>
<t> <t>
In the ANI, the Autonomic Control Plane (ACP) secured instance of In the ANI, the ACP-secured instance of
GRASP (<xref target="I-D.ietf-anima-grasp" format="default"/>) MU GRASP <xref target="RFC8990" format="default"/> <bcp14>MUST</bcp1
ST be used for 4> be used for
discovery of ANI registrar ACP addresses discovery of ANI registrar ACP addresses
and ports by ANI proxies. The TCP leg of the proxy connection be and ports by ANI proxies. Therefore, the TCP leg of the proxy co
tween nnection between
ANI proxy and ANI registrar therefore also runs across the ACP. the ANI proxy and ANI registrar also runs across the ACP.
</t> </t>
</section> </section>
</section> </section>
<section anchor="ProtocolDetails" numbered="true" toc="default"> <section anchor="ProtocolDetails" numbered="true" toc="default">
<name>Protocol Details (Pledge - Registrar - MASA)</name> <name>Protocol Details (Pledge -- Registrar -- MASA)</name>
<t>The pledge MUST initiate BRSKI after boot if it is unconfigured. <t>The pledge <bcp14>MUST</bcp14> initiate BRSKI after boot if it is uncon
The pledge MUST NOT automatically initiate BRSKI if it has been figured.
The pledge <bcp14>MUST NOT</bcp14> automatically initiate BRSKI if it ha
s been
configured or is in the process of being configured.</t> configured or is in the process of being configured.</t>
<t> <t>
BRSKI is described as extensions to EST <xref target="RFC7030" format= "default"/>. BRSKI is described as extensions to EST <xref target="RFC7030" format= "default"/>.
The goal of these extensions is to reduce the number of TLS The goal of these extensions is to reduce the number of TLS
connections and crypto operations required on the pledge. connections and crypto operations required on the pledge.
The registrar implements the BRSKI REST interface within The registrar implements the BRSKI REST interface within
the same "/.well-known" URI tree as the existing EST URIs as the "/.well-known/brski" URI tree and implements the existing EST URIs as
described in described in
EST <xref target="RFC7030" format="default"/> section 3.2.2. The commu nication channel EST <xref target="RFC7030" sectionFormat="comma" section="3.2.2"/>. Th e communication channel
between the pledge and the registrar is referred to as "BRSKI-EST" between the pledge and the registrar is referred to as "BRSKI-EST"
(see <xref target="architecturefigure" format="default"/>). (see <xref target="architecturefigure" format="default"/>).
</t> </t>
<t>The communication channel between the registrar and MASA is similarly d <t>
escribed as extensions to EST within the same "/.well-known" tree. For clarity t The communication channel between the registrar and MASA is a new
his channel is referred to as "BRSKI-MASA". (See <xref target="architecturefigur communication channel, similar to EST, within the newly registered
e" format="default"/>).</t> "/.well-known/brski" tree. For clarity, this channel is referred to
<t>The MASA URI is "https://" authority "/.well-known/est".</t> as "BRSKI-MASA" (see <xref target="architecturefigure" format="default"/>).
</t>
<t>The MASA URI is "https://" authority "/.well-known/brski".</t>
<t> <t>
BRSKI uses existing CMS message formats for existing EST BRSKI uses existing CMS message formats for existing EST
operations. BRSKI uses JSON operations. BRSKI uses JSON
<xref target="RFC8259" format="default"/> for all new operations defin <xref target="RFC8259" format="default"/> for all new operations defin
ed here, and ed here and
voucher formats. In all places where a binary value must be carried for voucher formats. In all places where a binary value must be carrie
in a JSON string, the use of base64 format (<xref target="RFC4648" for d
mat="default"/> section 4) is to be used, as per in a JSON string, a base64 format (<xref target="RFC4648"
<xref target="RFC7951" format="default"/> section 6.6. sectionFormat="comma" section="4"/>) is to be used, as per
<xref target="RFC7951" sectionFormat="comma" section="6.6"/>.
</t> </t>
<t> <t>
While EST section 3.2 does not insist upon use of HTTP While EST (<xref target="RFC7030" sectionFormat="comma" section="3.2"/ >) does not insist upon use of HTTP
persistent connections persistent connections
(<xref target="RFC7230" format="default"/> section 6.3), (<xref target="RFC7230" sectionFormat="comma" section="6.3"/>),
BRSKI-EST connections SHOULD use persistent BRSKI-EST connections <bcp14>SHOULD</bcp14> use persistent
connections. The intention of this guidance is to ensure the connections. The intention of this guidance is to ensure the
provisional TLS state occurs only once, and that the subsequent provisional TLS state occurs only once, and that the subsequent
resolution of the provision state is not subject to a MITM attack resolution of the provision state is not subject to a Man-in-the-Middl e (MITM) attack
during a critical phase. during a critical phase.
</t> </t>
<t> <t>
If non-persistent connections are used, then both the pledge and If non-persistent connections are used, then both the pledge and
the registrar MUST remember the certificates seen, and also sent the registrar <bcp14>MUST</bcp14> remember the certificates that have
for the first connection. They MUST check each subsequent been seen and also sent
connections for the same certificates, and each end MUST use for the first connection. They <bcp14>MUST</bcp14> check each subsequ
ent
connection for the same certificates, and each end <bcp14>MUST</bcp14>
use
the same certificates as well. This places a difficult restriction the same certificates as well. This places a difficult restriction
on rolling certificates on the Registrar. on rolling certificates on the registrar.
</t> </t>
<t>Summarized automation extensions for the BRSKI-EST flow are:</t> <t>Summarized automation extensions for the BRSKI-EST flow are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
The pledge either attempts concurrent connections via each The pledge either attempts concurrent connections via each
discovered proxy, or it times out quickly and tries connections discovered proxy or times out quickly and tries connections
in series, as explained at the end of <xref target="brskiesttls" f ormat="default"/>. in series, as explained at the end of <xref target="brskiesttls" f ormat="default"/>.
</li> </li>
<li> <li>
The pledge provisionally accepts the registrar certificate during The pledge provisionally accepts the registrar certificate during
the TLS handshake as detailed in <xref target="brskiesttls" format ="default"/>. the TLS handshake as detailed in <xref target="brskiesttls" format ="default"/>.
</li> </li>
<li> <li>
The pledge requests a voucher using The pledge requests a voucher using
the new REST calls described below. This voucher is then validate d. the new REST calls described below. This voucher is then validate d.
</li> </li>
skipping to change at line 1856 skipping to change at line 1925
state. state.
</li> </li>
<li> <li>
Mandatory bootstrap steps conclude with voucher status Mandatory bootstrap steps conclude with voucher status
telemetry (see <xref target="pledgestatus" format="default"/>). telemetry (see <xref target="pledgestatus" format="default"/>).
</li> </li>
</ul> </ul>
<t> <t>
The BRSKI-EST TLS connection can now be used for EST enrollment. The BRSKI-EST TLS connection can now be used for EST enrollment.
</t> </t>
<t>The extensions for a registrar (equivalent to EST server) are:</t> <t>The extensions for a registrar (equivalent to an EST server) are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Client authentication is automated using Initial Device Identity Client authentication is automated using IDevID as per the EST certi
(IDevID) as per the EST certificate based client authentication. ficate-based client authentication.
The subject field's DN encoding MUST include the "serialNumber" The subject field's DN encoding <bcp14>MUST</bcp14> include the "ser
ialNumber"
attribute with the device's unique serial number attribute with the device's unique serial number
as explained in <xref target="PledgeIdentification" format="default" /> as explained in <xref target="PledgeIdentification" format="default" />.
</li> </li>
<li>The registrar requests and validates the voucher from the MASA.</li> <li>The registrar requests and validates the voucher from the MASA.</li>
<li>The registrar forwards the voucher to the pledge when <li>The registrar forwards the voucher to the pledge when
requested.</li> requested.</li>
<li> <li>
The registrar performs log verifications (described in The registrar performs log verifications (described in
<xref target="auditLogVerification" format="default"/>) in addition to local <xref target="auditLogVerification" format="default"/>) in addition to local
authorization checks before accepting optional pledge device authorization checks before accepting optional pledge device
enrollment requests. enrollment requests.
</li> </li>
</ul> </ul>
<section anchor="brskiesttls" numbered="true" toc="default"> <section anchor="brskiesttls" numbered="true" toc="default">
<name>BRSKI-EST TLS establishment details</name> <name>BRSKI-EST TLS Establishment Details</name>
<t>The pledge establishes the TLS connection with the registrar through <t>The pledge establishes the TLS connection with the registrar through
the circuit proxy (see <xref target="proxydetails" format="defau lt"/>) the Circuit Proxy (see <xref target="proxydetails" format="defau lt"/>),
but the TLS handshake is with the registrar. The BRSKI-EST pledg e but the TLS handshake is with the registrar. The BRSKI-EST pledg e
is the TLS client and the BRSKI-EST registrar is the TLS server. is the TLS client, and the BRSKI-EST registrar is the TLS server .
All security associations established are All security associations established are
between the pledge and the registrar regardless of proxy between the pledge and the registrar regardless of proxy
operations. operations.
</t> </t>
<t> <t>
Use of TLS 1.3 (or newer) is encouraged. Use of TLS 1.3 (or newer) is encouraged.
TLS 1.2 or newer is REQUIRED on the Pledge side. TLS 1.2 or newer is <bcp14>REQUIRED</bcp14> on the pledge side.
TLS 1.3 (or newer) SHOULD be available on the Registrar server int TLS 1.3 (or newer) <bcp14>SHOULD</bcp14> be available on the regis
erface, trar server interface,
and the Registrar client interface, but TLS 1.2 MAY be used. and the registrar client interface, but TLS 1.2 <bcp14>MAY</bcp14>
TLS 1.3 (or newer) SHOULD be available on the MASA server interfac be used.
e, but TLS TLS 1.3 (or newer) <bcp14>SHOULD</bcp14> be available on the MASA
1.2 MAY be used. server interface, but TLS
1.2 <bcp14>MAY</bcp14> be used.
</t> </t>
<t> <t>
Establishment of the BRSKI-EST TLS connection is as Establishment of the BRSKI-EST TLS connection is as
specified in EST <xref target="RFC7030" format="default"/> section specified in "Bootstrap Distribution of CA Certificates" (Section
4.1.1 "Bootstrap <xref target='RFC7030' section='4.1.1' sectionFormat='bare'/>) of <xref target='
Distribution of CA Certificates" <xref target="RFC7030" format="de RFC7030' format="default"/>, wherein
fault"/> wherein
the client is authenticated with the IDevID certificate, and the the client is authenticated with the IDevID certificate, and the
EST server (the registrar) is provisionally authenticated with an unverified EST server (the registrar) is provisionally authenticated with an unverified
server certificate. server certificate.
Configuration or distribution of the trust anchor database Configuration or distribution of the trust anchor database
used for validating the IDevID certificate is out-of-scope of used for validating the IDevID certificate is out of scope of
this specification. Note that the trust anchors this specification. Note that the trust anchors
in/excluded from the database will affect which manufacturers' in / excluded from the database will affect which manufacturers'
devices are acceptable to the registrar as pledges, and can devices are acceptable to the registrar as pledges and can
also be used to limit the set of MASAs that are trusted for also be used to limit the set of MASAs that are trusted for
enrollment. enrollment.
</t> </t>
<t> <t>
The signature in the certificate MUST be validated even if a The signature in the certificate <bcp14>MUST</bcp14> be validated
signing key can not (yet) be validated. The certificate (or even if a
chain) MUST be retained for later validation. signing key cannot (yet) be validated. The certificate (or
chain) <bcp14>MUST</bcp14> be retained for later validation.
</t> </t>
<t> <t>
A self-signed A self-signed
certificate for the Registrar is acceptable as the voucher certificate for the registrar is acceptable as the voucher
can validate it upon successful enrollment. can validate it upon successful enrollment.
</t> </t>
<t>The pledge performs input validation of all data received <t>The pledge performs input validation of all data received
until a voucher is verified as specified in <xref target="Complet ingAuthenticationBootstrapping" format="default"/> and until a voucher is verified as specified in <xref target="Complet ingAuthenticationBootstrapping" format="default"/> and
the TLS connection leaves the provisional state. Until these the TLS connection leaves the provisional state. Until these
operations are complete the pledge could be communicating operations are complete, the pledge could be communicating
with an attacker. with an attacker.
</t> </t>
<t> <t>
The pledge code needs to be written with the assumption that The pledge code needs to be written with the assumption that
all data is being transmitted at this point to an all data is being transmitted at this point to an
unauthenticated peer, and that received data, while inside a unauthenticated peer, and that received data, while inside a
TLS connection, MUST be considered untrusted. This TLS connection, <bcp14>MUST</bcp14> be considered untrusted. This
particularly applies to HTTP headers and CMS structures that particularly applies to HTTP headers and CMS structures that
make up the voucher. make up the voucher.
</t> </t>
<t> <t>
A pledge that can connect to multiple Registrars concurrently A pledge that can connect to multiple registrars concurrently
SHOULD do so. Some devices may be unable to do so for lack of <bcp14>SHOULD</bcp14> do so. Some devices may be unable to do so
for lack of
threading, or resource issues. Concurrent connections defeat threading, or resource issues. Concurrent connections defeat
attempts by a malicious proxy from causing a TCP Slowloris-like attempts by a malicious proxy from causing a TCP Slowloris-like
attack (see <xref target="slowloris" format="default"/>). attack (see <xref target="slowloris" format="default"/>).
</t> </t>
<t> <t>
A pledge that can not maintain as many connections as there are A pledge that cannot maintain as many connections as there are
eligible proxies will need to rotate among the various choices, eligible proxies will need to rotate among the various choices,
terminating connections that do not appear to be making terminating connections that do not appear to be making
progress. progress.
If no connection is making progress after 5 seconds then the If no connection is making progress after 5 seconds, then the
pledge SHOULD drop the oldest connection and go on to a pledge <bcp14>SHOULD</bcp14> drop the oldest connection and go on
different proxy: the proxy that has been to a
communicated with least recently. different proxy: the proxy that has been communicated with least r
ecently.
If there were no If there were no
other proxies discovered, the pledge MAY continue to wait, other proxies discovered, the pledge <bcp14>MAY</bcp14> continue t o wait,
as long as it is concurrently listening for new proxy as long as it is concurrently listening for new proxy
announcements. announcements.
</t> </t>
</section> </section>
<section anchor="RequestVoucherFromRegistrar" numbered="true" toc="default "> <section anchor="RequestVoucherFromRegistrar" numbered="true" toc="default ">
<name>Pledge Requests Voucher from the Registrar</name> <name>Pledge Requests Voucher from the Registrar</name>
<t>When the pledge bootstraps it makes a request for a voucher from a <t>When the pledge bootstraps, it makes a request for a voucher from a
registrar.</t> registrar.</t>
<t>This is done with an HTTPS POST using the operation path value of <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>
<t>The pledge voucher-request Content-Type is as follows.</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>application/voucher-cms+json</dt> <dt>application/voucher-cms+json:</dt>
<dd> <dd><xref target="RFC8366" format="default"/> defines a "YANG-defined
<xref target="RFC8366" format="default"/> defines a JSON document that has been signed using a Cryptographic Message Syntax (CMS)
"YANG-defined JSON document that has been signed using a CMS
structure", and the voucher-request described in structure", and the voucher-request described in
<xref target="voucher-request" format="default"/> is created in the s ame way. <xref target="voucher-request" format="default"/> is created in the s ame way.
The media type is the same as defined in <xref target="RFC8366" forma t="default"/>. The media type is the same as defined in <xref target="RFC8366" forma t="default"/>.
This is also used for the pledge voucher-request. This is also used for the pledge voucher-request.
The pledge MUST sign the request using the The pledge <bcp14>MUST</bcp14> sign the request using the
<xref target="IDevIDextension" format="default"/> credential. credentials in <xref target="IDevIDextension" format="default"/>.
</dd> </dd>
</dl> </dl>
<t>Registrar <t>Registrar
implementations SHOULD anticipate future media types but of course will simply fail the request if those implementations <bcp14>SHOULD</bcp14> anticipate future media types but, of course, will simply fail the request if those
types are not yet known.</t> types are not yet known.</t>
<t> <t>
The pledge SHOULD include an <xref target="RFC7231" format="default"/> The pledge <bcp14>SHOULD</bcp14> include an
section 5.3.2 "Accept" header field (see <xref target="RFC7231" sectionFormat="comma
"Accept" header field indicating the acceptable media type for the vou " section="5.3.2"/>) indicating the acceptable media type for the voucher
cher
response. The "application/voucher-cms+json" media type is defined response. The "application/voucher-cms+json" media type is defined
in <xref target="RFC8366" format="default"/> but constrained voucher f ormats are in <xref target="RFC8366" format="default"/>, but constrained voucher formats are
expected in the future. Registrars and MASA are expected to be expected in the future. Registrars and MASA are expected to be
flexible in what they accept. flexible in what they accept.
</t> </t>
<t>The pledge populates the voucher-request fields as follows:</t> <t>The pledge populates the voucher-request fields as follows:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>created-on:</dt> <dt>created-on:</dt>
<dd>Pledges that have a realtime clock are <dd>Pledges that have a real-time clock are
RECOMMENDED to populate this field with the current date and <bcp14>RECOMMENDED</bcp14> to populate this field with the current d
ate and
time in yang:date-and-time format. This provides additional time in yang:date-and-time format. This provides additional
information to the MASA. information to the MASA.
Pledges that have no real-time clocks MAY omit this field. Pledges that have no real-time clocks <bcp14>MAY</bcp14> omit this f ield.
</dd> </dd>
<dt>nonce:</dt> <dt>nonce:</dt>
<dd>The pledge voucher-request MUST contain a <dd>The pledge voucher-request <bcp14>MUST</bcp14> contain a
cryptographically strong random or pseudo-random number cryptographically strong random or pseudo-random number
nonce (see <xref target="RFC4086" format="default"/> section 6.2). nonce (see <xref target="RFC4086" sectionFormat="comma" section="6.2
As the nonce is usually generated very early in the boot sequence "/>).
there is a concern that the same nonce might generated across As the nonce is usually generated very early in the boot sequence,
there is a concern that the same nonce might be generated across
multiple boots, or after a factory reset. multiple boots, or after a factory reset.
Different nonces MUST be generated for each bootstrapping Different nonces <bcp14>MUST</bcp14> be generated for each bootstrap ping
attempt, whether in series or concurrently. attempt, whether in series or concurrently.
The freshness of this nonce mitigates against the lack of real-time The freshness of this nonce mitigates against the lack of a real-tim e
clock as explained in <xref target="timeunknown" format="default"/>. clock as explained in <xref target="timeunknown" format="default"/>.
</dd> </dd>
<dt>assertion:</dt> <dt>assertion:</dt>
<dd> <dd>
The pledge indicates support for the mechanism The pledge indicates support for the mechanism
described in this document, by putting the value "proximity" in th e described in this document, by putting the value "proximity" in th e
voucher-request, MUST include the voucher-request, and <bcp14>MUST</bcp14> include the
"proximity-registrar-cert" field (below). proximity-registrar-cert field (below).
</dd> </dd>
<dt>proximity-registrar-cert:</dt> <dt>proximity-registrar-cert:</dt>
<dd>In a pledge <dd>In a pledge
voucher-request this is the first certificate in the TLS server voucher-request, this is the first certificate in the TLS server
'certificate_list' sequence (see [RFC5246]) presented by the "certificate_list" sequence (see <xref target="RFC8446" sectionForma
t="comma" section="4.4.2"/>) presented by the
registrar to the pledge. That is, it is the end-entity registrar to the pledge. That is, it is the end-entity
certificate. This MUST be populated in a pledge voucher-request. certificate. This <bcp14>MUST</bcp14> be populated in a pledge vouch er-request.
</dd> </dd>
<dt>serial-number</dt> <dt>serial-number:</dt>
<dd>The serial number of the pledge <dd>The serial number of the pledge
is included in the voucher-request from the Pledge. This value is is included in the voucher-request from the pledge. This value is
included as a sanity check only, but it is not to be forwarded included as a sanity check only, but it is not to be forwarded
by the Registrar as described in <xref target="RequestVoucherFromMAS A" format="default"/>. by the registrar as described in <xref target="RequestVoucherFromMAS A" format="default"/>.
</dd> </dd>
</dl> </dl>
<t>All other fields MAY be omitted in the pledge voucher-request.</t> <t>All other fields <bcp14>MAY</bcp14> be omitted in the pledge voucher-
<t>An example JSON payload of a pledge voucher-request is in request.</t>
<xref target="voucher-request-examples" format="default"/> Example 1 <t>See an example JSON payload of a pledge voucher-request in
.</t> <xref target="voucher-request-examples" format="default"/>, Example
1.</t>
<t> <t>
The registrar confirms that the The registrar confirms that the
assertion is 'proximity' and that pinned assertion is "proximity" and that pinned
'proximity-registrar-cert' is the Registrar's certificate. proximity-registrar-cert is the registrar's certificate.
If this validation fails, then there is an On-Path Attacker (MITM), If this validation fails, then there is an on-path attacker (MITM),
and the connection MUST be closed after the returning an and the connection <bcp14>MUST</bcp14> be closed after the returning o
f an
HTTP 401 error code. HTTP 401 error code.
</t> </t>
</section> </section>
<section anchor="pledgeauthorization" numbered="true" toc="default"> <section anchor="pledgeauthorization" numbered="true" toc="default">
<name>Registrar Authorization of Pledge</name> <name>Registrar Authorization of Pledge</name>
<t> <t>
In a fully automated network all devices must be securely identified In a fully automated network, all devices must be securely identified
and authorized to join the domain. and authorized to join the domain.
</t> </t>
<t> <t>
A Registrar accepts or declines a request to join the domain, based A registrar accepts or declines a request to join the domain, based
on the authenticated identity presented. For different networks, on the authenticated identity presented. For different networks,
examples of automated acceptance may include:</t> examples of automated acceptance may include the allowance of:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>allow any device of a specific type (as determined by the X.509 <li>any device of a specific type (as determined by the X.509
IDevID),</li> IDevID),</li>
<li>allow any device from a specific vendor (as determined by the <li>any device from a specific vendor (as determined by the
X.509 IDevID),</li> X.509 IDevID),</li>
<li>allow a specific device from a vendor (as determined by the X.509 <li>a specific device from a vendor (as determined by the X.509
IDevID) against a domain white list. (The mechanism for checking IDevID) against a domain acceptlist. (The mechanism for checking
a shared white list potentially used by multiple Registrars is out a shared acceptlist potentially used by multiple registrars is out
of scope).</li> of scope.)</li>
</ul> </ul>
<t> <t>
If validation fails the registrar SHOULD respond with the If validation fails, the registrar <bcp14>SHOULD</bcp14> respond with the
HTTP 404 error code. If the voucher-request is in an unknown HTTP 404 error code. If the voucher-request is in an unknown
format, then an HTTP 406 error code is more appropriate. format, then an HTTP 406 error code is more appropriate.
A situation that could be resolved with administrative action A situation that could be resolved with administrative action
(such as adding a vendor to a whitelist) MAY be responded with an (such as adding a vendor to an acceptlist) <bcp14>MAY</bcp14> be respo nded to with a
403 HTTP error code. 403 HTTP error code.
</t> </t>
<t>If authorization is successful the registrar obtains a voucher from t <t>If authorization is successful, the registrar obtains a voucher from
he MASA service (see the MASA service (see
<xref target="RequestVoucherFromMASA" format="default"/>) and return <xref target="RequestVoucherFromMASA" format="default"/>) and return
s that MASA signed voucher to the pledge s that MASA-signed voucher to the pledge
as described in <xref target="VoucherResponse" format="default"/>.</t> as described in <xref target="VoucherResponse" format="default"/>.</t>
</section> </section>
<section anchor="brskimasatls" numbered="true" toc="default"> <section anchor="brskimasatls" numbered="true" toc="default">
<name>BRSKI-MASA TLS establishment details</name> <name>BRSKI-MASA TLS Establishment Details</name>
<t> <t>
The BRSKI-MASA TLS connection is a 'normal' TLS connection The BRSKI-MASA TLS connection is a "normal" TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in connection and uses the MASA URL that is obtained as described in
<xref target="obtainmasaurl" format="default"/>. The mechanisms in <xref target="obtainmasaurl" format="default"/>. The mechanisms in
<xref target="RFC6125" format="default"/> SHOULD be used in authentica tion of the <xref target="RFC6125" format="default"/> <bcp14>SHOULD</bcp14> be use d in authentication of the
MASA using a DNS-ID that matches that which is found in the IDevID. MASA using a DNS-ID that matches that which is found in the IDevID.
Registrars MAY include a mechanism to override the MASA URL on a Registrars <bcp14>MAY</bcp14> include a mechanism to override the MASA
manufacturer-by-manufacturer basis, and within that override it is URL on a
manufacturer-by-manufacturer basis, and within that override, it is
appropriate to provide alternate anchors. appropriate to provide alternate anchors.
This will typically used by some vendors to establish explicit This will typically be used by some vendors to establish explicit
(or private) trust (or private) trust
anchors for validating their MASA that is part of a sales channel anchors for validating their MASA that is part of a sales channel
integration. integration.
</t> </t>
<t> <t>
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. TLS 1.3 (or newer) SHOULD be available. <bcp14>REQUIRED</bcp14>. TLS 1.3 (or newer) <bcp14>SHOULD</bcp14> be available.
</t> </t>
<t> <t>
As described in <xref target="RFC7030" format="default"/>, the MASA an d the As described in <xref target="RFC7030" format="default"/>, the MASA an d the
registrars SHOULD be prepared to support TLS client registrars <bcp14>SHOULD</bcp14> be prepared to support TLS Client
certificate authentication and/or HTTP Basic, Digest, or SCRAM authent Certificate authentication and/or HTTP Basic, Digest, or Salted Challe
ication. nge Response Authentication Mechanism (SCRAM) authentication.
This connection MAY also have no client authentication at all. This connection <bcp14>MAY</bcp14> also have no client authentication
at all.
</t> </t>
<t> <t>
Registrars SHOULD permit Registrars <bcp14>SHOULD</bcp14> permit
trust anchors to be pre-configured on a per-vendor(MASA) basis. trust anchors to be preconfigured on a per-vendor (MASA) basis.
Registrars SHOULD include the ability to configure a TLS Registrars <bcp14>SHOULD</bcp14> include the ability to configure a TL
ClientCertificate on a per-MASA basis, or to use no client S
certificate. Registrars SHOULD also permit HTTP Basic and Client Certificate on a per-MASA basis, or to use no Client
Certificate. Registrars <bcp14>SHOULD</bcp14> also permit HTTP Basic
and
Digest authentication to be configured. Digest authentication to be configured.
</t> </t>
<t> <t>
The authentication of the BRSKI-MASA The authentication of the BRSKI-MASA
connection does not change the voucher-request process, as connection does not change the voucher-request process, as
voucher-requests are already signed by the registrar. voucher-requests are already signed by the registrar.
Instead, this authentication provides access control to the Instead, this authentication provides access control to the
audit-log as described in <xref target="authzLogRequest" format="defau lt"/>. audit-log as described in <xref target="authzLogRequest" format="defau lt"/>.
</t> </t>
<t> <t>
Implementors are advised that Implementers are advised that
contacting the MASA is to establish a secured API connection with a contacting the MASA establishes a secured API connection with a
web service and that there are a number of authentication models web service, and that there are a number of authentication models
being explored within the industry. Registrars are RECOMMENDED to being explored within the industry. Registrars are <bcp14>RECOMMENDED<
/bcp14> to
fail gracefully and generate useful administrative notifications or fail gracefully and generate useful administrative notifications or
logs in the advent of unexpected HTTP 401 (Unauthorized) responses logs in the advent of unexpected HTTP 401 (Unauthorized) responses
from the MASA. from the MASA.
</t> </t>
<section anchor="masaauthentication" numbered="true" toc="default"> <section anchor="masaauthentication" numbered="true" toc="default">
<name>MASA authentication of customer Registrar</name> <name>MASA Authentication of Customer Registrar</name>
<t> <t>
Providing per-customer options requires that the customer's Providing per-customer options requires the customer's
registrar be uniquely identified. This can be done by any stateless registrar to be uniquely identified. This can be done by any statel
method that HTTPS supports such as with HTTP Basic ess
method that HTTPS supports such as HTTP Basic
or Digest authentication (that is using a password), but the use or Digest authentication (that is using a password), but the use
of TLS Client Certificate authentication is RECOMMENDED. of TLS Client Certificate authentication is <bcp14>RECOMMENDED</bcp1 4>.
</t> </t>
<t> <t>
Stateful methods involving API tokens, or HTTP Cookies, are not Stateful methods involving API tokens, or HTTP Cookies, are not
recommended. recommended.
</t> </t>
<t> <t>
It is expected that the setup and configuration of per-customer It is expected that the setup and configuration of per-customer
Client Certificates is done as part of a sales ordering process. Client Certificates is done as part of a sales ordering process.
</t> </t>
<t> <t>
The use of public PKI (i.e. WebPKI) End-Entity Certificates to The use of public PKI (i.e., WebPKI) end-entity certificates to
identify the Registrar is reasonable, and if done universally identify the registrar is reasonable, and if done universally,
this would permit a MASA to identify a customers' Registrar simply b this would permit a MASA to identify a customer's registrar simply b
y a y a
FQDN. Fully Qualified Domain Name (FQDN).
</t> </t>
<t> <t>
The use of DANE records in DNSSEC signed zones would also permit use The use of DANE records in DNSSEC-signed zones would also permit use
of of
a FQDN to identify customer Registrars. a FQDN to identify customer registrars.
</t> </t>
<t> <t>
A third (and simplest, but least flexible) mechanism would be for A third (and simplest, but least flexible) mechanism would be for
the MASA to simply store the Registrar's certificate pinned in a the MASA to simply store the registrar's certificate pinned in a
database. database.
</t> </t>
<t> <t>
A MASA without any supply chain integration can simply accept A MASA without any supply-chain integration can simply accept
Registrars without any authentication, or can accept them on a registrars without any authentication or on a
blind Trust-on-First-Use basis as described in <xref target="masasec blind TOFU basis as described in <xref target="masasecurityreduction
urityreduction_tofu" format="default"/>. _tofu" format="default"/>.
</t> </t>
<t> <t>
This document does not make a specific recommendation on how the This document does not make a specific recommendation on how the
MASA authenticates the Registrar as there are MASA authenticates the registrar as there are
likely different tradeoffs in different environments and product likely different tradeoffs in different environments and product
values. Even within the ANIMA ACP applicability, there is a values. Even within the ANIMA ACP applicability, there is a
significant difference between supply chain logistics for $100 significant difference between supply-chain logistics for $100
CPE devices and $100,000 core routers. CPE devices and $100,000 core routers.
</t> </t>
</section> </section>
</section> </section>
<section anchor="RequestVoucherFromMASA" numbered="true" toc="default"> <section anchor="RequestVoucherFromMASA" numbered="true" toc="default">
<name>Registrar Requests Voucher from MASA</name> <name>Registrar Requests Voucher from MASA</name>
<t> <t>
When a registrar receives a pledge voucher-request it in turn When a registrar receives a pledge voucher-request, it in turn
submits a registrar voucher-request to the MASA service via an submits a registrar voucher-request to the MASA service via an
HTTPS interface (<xref target="RFC7231" format="default"/>). HTTPS interface <xref target="RFC7231" format="default"/>.
</t> </t>
<t>This is done with an HTTP POST using the operation path value of <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 <t>The voucher media type "application/voucher-cms+json" is defined in
<xref target="RFC8366" format="default"/> and is also used for the reg istrar voucher-request. It is a JSON document that has been <xref target="RFC8366" format="default"/> and is also used for the reg istrar voucher-request. It is a JSON document that has been
signed using a CMS structure. signed using a CMS structure.
The registrar MUST sign the registrar voucher-request. The registrar <bcp14>MUST</bcp14> sign the registrar voucher-request.
</t> </t>
<t> <t>
MASA implementations SHOULD anticipate future media MASA implementations <bcp14>SHOULD</bcp14> anticipate future media
ntypes but of course will simply fail the request if those types are ntypes but, of course, will simply fail the request if those types are
not yet known. not yet known.
</t> </t>
<t> <t>
The voucher-request CMS object includes some number of certificates The voucher-request CMS object includes some number of certificates
that are input to the MASA as it populates the that are input to the MASA as it populates the
'pinned-domain-cert'. As the pinned-domain-cert. As
<xref target="RFC8366" format="default"/> is quite flexible in what ma y be put into <xref target="RFC8366" format="default"/> is quite flexible in what ma y be put into
the 'pinned-domain-cert', the MASA needs some signal as to what the pinned-domain-cert, the MASA needs some signal as to what
certificate would be effective to populate the field with: it may certificate would be effective to populate the field with: it may
range from the End Entity (EE) Certificate that the Registrar uses, range from the end-entity certificate that the registrar uses
to the entire private Enterprise CA certificate. to the entire private Enterprise CA certificate.
More specific certificates result in a tighter binding of the More-specific certificates result in a tighter binding of the
voucher to the domain, while less specific certificates result in voucher to the domain, while less-specific certificates result in
more flexibility in how the domain is represented by certificates. more flexibility in how the domain is represented by certificates.
</t> </t>
<t> <t>
A Registrar which is seeking a nonceless voucher for later offline use A registrar that is seeking a nonceless voucher for later offline use
benefits from a less specific certificate, as it permits the actual benefits from a less-specific certificate, as it permits the actual
keypair used by a future Registrar to be determined by the pinned key pair used by a future registrar to be determined by the pinned
certificate authority. CA.
</t> </t>
<t> <t>
In some cases, a less specific certificate, such a public WebPKI In some cases, a less-specific certificate, such as a public WebPKI
certificate authority, could be too open, and could permit any CA, could be too open and could permit any
entity issued a certificate by that entity issued a certificate by that
authority to assume ownership of a device authority to assume ownership of a device
that has a voucher pinned. that has a voucher pinned.
Future work may provide a solution to pin both a certificate and a Future work may provide a solution to pin both a certificate and a
name that would reduce such risk of malicious ownership assertions. name that would reduce such risk of malicious ownership assertions.
</t> </t>
<t> <t>
The Registrar SHOULD request a voucher with the most specificity The registrar <bcp14>SHOULD</bcp14> request a voucher with the most sp ecificity
consistent with the mode that it is operating in. consistent with the mode that it is operating in.
In order to do this, when the Registrar prepares the CMS structure In order to do this, when the registrar prepares the CMS structure
for the signed voucher-request, it SHOULD include only certificates for the signed voucher-request, it <bcp14>SHOULD</bcp14> include only
which are part of the chain that it wishes the MASA to pin. certificates
This MAY be as small as only the End-Entity certificate (with id-kp-cm that are a part of the chain that it wishes the MASA to pin.
cRA set) that This <bcp14>MAY</bcp14> be as small as only the end-entity certificate
it uses as it's TLS Server Certificate, or it MAY be the entire (with id-kp-cmcRA set) that
chain, including the Domain CA. it uses as its TLS server certificate, or it <bcp14>MAY</bcp14> be the
entire
chain, including the domain CA.
</t> </t>
<t> <t>
The Registrar SHOULD include an <xref target="RFC7231" format="default The registrar <bcp14>SHOULD</bcp14> include an "Accept" header field (
"/> section see <xref target="RFC7231" sectionFormat="comma" section="5.3.2"/>) indicating t
5.3.2 "Accept" header field indicating the response media types that a he response
re media types that are
acceptable. This list SHOULD be the entire list presented to the acceptable. This list <bcp14>SHOULD</bcp14> be the entire list present
Registrar in the Pledge's original request (see <xref target="RequestV ed to the
oucherFromRegistrar" format="default"/>) but MAY be a subset. registrar in the pledge's original request (see <xref target="RequestV
oucherFromRegistrar" format="default"/>), but it <bcp14>MAY</bcp14> be a subset.
The MASA is expected to be flexible in what it accepts. The MASA is expected to be flexible in what it accepts.
</t> </t>
<t>The registrar populates the voucher-request fields as follows:</t> <t>The registrar populates the voucher-request fields as follows:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>created-on:</dt> <dt>created-on:</dt>
<dd> <dd>
The Registrars SHOULD populate this field with the current date and The registrar <bcp14>SHOULD</bcp14> populate this field with the curre
time when the Registrar formed this voucher request. This field nt date and
time when the voucher-request is formed. This field
provides additional information to the MASA. provides additional information to the MASA.
</dd> </dd>
<dt>nonce:</dt> <dt>nonce:</dt>
<dd>This value, if present, is copied from the pledge <dd>This value, if present, is copied from the pledge
voucher-request. The registrar voucher-request MAY omit voucher-request. The registrar voucher-request <bcp14>MAY</bcp14> om it
the nonce as per <xref target="noncelessVoucherRequest" format="defa ult"/>. the nonce as per <xref target="noncelessVoucherRequest" format="defa ult"/>.
</dd> </dd>
<dt>serial-number:</dt> <dt>serial-number:</dt>
<dd>The serial number of the pledge the registrar would like a voucher for. The registrar <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 certifi determines this value by parsing the authenticated pledge IDevID certifi
cate. See <xref target="IDevIDextension" format="default"/>. cate; see <xref target="IDevIDextension" format="default"/>.
The registrar MUST verify that the serial number field it parsed matches The registrar <bcp14>MUST</bcp14> verify that the serial-number field it
the serial number field the pledge parsed matches the serial-number field the pledge
provided in its voucher-request. This provides a sanity check useful for detecting error conditions and logging. provided in its voucher-request. This provides a sanity check useful for detecting error conditions and logging.
The registrar MUST NOT simply copy the serial number field from a pledge voucher request as that field is claimed but The registrar <bcp14>MUST NOT</bcp14> simply copy the serial-number fiel d from a pledge voucher-request as that field is claimed but
not certified.</dd> not certified.</dd>
<dt>idevid-issuer:</dt> <dt>idevid-issuer:</dt>
<dd>The Issuer value from the <dd>The Issuer value from the
pledge IDevID certificate is included to ensure unique interpretation of the pledge IDevID certificate is included to ensure unique interpretation of the
serial-number. In the case of nonceless (offline) voucher-request, then an serial-number. In the case of a nonceless (offline) voucher-request, an
appropriate value needs to be configured from the same out-of-band sourc e as the serial-number. appropriate value needs to be configured from the same out-of-band sourc e as the serial-number.
</dd> </dd>
<dt>prior-signed-voucher-request:</dt> <dt>prior-signed-voucher-request:</dt>
<dd>The signed pledge <dd>The signed pledge
voucher-request SHOULD be included in the registrar voucher-request. voucher-request <bcp14>SHOULD</bcp14> be included in the registrar vouch
The entire CMS signed structure is to be included, base64 encoded for er-request.
The entire CMS-signed structure is to be included and base64 encoded for
transport in the JSON structure. transport in the JSON structure.
</dd> </dd>
</dl> </dl>
<t> <t>
A nonceless registrar voucher-request MAY be A nonceless registrar voucher-request <bcp14>MAY</bcp14> be
submitted to the MASA. Doing so allows submitted to the MASA. Doing so allows
the registrar to request a voucher when the pledge is offline, or the registrar to request a voucher when the pledge is offline, or
when the registrar anticipates not being able to connect to the when the registrar anticipates not being able to connect to the
MASA MASA
while the pledge is being deployed. Some use cases require the while the pledge is being deployed. Some use cases require the
registrar to learn the registrar to learn the
appropriate IDevID SerialNumber field and appropriate 'Accept header f appropriate IDevID serialNumber field and appropriate "Accept" header
ield' values from the physical device field values from the physical device
labeling or from the sales channel (out-of-scope for this labeling or from the sales channel (which is out of scope for this
document). document).
</t> </t>
<t>All other fields MAY be omitted in the registrar <t>All other fields <bcp14>MAY</bcp14> be omitted in the registrar
voucher-request.</t> voucher-request.</t>
<t> <t>
The "proximity-registrar-cert" field MUST NOT be present in the The proximity-registrar-cert field <bcp14>MUST NOT</bcp14> be present in the
registrar voucher-request. registrar voucher-request.
</t> </t>
<t>Example JSON payloads of registrar voucher-requests are in <t>See example JSON payloads of registrar voucher-requests in
<xref target="voucher-request-examples" format="default"/> Examples <xref target="voucher-request-examples" format="default"/>, Examples
2 through 4.</t> 2 through 4.</t>
<t>The MASA verifies that the registrar voucher-request is internally co
nsistent <t>The MASA verifies that the registrar voucher-request is internally con
sistent
but does not necessarily authenticate the registrar certificate since th e but does not necessarily authenticate the registrar certificate since th e
registrar MAY be unknown to the MASA in advance. The MASA registrar <bcp14>MAY</bcp14> be unknown to the MASA in advance. The MASA
performs the actions and validation checks described in the following performs the actions and validation checks described in the following
sub-sections before issuing a voucher.</t> subsections before issuing a voucher.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>MASA renewal of expired vouchers</name> <name>MASA Renewal of Expired Vouchers</name>
<t> <t>
As described in As described in
<xref target="RFC8366" format="default"/> vouchers <xref target="RFC8366" format="default"/>, vouchers
are normally short lived to avoid revocation issues. If the request are normally short lived to avoid revocation issues. If the request
is for a previous (expired) voucher using the same registrar is for a previous (expired) voucher using the same registrar
(that is, a Registrar with the same Domain CA) (that is, a registrar with the same domain CA),
then the request for then the request for
a renewed voucher SHOULD be automatically authorized. The MASA has a renewed voucher <bcp14>SHOULD</bcp14> be automatically authorized. The MASA has
sufficient information to determine this by examining the request, t he registrar sufficient information to determine this by examining the request, t he registrar
authentication, and the existing audit-log. The issuance of a renewe d voucher is authentication, and the existing audit-log. The issuance of a renewe d voucher is
logged as detailed in <xref target="VoucherResponse" format="default "/>. logged as detailed in <xref target="VoucherResponse" format="default "/>.
</t> </t>
<t>To inform the MASA that existing vouchers are not to be renewed one <t>To inform the MASA that existing vouchers are not to be renewed, on
can update or revoke the registrar credentials used to authorize the e
request (see can update or revoke the registrar credentials used to authorize the
<xref target="MASAauthenticationOfRegistrar" format="default"/> and request (see Sections
<xref target="revocationcheck" format="default"/>). More <xref target="MASAauthenticationOfRegistrar" format="counter"/> and
<xref target="revocationcheck" format="counter"/>). More
flexible methods will likely involve sales channel integration and flexible methods will likely involve sales channel integration and
authorizations (details are out-of-scope of this document).</t> authorizations (details are out of scope of this document).</t>
</section> </section>
<section anchor="MASApinned" numbered="true" toc="default"> <section anchor="MASApinned" numbered="true" toc="default">
<name>MASA pinning of registrar</name> <name>MASA Pinning of Registrar</name>
<t> <t>
A certificate chain is extracted from the Registrar's signed CMS con A certificate chain is extracted from the registrar's signed CMS con
tainer. tainer.
This chain may be as short as a single End-Entity Certificate, up This chain may be as short as a single end-entity certificate, up
to the entire registrar certificate chain, including the Domain to the entire registrar certificate chain, including the domain
CA certificate, CA certificate,
as specified in <xref target="RequestVoucherFromMASA" format="defaul t"/>. as specified in <xref target="RequestVoucherFromMASA" format="defaul t"/>.
</t> </t>
<t> <t>
If the domain's CA is unknown to the MASA, then it is to be If the domain's CA is unknown to the MASA, then it is
considered a temporary trust anchor for the rest of the steps considered a temporary trust anchor for the rest of the steps
in this section. The intention is not to authenticate the in this section. The intention is not to authenticate the
message as having come from a fully validated origin, but message as having come from a fully validated origin but
to establish the consistency of the domain PKI. to establish the consistency of the domain PKI.
</t> </t>
<t> <t>
The MASA MAY use the certificate farthest in the chain The MASA <bcp14>MAY</bcp14> use the certificate in the chain that is
chain that it received from the Registrar from the farthest
end-entity, as determined by MASA policy. from the end-entity certificate of the registrar, as determined by M
A MASA MAY have a local policy that it only pins the End-Entity ASA policy.
A MASA <bcp14>MAY</bcp14> have a local policy in which it only pins
the end-entity
certificate. This is consistent with <xref target="RFC8366" format=" default"/>. certificate. This is consistent with <xref target="RFC8366" format=" default"/>.
Details of the policy will typically depend upon the degree of Details of the policy will typically depend upon the degree of
Supply Chain Integration, and the mechanism used by the Registrar to supply-chain integration and the mechanism used by the registrar to
authenticate. Such a policy would also determine how authenticate. Such a policy would also determine how
the MASA will respond to a request for a nonceless voucher. the MASA will respond to a request for a nonceless voucher.
</t> </t>
</section> </section>
<section anchor="revocationcheck" numbered="true" toc="default"> <section anchor="revocationcheck" numbered="true" toc="default">
<name>MASA checking of voucher request signature</name> <name>MASA Check of the Voucher-Request Signature</name>
<t> <t>
As described in <xref target="MASApinned" format="default"/>, the MA SA has As described in <xref target="MASApinned" format="default"/>, the MA SA has
extracted Registrar's domain CA. This is used to validate the extracted the registrar's domain CA. This is used to validate the
CMS signature (<xref target="RFC5652" format="default"/>) on the vou CMS signature <xref target="RFC5652" format="default"/> on the vouch
cher-request. er-request.
</t> </t>
<t> <t>
Normal PKIX revocation Normal PKIX revocation
checking is assumed during voucher-request signature validation. checking is assumed during voucher-request signature validation.
This CA certificate MAY have This CA certificate <bcp14>MAY</bcp14> have
Certificate Revocation List distribution points, or Online Certificate Revocation List (CRL) distribution points or Online
Certificate Status Protocol (OCSP) information (<xref target="RFC696 Certificate Status Protocol (OCSP) information <xref target="RFC6960
0" format="default"/>). If they are present, the MASA MUST " format="default"/>. If they are present, the MASA <bcp14>MUST</bcp14>
be able to reach the relevant servers belonging to the be able to reach the relevant servers belonging to the
Registrar's domain CA to perform the revocation checks. registrar's domain CA to perform the revocation checks.
</t> </t>
<t> <t>
The use of OCSP Stapling is preferred. The use of OCSP Stapling is preferred.
</t> </t>
</section> </section>
<section anchor="MASAauthenticationOfRegistrar" numbered="true" toc="def ault"> <section anchor="MASAauthenticationOfRegistrar" numbered="true" toc="def ault">
<name>MASA verification of domain registrar</name> <name>MASA Verification of the Domain Registrar</name>
<t> <t>
The MASA MUST verify that the registrar voucher-request is signed The MASA <bcp14>MUST</bcp14> verify that the registrar voucher-reque st is signed
by a registrar. This is confirmed by verifying that the by a registrar. This is confirmed by verifying that the
id-kp-cmcRA extended key usage extension field (as detailed in id-kp-cmcRA extended key usage extension field (as detailed in
EST RFC7030 section 3.6.1) exists in the certificate of the EST <xref target="RFC7030" sectionFormat="comma" section="3.6.1"/>) exists in the certificate of the
entity that signed the registrar voucher-request. This entity that signed the registrar voucher-request. This
verification is only a consistency check that the unauthenticated verification is only a consistency check to ensure that the unauthen ticated
domain CA intended the voucher-request signer to be a registrar. Per forming this check domain CA intended the voucher-request signer to be a registrar. Per forming this check
provides value to the domain PKI by assuring the domain administrato r provides value to the domain PKI by assuring the domain administrato r
that the MASA service will only respect claims from authorized that the MASA service will only respect claims from authorized
Registration Authorities of the domain. registration authorities of the domain.
</t> </t>
<t> <t>
Even when a domain CA is authenticated to the MASA, and there is Even when a domain CA is authenticated to the MASA, and there is
strong sales channel integration to understand who the legitimate strong sales channel integration to understand who the legitimate
owner is, the above id-kp-cmcRA check prevents arbitrary End-Entity owner is, the above id-kp-cmcRA check prevents arbitrary end-entity
certificates (such as an LDevID certificate) from certificates (such as an LDevID certificate) from
having vouchers issued against them. having vouchers issued against them.
</t> </t>
<t> <t>
Other cases of inappropriate voucher issuance are detected Other cases of inappropriate voucher issuance are detected
by examination of the audit log. by examination of the audit-log.
</t> </t>
<t> <t>
If a nonceless voucher-request is submitted the MASA MUST If a nonceless voucher-request is submitted, the MASA <bcp14>MUST</b
authenticate the registrar as described in either cp14>
EST <xref target="RFC7030" format="default"/> section 3.2.3, section authenticate the registrar either as described in
3.3.2, EST (see Sections <xref target="RFC7030" sectionFormat="bare" sectio
n="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 or by validating the registrar's certificate used to
sign the registrar voucher-request using a configured trust anchor. sign the registrar voucher-request using a configured trust anchor.
Any of these methods reduce the risk of DDoS attacks Any of these methods reduce the risk of DDoS attacks
and provide an authenticated identity as an input to and provide an authenticated identity as an input to
sales channel integration and authorizations sales channel integration and authorizations
(details are out-of-scope of this document). (details are out of scope of this document).
</t> </t>
<t> <t>
In the nonced case, validation of the Registrar's identity (via In the nonced case, validation of the registrar's identity (via
TLS Client Certificate or HTTP authentication) MAY be omitted TLS Client Certificate or HTTP authentication) <bcp14>MAY</bcp14> be
if the device policy is to accept audit-only vouchers. omitted
if the MASA knows that the device policy is to accept audit-only vou
chers.
</t> </t>
</section> </section>
<section anchor="MASAassertion" numbered="true" toc="default"> <section anchor="MASAassertion" numbered="true" toc="default">
<name>MASA verification of pledge prior-signed-voucher-request</name> <name>MASA Verification of the Pledge 'prior-signed-voucher-request'</ name>
<t> <t>
The MASA MAY verify that the registrar voucher-request The MASA <bcp14>MAY</bcp14> verify that the registrar voucher-reques
includes the 'prior-signed-voucher-request' field. If so the t
prior-signed-voucher-request MUST include a includes the prior-signed-voucher-request field. If so, the
'proximity-registrar-cert' that is consistent with the prior-signed-voucher-request <bcp14>MUST</bcp14> include a
proximity-registrar-cert that is consistent with the
certificate used to sign the registrar voucher-request. certificate used to sign the registrar voucher-request.
Additionally the Additionally, the
voucher-request serial-number leaf MUST match the pledge voucher-request serial-number leaf <bcp14>MUST</bcp14> match the ple
dge
serial-number that the MASA extracts from the signing certificate serial-number that the MASA extracts from the signing certificate
of the prior-signed-voucher-request. of the prior-signed-voucher-request.
The consistency check described above is checking that the The consistency check described above entails checking that the
'proximity-registrar-cert' SPKI fingerprint exists within the proximity-registrar-cert Subject Public Key Info (SPKI) Fingerprint
exists within the
registrar voucher-request CMS signature's certificate chain. registrar voucher-request CMS signature's certificate chain.
This is substantially the same as the pin validation described in This is substantially the same as the pin validation described in
in <xref target="RFC7469" format="default"/> section 2.6, paragraph three. <xref target="RFC7469" sectionFormat="comma" section="2.6"/>.
</t> </t>
<t> <t>
If these checks succeed the MASA updates If these checks succeed, the MASA updates
the voucher and audit-log assertion leafs with the "proximity" the voucher and audit-log assertion leafs with the "proximity"
assertion, as defined by <xref target="RFC8366" format="default"/> s assertion, as defined by <xref target="RFC8366"
ection 5.3. sectionFormat="comma" section="5.3"/>.
</t> </t>
</section> </section>
<section anchor="MASAnoncehandling" numbered="true" toc="default"> <section anchor="MASAnoncehandling" numbered="true" toc="default">
<name>MASA nonce handling</name> <name>MASA Nonce Handling</name>
<t> <t>
The MASA does not verify the nonce itself. The MASA does not verify the nonce itself.
If the registrar voucher-request contains a nonce, and the If the registrar voucher-request contains a nonce, and the
prior-signed-voucher-request exists, then the MASA MUST prior-signed-voucher-request exists, then the MASA <bcp14>MUST</bcp1 4>
verify that the nonce is consistent. verify that the nonce is consistent.
(Recall from above that the (Recall from above that the
voucher-request might not contain a nonce, see voucher-request might not contain a nonce; see
<xref target="RequestVoucherFromMASA" format="default"/> and Sections <xref target="RequestVoucherFromMASA" format="counter"/> an
<xref target="MASAauthenticationOfRegistrar" format="default"/>). d
<xref target="MASAauthenticationOfRegistrar" format="counter"/>.)
</t> </t>
<t> <t>
The MASA populates the audit-log with the nonce that was The MASA populates the audit-log with the nonce that was
verified. If a nonceless voucher is issued, then the verified. If a nonceless voucher is issued, then the
audit-log is to be populated with the JSON value "null". audit-log is to be populated with the JSON value "null".
</t> </t>
</section> </section>
</section> </section>
<section anchor="VoucherResponse" numbered="true" toc="default"> <section anchor="VoucherResponse" numbered="true" toc="default">
<name>MASA and Registrar Voucher Response</name> <name>MASA and Registrar Voucher Response</name>
<t>The MASA voucher response to the registrar is forwarded <t>The MASA voucher response to the registrar is forwarded
without changes to the pledge; therefore this section applies without changes to the pledge; therefore, this section applies
to both the MASA and the registrar. The HTTP signaling described to both the MASA and the registrar. The HTTP signaling described
applies to both the MASA and registrar responses. applies to both the MASA and registrar responses.
</t> </t>
<t> <t>
When a voucher request arrives at the registrar, if it has a cached When a voucher-request arrives at the registrar, if it has a cached
response from the MASA for the corresponding registrar response from the MASA for the corresponding registrar
voucher-request, that cached response can be used according to voucher-request, that cached response can be used according to
local policy; otherwise the registrar constructs a new registrar local policy; otherwise, the registrar constructs a new registrar
voucher-request and sends it to the MASA. voucher-request and sends it to the MASA.
</t> </t>
<t> <t>
Registrar evaluation of the voucher itself is purely for Registrar evaluation of the voucher itself is purely for
transparency and audit purposes to further inform log verification transparency and audit purposes to further inform log verification
(see <xref target="auditLogVerification" format="default"/>) and there fore a (see <xref target="auditLogVerification" format="default"/>); therefor e, a
registrar could accept future voucher formats that are opaque to registrar could accept future voucher formats that are opaque to
the registrar. the registrar.
</t> </t>
<t> <t>
If the voucher-request is successful, the server (MASA responding If the voucher-request is successful, the server (a MASA responding
to registrar or registrar responding to pledge) response MUST to a registrar or a registrar responding to a pledge) response <bcp14>
contain an HTTP 200 response code. The server MUST answer with a MUST</bcp14>
contain an HTTP 200 response code. The server <bcp14>MUST</bcp14> answ
er with a
suitable 4xx or 5xx HTTP <xref target="RFC7230" format="default"/> err or code when a problem occurs. suitable 4xx or 5xx HTTP <xref target="RFC7230" format="default"/> err or code when a problem occurs.
In this case, the response data from the MASA MUST be a plaintext In this case, the response data from the MASA <bcp14>MUST</bcp14> be a plain text
human-readable (UTF-8) error message containing explanatory human-readable (UTF-8) error message containing explanatory
information describing why the request was rejected. information describing why the request was rejected.
</t> </t>
<t> <t>
The registrar MAY respond with an HTTP 202 ("the request has been The registrar <bcp14>MAY</bcp14> respond with an HTTP 202 ("the reques t has been
accepted for processing, but the processing has not been completed") a s accepted for processing, but the processing has not been completed") a s
described in EST <xref target="RFC7030" format="default"/> section 4.2 described in EST <xref target="RFC7030" sectionFormat="comma" section=
.3 wherein the "4.2.3"/>, wherein the
client "MUST wait at least the specified 'Retry-After' time before client "<bcp14>MUST</bcp14> wait at least the specified "retry-after"
repeating the same request". time before
(see <xref target="RFC7231" format="default"/> section 6.6.4) repeating the same request"
The pledge is RECOMMENDED to provide local (also see <xref target="RFC7231" sectionFormat="comma" section="6.6.4"
feedback (blinked LED etc) during this wait cycle if mechanisms for th />).
is The pledge is <bcp14>RECOMMENDED</bcp14> to provide local
feedback (blinked LED, etc.) during this wait cycle if mechanisms for
this
are available. To prevent an attacker registrar from significantly are available. To prevent an attacker registrar from significantly
delaying bootstrapping the pledge MUST limit the 'Retry-After' time to delaying bootstrapping, the pledge <bcp14>MUST</bcp14> limit the Retry
60 seconds. Ideally the pledge would keep track of the -After time to
60 seconds. Ideally, the pledge would keep track of the
appropriate Retry-After header field values for any number of appropriate Retry-After header field values for any number of
outstanding registrars but this would involve a state table outstanding registrars, but this would involve a state table
on the pledge. Instead the on the pledge. Instead, the
pledge MAY ignore the exact Retry-After value in favor of a single har pledge <bcp14>MAY</bcp14> ignore the exact Retry-After value in favor
d of a single hard-coded
coded value (a registrar that is unable value (a registrar that is unable
to complete the transaction after the first 60 seconds has another cha to complete the transaction after the first 60 seconds has another cha
nce a minute later). A pledge SHOULD only maintain a 202 retry-state nce a minute later). A pledge <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 for up to 4 days, which is longer than a long weekend, after which
time the enrollment attempt fails and the pledge returns to discovery time the enrollment attempt fails, and the pledge returns to Discovery
state. state. This allows time for an alert to get from the registrar to a human opera
tor who can make a
decision as to whether or not to proceed with the enrollment.
</t> </t>
<t> <t>
A pledge that retries a request after receiving a 202 message MUST A pledge that retries a request after receiving a 202 message <bcp14>M
resend the same voucher-request. It MUST NOT sign a new UST</bcp14>
voucher-request each time, and in particular, it MUST NOT change resend the same voucher-request. It <bcp14>MUST NOT</bcp14> sign a ne
w
voucher-request each time, and in particular, it <bcp14>MUST NOT</bcp1
4> change
the nonce value. the nonce value.
</t> </t>
<t> <t>
In order to avoid infinite redirect loops, which a malicious In order to avoid infinite redirect loops, which a malicious
registrar might do in order to keep the pledge from registrar might do in order to keep the pledge from
discovering the correct registrar, the pledge MUST NOT discovering the correct registrar, the pledge <bcp14>MUST NOT</bcp14>
follow more than one redirection (3xx code) to another web follow more than one redirection (3xx code) to another web
origin. EST supports redirection but requires user origin. EST supports redirection but requires user
input; this change allows the pledge to follow a single input; this change allows the pledge to follow a single
redirection without a user interaction. redirection without a user interaction.
</t> </t>
<t>A 403 (Forbidden) response is appropriate if the voucher-request <t>A 403 (Forbidden) response is appropriate if the voucher-request
is not signed correctly, stale, or if the pledge has another is not signed correctly or is stale or if the pledge has another
outstanding voucher that cannot be overridden.</t> outstanding voucher that cannot be overridden.</t>
<t>A 404 (Not Found) response is appropriate when the request is for a <t>A 404 (Not Found) response is appropriate when the request is for a
device that is not known to the MASA.</t> device that is not known to the MASA.</t>
<t>A 406 (Not Acceptable) response is appropriate if a voucher of the <t>A 406 (Not Acceptable) response is appropriate if a voucher of the
desired type or using the desired algorithms (as indicated by the desired type or that uses the desired algorithms (as indicated by the
Accept: header fields, and algorithms used in the signature) cannot be "Accept" header fields and algorithms used in the signature) cannot be
issued such as because the MASA knows the pledge cannot process issued as such because the MASA knows the pledge cannot process
that type. The registrar SHOULD use this response if it determines that type. The registrar <bcp14>SHOULD</bcp14> use this response if it d
etermines
the pledge is unacceptable due to inventory control, MASA audit-logs, or the pledge is unacceptable due to inventory control, MASA audit-logs, or
any other reason.</t> any other reason.</t>
<t> <t>
A 415 (Unsupported Media Type) response is appropriate A 415 (Unsupported Media Type) response is appropriate
for a request that has a voucher-request or Accept: value that is for a request that has a voucher-request or "Accept" value that is
not understood. not understood.
</t> </t>
<t>The voucher response format is as indicated in the submitted <t>The voucher response format is as indicated in the submitted
Accept header fields or based on the MASA's prior understanding of prope "Accept" header fields or based on the MASA's prior understanding of pro
r per
format for this Pledge. Only the <xref target="RFC8366" format="default" format for this pledge. Only the
/> "application/voucher-cms+json" media type <xref target="RFC8366" format=
"application/voucher-cms+json" media type is defined at this "default"/> is defined at this
time. The syntactic details of vouchers are described in detail in time. The syntactic details of vouchers are described in detail in
<xref target="RFC8366" format="default"/>. <xref target="voucherjsonexam ple" format="default"/> shows <xref target="RFC8366" format="default"/>. <xref target="voucherjsonexam ple" format="default"/> shows
a sample of the contents of a voucher. a sample of the contents of a voucher.
</t> </t>
<figure anchor="voucherjsonexample"> <figure anchor="voucherjsonexample">
<name>An example voucher</name> <name>An Example Voucher</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{ {
"ietf-voucher:voucher": { "ietf-voucher:voucher": {
"nonce": "62a2e7693d82fcda2624de58fb6722e5", "nonce": "62a2e7693d82fcda2624de58fb6722e5",
"assertion": "logged", "assertion": "logged",
"pinned-domain-cert": "base64encodedvalue==", "pinned-domain-cert": "base64encodedvalue==",
"serial-number": "JADA123456789" "serial-number": "JADA123456789"
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<t>The MASA populates the voucher fields as follows:</t> <t>The MASA populates the voucher fields as follows:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>nonce:</dt> <dt>nonce:</dt>
<dd>The nonce from the pledge if available. See <xref target="MASAnonc ehandling" format="default"/>.</dd> <dd>The nonce from the pledge if available. See <xref target="MASAnonc ehandling" format="default"/>.</dd>
<dt>assertion:</dt> <dt>assertion:</dt>
<dd>The method used to verify the relationship <dd>The method used to verify the relationship
between pledge and registrar. See <xref target="MASAassertion" format="d efault"/>.</dd> between the pledge and registrar. See <xref target="MASAassertion" forma t="default"/>.</dd>
<dt>pinned-domain-cert:</dt> <dt>pinned-domain-cert:</dt>
<dd>A certificate. See <xref target="MASApinned" format="default"/>. T <dd>A certificate; see <xref target="MASApinned" format="default"/>. T
his figure is illustrative, for an example, his figure is illustrative; for an example,
see <xref target="exampleprocess" format="default"/> where an End Entity see <xref target="exampleprocess" format="default"/> where an end-entity
certificate certificate
is used. </dd> is used. </dd>
<dt>serial-number:</dt> <dt>serial-number:</dt>
<dd>The serial-number as provided in the <dd>The serial-number as provided in the
voucher-request. Also see <xref target="MASAassertion" format="default "/>.</dd> voucher-request. Also see <xref target="MASAassertion" format="default "/>.</dd>
<dt>domain-cert-revocation-checks:</dt> <dt>domain-cert-revocation-checks:</dt>
<dd>Set as appropriate for the <dd>Set as appropriate for the
pledge's capabilities and as documented in <xref target="RFC8366" form at="default"/>. pledge's capabilities and as documented in <xref target="RFC8366" form at="default"/>.
The MASA MAY set this field to 'false' since setting it to 'true' woul
d The MASA <bcp14>MAY</bcp14> set this field to "false" since setting it
require that revocation information be available to the pledge and thi to "true" would
s require that revocation information be available to the pledge, and th
is
document does not make normative requirements for document does not make normative requirements for
<xref target="RFC6961" format="default"/> or equivalent integrations.< /dd> <xref target="RFC6961" format="default"/>, <xref target="RFC8446" sect ionFormat="of" section="4.4.2.1"/>, or equivalent integrations.</dd>
<dt>expires-on:</dt> <dt>expires-on:</dt>
<dd>This is set for nonceless vouchers. The MASA <dd>This is set for nonceless vouchers. The MASA
ensures the voucher lifetime is consistent with any revocation or ensures the voucher lifetime is consistent with any revocation or
pinned-domain-cert consistency checks the pledge might perform. pinned-domain-cert consistency checks the pledge might perform.
See section <xref target="timeunknown" format="default"/>. There are t hree times to consider: See <xref target="timeunknown" format="default"/>. There are three tim es to consider:
(a) a configured voucher lifetime in the MASA, (b) the expiry time for the (a) a configured voucher lifetime in the MASA, (b) the expiry time for the
registrar's certificate, (c) any certificate revocation registrar's certificate, and (c) any CRL lifetime. The expires-on fiel
information (CRL) lifetime. The expires-on field SHOULD be before d <bcp14>SHOULD</bcp14> be before
the earliest of these three values. the earliest of these three values.
Typically (b) will be some significant time in the future, Typically, (b) will be some significant time in the future,
but (c) will typically be short (on the order of a week or but (c) will typically be short (on the order of a week or
less). The RECOMMENDED period for (a) is on the order of less). The <bcp14>RECOMMENDED</bcp14> period for (a) is on the order
20 minutes, so it will typically determine the lifespan of
20 minutes, so it will typically determine the life span
of the resulting voucher. of the resulting voucher.
20 minutes is sufficient time to reach the post-provisional state 20 minutes is sufficient time to reach the post-provisional state
in the pledge, at which point there is an established trust in the pledge, at which point there is an established trust
relationship between pledge and registrar. The subsequent relationship between the pledge and registrar. The subsequent
operations can take as long as required from that point onwards. operations can take as long as required from that point onwards.
The lifetime of the voucher has no impact on the lifespan of the The lifetime of the voucher has no impact on the life span of the
ownership relationship. ownership relationship.
</dd> </dd>
</dl> </dl>
<t> <t>
Whenever a voucher is issued the MASA MUST update the Whenever a voucher is issued, the MASA <bcp14>MUST</bcp14> update the
audit-log sufficiently to generate the response as described in audit-log sufficiently to generate the response as described in
<xref target="MASAauditlog" format="default"/>. <xref target="MASAauditlog" format="default"/>.
The internal state requirements to maintain the audit-log The internal state requirements to maintain the audit-log
are out-of-scope. are out of scope.
</t> </t>
<section anchor="CompletingAuthenticationBootstrapping" numbered="true" toc="default"> <section anchor="CompletingAuthenticationBootstrapping" numbered="true" toc="default">
<name>Pledge voucher verification</name> <name>Pledge Voucher Verification</name>
<t> <t>
The pledge MUST verify the voucher signature using the The pledge <bcp14>MUST</bcp14> verify the voucher signature using the
manufacturer-installed manufacturer-installed
trust anchor(s) associated with the manufacturer's MASA (this is trust anchor(s) associated with the manufacturer's MASA (this is
likely included in the pledge's firmware). Management of the likely included in the pledge's firmware). Management of the
manufacturer-installed manufacturer-installed
trust anchor(s) is out-of-scope of this document; this protocol trust anchor(s) is out of scope of this document; this protocol
does not update these trust anchor(s). does not update this trust anchor(s).
</t> </t>
<t> <t>
The pledge MUST verify the serial-number field of the signed voucher The pledge <bcp14>MUST</bcp14> verify that the serial-number field of the signed voucher
matches the pledge's own serial-number. matches the pledge's own serial-number.
</t> </t>
<t> <t>
The pledge MUST The pledge <bcp14>MUST</bcp14>
verify the nonce information in the voucher. If present, the nonce in verify the nonce information in the voucher. If present, the nonce in
the voucher must match the nonce the pledge submitted to the the voucher must match the nonce the pledge submitted to the
registrar; vouchers with no nonce can also be accepted (according registrar; vouchers with no nonce can also be accepted (according
to local policy, see <xref target="pledgeReductions" format="default"/ >) to local policy; see <xref target="pledgeReductions" format="default"/ >).
</t> </t>
<t> <t>
The pledge MUST be prepared to parse and fail gracefully from The pledge <bcp14>MUST</bcp14> be prepared to parse and fail gracefull
a voucher response that does not contain a 'pinned-domain-cert' y from
a voucher response that does not contain a pinned-domain-cert
field. field.
Such a thing indicates a failure to enroll in this domain, Such a thing indicates a failure to enroll in this domain,
and the pledge MUST attempt joining with other available Join Proxy. and the pledge <bcp14>MUST</bcp14> attempt joining with other availabl e Join Proxies.
</t> </t>
<t> <t>
The pledge MUST be prepared to ignore additional fields that it does n ot recognize. The pledge <bcp14>MUST</bcp14> be prepared to ignore additional fields that it does not recognize.
</t> </t>
</section> </section>
<section anchor="PledgeAuthenticationOfProvisionalTLS" numbered="true" t oc="default"> <section anchor="PledgeAuthenticationOfProvisionalTLS" numbered="true" t oc="default">
<name>Pledge authentication of provisional TLS connection</name> <name>Pledge Authentication of Provisional TLS Connection</name>
<t> <t>
Following the process described in <xref target="RFC8366" format="de fault"/>, Following the process described in <xref target="RFC8366" format="de fault"/>,
the pledge should consider the public key from the the pledge should consider the public key from the
pinned-domain-cert as the sole temporary trust anchor. pinned-domain-cert as the sole temporary trust anchor.
</t> </t>
<t> <t>
The pledge then evaluates the TLS Server Certificate chain that it The pledge then evaluates the TLS server certificate chain that it
received when the TLS connection was formed using this trust received when the TLS connection was formed using this trust
anchor. anchor.
It is possible that the pinned-domain-cert matches the End-Entity It is possible that the public key in the pinned-domain-cert directl
Certificate provided in the TLS Server. y matches
the public key in the end-entity
certificate provided by the TLS server.
</t> </t>
<t> <t>
If a registrar's credentials cannot be verified using the If a registrar's credentials cannot be verified using the
pinned-domain-cert trust anchor from the voucher then the TLS pinned-domain-cert trust anchor from the voucher, then the TLS
connection is immediately connection is
discarded and the pledge abandons attempts to bootstrap with this discarded, and the pledge abandons attempts to bootstrap with this
discovered registrar. The pledge SHOULD send voucher status discovered registrar. The pledge <bcp14>SHOULD</bcp14> send voucher
status
telemetry (described below) before closing the TLS connection. telemetry (described below) before closing the TLS connection.
The pledge MUST attempt to enroll using any other proxies The pledge <bcp14>MUST</bcp14> attempt to enroll using any other pro
it has found. It SHOULD return to the same proxy again after xies
it has found. It <bcp14>SHOULD</bcp14> return to the same proxy aga
in after
unsuccessful attempts with other proxies. Attempts should be unsuccessful attempts with other proxies. Attempts should be
made repeated at intervals according to the backoff timer made at repeated intervals according to the back-off timer
described earlier. described earlier.
Attempts SHOULD be repeated as failure may be the result of a Attempts <bcp14>SHOULD</bcp14> be repeated as failure may be the res ult of a
temporary inconsistency (an inconsistently rolled registrar key, temporary inconsistency (an inconsistently rolled registrar key,
or some other mis-configuration). The inconsistency could also or some other misconfiguration). The inconsistency could also
be the result an active MITM attack on the EST connection. be the result of an active MITM attack on the EST connection.
</t> </t>
<t> The registrar MUST use a certificate that chains to the pinned-dom ain-cert <t> The registrar <bcp14>MUST</bcp14> use a certificate that chains to the pinned-domain-cert
as its TLS server certificate. as its TLS server certificate.
</t> </t>
<t>The pledge's PKIX path validation of a registrar certificate's vali dity <t>The pledge's PKIX path validation of a registrar certificate's vali dity
period information is as described in <xref target="timeunknown" for mat="default"/>. period information is as described in <xref target="timeunknown" for mat="default"/>.
Once the PKIX path validation is successful the TLS connection is Once the PKIX path validation is successful, the TLS connection is
no longer provisional.</t> no longer provisional.</t>
<t>The pinned-domain-cert MAY be installed as a <t>The pinned-domain-cert <bcp14>MAY</bcp14> be installed as a
trust anchor for future operations such as enrollment (e.g. <xref ta trust anchor for future operations such as enrollment (e.g., as reco
rget="RFC7030" format="default"/> as recommended) or trust anchor management or mmended per <xref target="RFC7030" format="default"/>) or trust anchor managemen
raw protocols that do not need full PKI based key management. It can be used to t or raw protocols that do not need full PKI-based key management. It can be use
authenticate any dynamically d to authenticate any dynamically
discovered EST server that contain the id-kp-cmcRA extended key discovered EST server that contains the id-kp-cmcRA extended key
usage extension as detailed in EST RFC7030 section 3.6.1; but to usage extension as detailed in EST (see <xref target="RFC7030" secti
reduce system complexity the pledge SHOULD avoid additional onFormat="comma" section="3.6.1"/>); but to
discovery operations. Instead the pledge SHOULD communicate directly reduce system complexity, the pledge <bcp14>SHOULD</bcp14> avoid add
with the registrar as the EST server. The 'pinned-domain-cert' itional
discovery operations. Instead, the pledge <bcp14>SHOULD</bcp14> comm
unicate directly
with the registrar as the EST server. The pinned-domain-cert
is not a complete is not a complete
distribution of the <xref target="RFC7030" format="default"/> sectio distribution of the CA certificate response, as described in <xref t
n 4.1.3 CA Certificate Response, arget="RFC7030" sectionFormat="comma"
section="4.1.3"/>,
which is which is
an additional justification for the recommendation to proceed with E ST an additional justification for the recommendation to proceed with E ST
key management operations. Once a full CA Certificate Response is key management operations. Once a full CA certificate response is
obtained it is more authoritative for the domain than the limited obtained, it is more authoritative for the domain than the limited
'pinned-domain-cert' response.</t> pinned-domain-cert response.</t>
</section> </section>
</section> </section>
<section anchor="pledgestatus" numbered="true" toc="default"> <section anchor="pledgestatus" numbered="true" toc="default">
<name>Pledge BRSKI Status Telemetry</name> <name>Pledge BRSKI Status Telemetry</name>
<t>The domain is expected to provide indications to the system <t>The domain is expected to provide indications to the system
administrators concerning device lifecycle status. To facilitate this administrators concerning device life-cycle status. To facilitate this,
it needs telemetry information concerning the device's it needs telemetry information concerning the device's
status.</t> status.</t>
<t>The pledge MUST indicate its pledge status regarding the voucher. <t>The pledge <bcp14>MUST</bcp14> indicate its pledge status regarding t
It does this by sending a status message to the Registrar.</t> he voucher.
It does this by sending a status message to the registrar.</t>
<t>The posted data media type: application/json</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/e
st/voucher_status".</t> <t>The client sends an HTTP POST to the server at the URI ".well-known/brski/vou
cher_status".</t>
<t> <t>
The format and semantics described below are for version 1. The format and semantics described below are for version 1.
A version field is included to permit significant changes to this A version field is included to permit significant changes to this
feedback in the future. A Registrar that receives a status feedback in the future. A registrar that receives a status
message with a version larger than it knows about SHOULD log the message with a version larger than it knows about <bcp14>SHOULD</bcp14
> log the
contents and alert a human. contents and alert a human.
</t> </t>
<t>The Status field indicates if the voucher was acceptable. <t>The status field indicates if the voucher was acceptable.
Boolean values are acceptable, where "true" indicates the voucher was Boolean values are acceptable, where "true" indicates the voucher was
acceptable. acceptable.
</t> </t>
<t> <t>
If the voucher was not acceptable the Reason string indicates If the voucher was not acceptable, the Reason string indicates
why. In the failure case this message may be sent to an why. In a failure case, this message may be sent to an
unauthenticated, potentially malicious registrar and therefore the unauthenticated, potentially malicious registrar; therefore, the
Reason string SHOULD NOT provide information beneficial to an Reason string <bcp14>SHOULD NOT</bcp14> provide information beneficial
to an
attacker. The operational benefit of this telemetry information is attacker. The operational benefit of this telemetry information is
balanced against the operational costs of not recording that an balanced against the operational costs of not recording that a
voucher was ignored by a client the registrar expected to continue voucher was ignored by a client that the registrar expected was going
to continue
joining the domain. joining the domain.
</t> </t>
<t> <t>
The reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
value or hash of values) which provides additional information value or hash of values) that provides additional information
specific to this pledge. The contents of this field are not specific to this pledge. The contents of this field are not
subject to standardization. subject to standardization.
</t> </t>
<t> <t>
The version and status fields MUST be present. The version and status fields <bcp14>MUST</bcp14> be present.
The Reason field SHOULD be present whenever the status field The Reason field <bcp14>SHOULD</bcp14> be present whenever the status
field
is false. The Reason-Context field is optional. is false. The Reason-Context field is optional.
In the case of a SUCCESS, the Reason string <bcp14>MAY</bcp14> be omitt ed.
</t> </t>
<t> <t>
The keys to this JSON object are case-sensitive and MUST be lowercase. The keys to this JSON object are case sensitive and <bcp14>MUST</bcp14
> be lowercase.
<xref target="telemetryexample" format="default"/> shows an example JS ON. <xref target="telemetryexample" format="default"/> shows an example JS ON.
</t> </t>
<figure anchor="telemetryexample"> <figure anchor="cddl-voucherstatus">
<name>CDDL for Voucher Status POST</name>
<sourcecode name="voucherstatus.cddl" type="CDDL" markers="true"><![CD
ATA[
voucherstatus-post = {
"version": uint,
"status": bool,
? "reason": text,
? "reason-context" : { $$arbitrary-map }
}
}
]]></sourcecode>
</figure>
<figure anchor="telemetryexample">
<name>Example Status Telemetry</name> <name>Example Status Telemetry</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"version":"1", "version": 1,
"status":false, "status":false,
"reason":"Informative human readable message", "reason":"Informative human-readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
The server SHOULD respond with an HTTP 200 but MAY simply The server <bcp14>SHOULD</bcp14> respond with an HTTP 200 but <bcp14>M
fail with an HTTP 404 error. The client ignores any response. Within AY</bcp14> simply
the server logs the server SHOULD capture this telemetry fail with an HTTP 404 error. The client ignores any response. The serv
information. er <bcp14>SHOULD</bcp14> capture this telemetry information within the server lo
gs.
</t> </t>
<t> <t>
Additional standard JSON fields in this POST MAY be added, see Additional standard JSON fields in this POST <bcp14>MAY</bcp14> be add ed; see
<xref target="pledgestatustelemetryregistry" format="default"/>. A se rver that <xref target="pledgestatustelemetryregistry" format="default"/>. A se rver that
sees unknown fields should log them, but otherwise ignore them. sees unknown fields should log them, but otherwise ignore them.
</t> </t>
</section> </section>
<section anchor="authzLogRequest" numbered="true" toc="default"> <section anchor="authzLogRequest" numbered="true" toc="default">
<name>Registrar audit-log request</name> <name>Registrar Audit-Log Request</name>
<t> <t>
After receiving the pledge status telemetry <xref target="pledgestatu After receiving the pledge status telemetry (see <xref target="pledge
s" format="default"/>, status" format="default"/>),
the registrar SHOULD request the MASA audit-log from the MASA the registrar <bcp14>SHOULD</bcp14> request the MASA audit-log from t
service.</t> he MASA
service.</t>
<t> <t>
This is done with an HTTP POST using the operation path value of This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestauditlog". "/.well-known/brski/requestauditlog".
</t> </t>
<t> <t>
The registrar SHOULD HTTP POST the same registrar voucher-request The registrar <bcp14>SHOULD</bcp14> HTTP POST the same registrar vouch er-request
as it did when requesting a as it did when requesting a
voucher (using the same Content-Type). It is posted to the /requestaud itlog URI instead. voucher (using the same Content-Type). It is posted to the /requestaud itlog URI instead.
The "idevid-issuer" and "serial-number" informs the MASA The idevid-issuer and serial-number informs the MASA
which log is requested so the appropriate log can be prepared which log is requested, so the appropriate log can be prepared
for the response. for the response.
Using the same media type and message minimizes Using the same media type and message minimizes
cryptographic and message operations although it results in additional cryptographic and message operations, although it results in additiona l
network traffic. network traffic.
The relying MASA implementation MAY leverage internal state The relying MASA implementation <bcp14>MAY</bcp14> leverage internal s tate
to associate this request with the original, and by now already to associate this request with the original, and by now already
validated, voucher-request so as to avoid an extra crypto validated, voucher-request so as to avoid an extra crypto
validation. validation.
</t> </t>
<t> <t>
A registrar MAY request logs at future times. If the registrar A registrar <bcp14>MAY</bcp14> request logs at future times. If the re
generates a new request then the MASA is forced to perform gistrar
generates a new request, then the MASA is forced to perform
the additional cryptographic operations to verify the new request. the additional cryptographic operations to verify the new request.
</t> </t>
<t> <t>
A MASA that receives a request for a device that does not exist, A MASA that receives a request for a device that does not exist,
or for which the requesting owner was never an owner returns an or for which the requesting owner was never an owner, returns an
HTTP 404 ("Not found") code. HTTP 404 ("Not found") code.
</t> </t>
<t> <t>
It is reasonable for a Registrar, that the MASA does not believe It is reasonable for a registrar, that the MASA does not believe
to be the current owner, to request the audit-log. There are to be the current owner, to request the audit-log. There are
probably reasons for this which are hard to predict in advance. probably reasons for this, which are hard to predict in advance.
For instance, such a registrar may not be aware that the device has For instance, such a registrar may not be aware that the device has
been resold; it may be that the device has been resold been resold; it may be that the device has been resold
inappropriately, and this is how the original owner will learn of inappropriately, and this is how the original owner will learn of
the occurance. It is also possible that the device legitimately the occurrence. It is also possible that the device legitimately
spends time in two different networks. spends time in two different networks.
</t> </t>
<t> <t>
Rather than returning the audit-log as a response to the POST (with Rather than returning the audit-log as a response to the POST (with
a return code 200), the MASA MAY instead return a 201 ("Created") a return code 200), the MASA <bcp14>MAY</bcp14> instead return a 201 (
response (<xref target="RFC7231" format="default"/> sections 6.3.2 and "Created")
7.1), with response (<xref target="RFC7231" sectionFormat="bare"/>, Sections
<xref target="RFC7231" sectionFormat="bare" section="6.3.2"/> and <xref
target="RFC7231" sectionFormat="bare" section="7.1"/>), with
the URL to the prepared (and idempotent, therefore cachable) audit the URL to the prepared (and idempotent, therefore cachable) audit
response in the Location: header field. response in the "Location" header field.
</t> </t>
<t> <t>
In order to avoid enumeration of device audit-logs, In order to avoid enumeration of device audit-logs,
MASA that return URLs SHOULD take care to make the returned a MASA that returns URLs <bcp14>SHOULD</bcp14> take care to make the r eturned
URL unguessable. URL unguessable.
<xref target="W3C.WD-capability-urls-20140218" format="default"/> prov ides very good additional guidance. <xref target="W3C.capability-urls" format="default"/> provides very go od additional guidance.
For instance, rather than returning URLs containing a database number For instance, rather than returning URLs containing a database number
such as https://example.com/auditlog/1234 or the EUI of the device such as https://example.com/auditlog/1234 or the Extended Unique Ident ifier (EUI) of the device
such https://example.com/auditlog/10-00-00-11-22-33, such https://example.com/auditlog/10-00-00-11-22-33,
the MASA SHOULD return a randomly generated value (a "slug" in the MASA <bcp14>SHOULD</bcp14> return a randomly generated value (a "s lug" in
web parlance). The value is used to find the relevant database web parlance). The value is used to find the relevant database
entry. entry.
</t> </t>
<t> <t>
A MASA that returns a code 200 MAY also include a Location: header A MASA that returns a code 200 <bcp14>MAY</bcp14> also include a "Loca tion" header
for future reference by the registrar. for future reference by the registrar.
</t> </t>
<section anchor="MASAauditlog" numbered="true" toc="default"> <section anchor="MASAauditlog" numbered="true" toc="default">
<name>MASA audit log response</name> <name>MASA Audit-Log Response</name>
<t>A log data file is returned consisting of all log entries <t>A log data file is returned consisting of all log entries
associated with the device selected by the IDevID presented in associated with the device selected by the IDevID presented in
the request. The audit log may be abridged by removal of old or repea ted the request. The audit-log may be abridged by removal of old or repea ted
values as explained below. values as explained below.
The returned data is in JSON format (<xref target="RFC8259" format="de The returned data is in JSON format <xref target="RFC8259" format="def
fault"/>), ault"/>,
and the Content-Type SHOULD be "application/json". and the Content-Type <bcp14>SHOULD</bcp14> be "application/json".
</t> </t>
<t> <t>
The following CDDL (<xref target="RFC8610" format="default"/>) expla ins the The following CDDL <xref target="RFC8610" format="default"/> explain s the
structure of the JSON format audit-log response: structure of the JSON format audit-log response:
</t> </t>
<figure anchor="cddl-auditlog"> <figure anchor="cddl-auditlog">
<name>CDDL for audit-log response</name> <name>CDDL for Audit-Log Response</name>
<sourcecode name="auditlog.cddl" type="" markers="true"><![CDATA[ <sourcecode name="auditlog.cddl" type="CDDL" markers="true"><![CDATA
[
audit-log-response = { audit-log-response = {
"version": uint, "version": uint,
"events": [ + event ] "events": [ + event ]
"truncation": { "truncation": {
? "nonced duplicates": uint, ? "nonced duplicates": uint,
? "nonceless duplicates": uint, ? "nonceless duplicates": uint,
? "arbitrary": uint, ? "arbitrary": uint,
} }
} }
skipping to change at line 2863 skipping to change at line 2956
"domainID": text, "domainID": text,
"nonce": text / null, "nonce": text / null,
"assertion": "verified" / "logged" / "proximity", "assertion": "verified" / "logged" / "proximity",
? "truncated": uint, ? "truncated": uint,
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>An example: <t>An example:
</t> </t>
<figure anchor="example-auditlog"> <figure anchor="example-auditlog">
<name>Example of audit-log response</name> <name>Example of an Audit-Log Response</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{ {
"version":"1", "version":"1",
"events":[ "events":[
{ {
"date":"2019-05-15T17:25:55.644-04:00", "date":"2019-05-15T17:25:55.644-04:00",
"domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=",
"nonce":"VOUFT-WwrEv0NuAQEHoV7Q", "nonce":"VOUFT-WwrEv0NuAQEHoV7Q",
"assertion":"proximity", "assertion":"proximity",
"truncated":"0" "truncated":"0"
}, },
skipping to change at line 2888 skipping to change at line 2981
"nonce":"f4G6Vi1t8nKo/FieCVgpBg==", "nonce":"f4G6Vi1t8nKo/FieCVgpBg==",
"assertion":"proximity" "assertion":"proximity"
} }
], ],
"truncation": { "truncation": {
"nonced duplicates": "0", "nonced duplicates": "0",
"nonceless duplicates": "1", "nonceless duplicates": "1",
"arbitrary": "2" "arbitrary": "2"
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<t> <t>
The domainID is a binary SubjectKeyIdentifier value calculated The domainID is a binary SubjectKeyIdentifier value calculated
according to <xref target="domainID" format="default"/>. according to <xref target="domainID" format="default"/>.
It is encoded once in base64 in order to be transported in this It is encoded once in base64 in order to be transported in this
JSON container. JSON container.
</t> </t>
<t> <t>
The date is in <xref target="RFC3339" format="default"/> format, whi ch is The date is formatted per <xref target="RFC3339" format="default"/>, which is
consistent with typical JavaScript usage of JSON. consistent with typical JavaScript usage of JSON.
</t> </t>
<t> <t>
The truncation structure MAY be omitted if all values are zero. The truncation structure <bcp14>MAY</bcp14> be omitted if all values
Any counter missing from the truncation structure is the be are zero.
Any counter missing from the truncation structure is
assumed to be zero. assumed to be zero.
</t> </t>
<t> <t>
The nonce is a string, as provided in the voucher-request, and The nonce is a string, as provided in the voucher-request, and
used in the voucher. If no nonce was placed in the resulting is used in the voucher. If no nonce was placed in the resulting
voucher, then a value of null SHOULD be used in preference to voucher, then a value of null <bcp14>SHOULD</bcp14> be used in prefe
rence to
omitting the entry. omitting the entry.
While the nonce is often created as a base64 encoded random While the nonce is often created as a base64-encoded random
series of bytes, this should not be assumed. series of bytes, this should not be assumed.
</t> </t>
<t> <t>
Distribution of a large log is less than ideal. This structure can Distribution of a large log is less than ideal. This structure can
be optimized as follows: Nonced or Nonceless entries for the be optimized as follows: nonced or nonceless entries for the
same domainID MAY be abridged from the log leaving only the single same domainID <bcp14>MAY</bcp14> be abridged from the log leaving on
ly the single
most recent nonced or nonceless entry for that domainID. In the case of most recent nonced or nonceless entry for that domainID. In the case of
truncation the 'event' truncation value SHOULD contain a count of th truncation, the "event" truncation value <bcp14>SHOULD</bcp14> conta
e number of events for this in a count of the number of events for this
domainID that were omitted. The log SHOULD NOT be further domainID that were omitted. The log <bcp14>SHOULD NOT</bcp14> be fur
reduced but there could exist operational situation where maintainin ther
g reduced, but an operational situation could exist where maintaining
the full log is not possible. In such situations the log MAY be the full log is not possible. In such situations, the log <bcp14>MAY
</bcp14> be
arbitrarily abridged for length, with the number of removed arbitrarily abridged for length, with the number of removed
entries indicated as 'arbitrary'. entries indicated as "arbitrary".
</t> </t>
<t> <t>
If the truncation count exceeds 1024 then the MASA If the truncation count exceeds 1024, then the MASA
MAY use this value without further incrementing it. <bcp14>MAY</bcp14> use this value without further incrementing it.
</t> </t>
<t> <t>
A log where duplicate entries for the same domain have A log where duplicate entries for the same domain have
been omitted ("nonced duplicates" and/or "nonceless duplicates) been omitted ("nonced duplicates" and/or "nonceless duplicates")
could still be acceptable for informed decisions. A log that could still be acceptable for informed decisions. A log that
has had "arbitrary" truncations is less acceptable but manufacturer has had "arbitrary" truncations is less acceptable, but manufacturer
transparency is better than hidden truncations. transparency is better than hidden truncations.
</t> </t>
<t> <t>
A registrar that sees a version value greater than 1 indicates A registrar that sees a version value greater than 1 indicates
an audit log format that has been enhanced with additional an audit-log format that has been enhanced with additional
information. No information will be removed in future information. No information will be removed in future
versions; should an incompatible change be desired in the future, versions; should an incompatible change be desired in the future,
then a new HTTP end point will be used. then a new HTTP endpoint will be used.
</t> </t>
<t>This document <t>This document
specifies a simple log format as provided by the specifies a simple log format as provided by the
MASA service to the registrar. This format could be improved by MASA service to the registrar. This format could be improved by
distributed consensus technologies that integrate vouchers distributed consensus technologies that integrate vouchers
with technologies such as block-chain or hash trees or optimized with technologies such as block-chain or hash trees or optimized
logging approaches. Doing so is out of the scope of this document logging approaches. Doing so is out of the scope of this document
but is an but is an
anticipated improvement for future work. As such, the anticipated improvement for future work. As such, the
registrar SHOULD anticipate new kinds of responses, and registrar <bcp14>SHOULD</bcp14> anticipate new kinds of responses an
SHOULD provide operator controls to indicate how to process d
<bcp14>SHOULD</bcp14> provide operator controls to indicate how to p
rocess
unknown responses. unknown responses.
</t> </t>
</section> </section>
<section anchor="domainID" numbered="true" toc="default"> <section anchor="domainID" numbered="true" toc="default">
<name>Calculation of domainID</name> <name>Calculation of domainID</name>
<t> <t>
The domainID is a binary value (a BIT STRING) that uniquely The domainID is a binary value (a BIT STRING) that uniquely
identifies a Registrar by the "pinned-domain-cert". identifies a registrar by the pinned-domain-cert.
</t> </t>
<t> <t>
If the "pinned-domain-cert" certificate If the pinned-domain-cert certificate
includes the SubjectKeyIdentifier (<xref target="RFC5280" format="de includes the SubjectKeyIdentifier (<xref target="RFC5280" sectionFor
fault">Section mat="comma" section="4.2.1.2"/>), then it is used as the domainID. If not,
4.2.1.2</xref>), then it is to be used as the domainID. If not,
the SPKI Fingerprint as described in the SPKI Fingerprint as described in
<xref target="RFC7469" format="default"/> section 2.4 is to be used. <xref target="RFC7469" sectionFormat="comma" section="2.4"/> is used
This value needs to be calculated by both MASA (to .
populate the audit-log), and by the Registrar (to recognize This value needs to be calculated by both the MASA (to
itself in the audit log). populate the audit-log) and the registrar (to recognize itself in th
e audit-log).
</t> </t>
<t> <t>
<xref target="RFC5280" format="default"/> section 4.2.1.2 does not m andate that the <xref target="RFC5280" sectionFormat="comma" section="4.2.1.2"/> doe s not mandate that the
SubjectKeyIdentifier extension be present in non-CA certificates. SubjectKeyIdentifier extension be present in non-CA certificates.
It is RECOMMENDED that Registrar certificates (even if It is <bcp14>RECOMMENDED</bcp14> that registrar certificates (even i
self-signed), always include the SubjectKeyIdentifier to be f
self-signed) always include the SubjectKeyIdentifier to be
used as a domainID. used as a domainID.
</t> </t>
<t> <t>
The domainID is determined The domainID is determined
from the certificate chain associated with the from the certificate chain associated with the
pinned-domain-cert and is used to update the audit-log. pinned-domain-cert and is used to update the audit-log.
</t> </t>
</section> </section>
<section anchor="auditLogVerification" numbered="true" toc="default"> <section anchor="auditLogVerification" numbered="true" toc="default">
<name>Registrar audit log verification</name> <name>Registrar Audit-Log Verification</name>
<t> <t>
Each time the Manufacturer Authorized Signing Authority (MASA) Each time the MASA
issues a voucher, it appends details of the assignment to issues a voucher, it appends details of the assignment to
an internal audit log for that device. an internal audit-log for that device.
The internal audit log is processed when responding to The internal audit-log is processed when responding to
requests for details as described in <xref target="authzLogRequest" format="default"/>. requests for details as described in <xref target="authzLogRequest" format="default"/>.
The contents of the audit log can express a variety of trust The contents of the audit-log can express a variety of trust
levels, and this section explains what kind of trust a levels, and this section explains what kind of trust a
registrar can derive from the entries. registrar can derive from the entries.
</t> </t>
<t> <t>
While the audit log provides a list of vouchers that were issued While the audit-log provides a list of vouchers that were issued
by the MASA, the vouchers are issued in response to by the MASA, the vouchers are issued in response to
voucher-requests, and it is the contents of the voucher-requests voucher-requests, and it is the content of the voucher-requests
which determines how meaningful the audit log entries are. that determines how meaningful the audit-log entries are.
</t> </t>
<t>A registrar SHOULD use the log information to make an informed deci sion <t>A registrar <bcp14>SHOULD</bcp14> use the log information to make a n informed decision
regarding the continued bootstrapping of the pledge. The exact policy is regarding the continued bootstrapping of the pledge. The exact policy is
out of scope of this document as it depends on the security requiremen ts out of scope of this document as it depends on the security requiremen ts
within the registrar domain. Equipment that is purchased pre-owned can be within the registrar domain. Equipment that is purchased preowned can be
expected to have an extensive history. The following discussion is pr ovided to help expected to have an extensive history. The following discussion is pr ovided to help
explain the value of each log element:</t> explain the value of each log element:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>date:</dt> <dt>date:</dt>
<dd>The date field provides the registrar an <dd>The date field provides the registrar an
opportunity to divide the log around known events such as opportunity to divide the log around known events such as
the purchase date. Depending on context known to the registrar the purchase date. Depending on the context known to the registrar
or administrator events before/after certain dates can or administrator, events before/after certain dates can
have different levels of importance. For example for equipment have different levels of importance. For example, for equipment
that is expected to be new, and thus have no history, it that is expected to be new, and thus has no history, it
would be a surprise to find prior entries.</dd> would be a surprise to find prior entries.</dd>
<dt>domainID:</dt> <dt>domainID:</dt>
<dd> If the log includes an unexpected domainID <dd> If the log includes an unexpected domainID,
then the pledge could have imprinted on an unexpected domain. The then the pledge could have imprinted on an unexpected domain. The
registrar can be expected to use a variety of techniques to registrar can be expected to use a variety of techniques to
define "unexpected" ranging from white lists of prior define "unexpected" ranging from acceptlists of prior
domains to anomaly detection (e.g. "this device was previously domains to anomaly detection (e.g., "this device was previously
bound to a different domain than any other device deployed"). Log bound to a different domain than any other device deployed"). Log
entries can also be compared against local history logs in search of entries can also be compared against local history logs in search of
discrepancies (e.g. "this device was re-deployed some number of ti discrepancies (e.g., "this device was re-deployed some number of t
mes imes
internally but the external audit log shows additional re-deployme internally, but the external audit-log shows additional re-deploym
nts ents
our internal logs are unaware of").</dd> our internal logs are unaware of").</dd>
<dt>nonce:</dt> <dt>nonce:</dt>
<dd>Nonceless entries mean the logged domainID could <dd>Nonceless entries mean the logged domainID could
theoretically trigger a reset of the pledge and then take over man agement theoretically trigger a reset of the pledge and then take over man agement
by using the existing nonceless voucher.</dd> by using the existing nonceless voucher.</dd>
<dt>assertion:</dt> <dt>assertion:</dt>
<dd>The assertion leaf in the voucher and <dd>The assertion leaf in the voucher and
audit log indicates why the MASA issued the voucher. audit-log indicates why the MASA issued the voucher.
A "verified" entry means that A "verified" entry means that
the MASA issued the associated voucher as a result of positive the MASA issued the associated voucher as a result of positive
verification of ownership. verification of ownership.
However, this entry does not indicate whether the pledge was However, this entry does not indicate whether or not the pledge wa
actually deployed in the prior domain, or not. s
actually deployed in the prior domain.
A "logged" assertion informs A "logged" assertion informs
the registrar that the prior vouchers were issued with the registrar that the prior vouchers were issued with
minimal verification. A "proximity" assertion minimal verification. A "proximity" assertion
assures the registrar that the pledge was truly communicating assures the registrar that the pledge was truly communicating
with the prior domain and thus provides assurance that the with the prior domain and thus provides assurance that the
prior domain really has deployed the pledge.</dd> prior domain really has deployed the pledge.</dd>
</dl> </dl>
<t> <t>
A relatively simple policy is to white list known (internal or A relatively simple policy is to acceptlist known (internal or
external) domainIDs, and require all vouchers to have a nonce. external) domainIDs and require all vouchers to have a nonce.
An alternative is to require that all nonceless vouchers be from a An alternative is to require that all nonceless vouchers be from a
subset (e.g. only internal) of domainIDs. subset (e.g., only internal) of domainIDs.
If the policy is violated a simple action is to revoke any If the policy is violated, a simple action is to revoke any
locally issued credentials for the pledge in question or to locally issued credentials for the pledge in question or to
refuse to forward the voucher. The Registrar MUST then refuse refuse to forward the voucher. The registrar <bcp14>MUST</bcp14> th
any EST actions, and SHOULD inform a human via a log. en refuse
A registrar MAY be configured to ignore (i.e. override the above any EST actions and <bcp14>SHOULD</bcp14> inform a human via a log.
A registrar <bcp14>MAY</bcp14> be configured to ignore (i.e., overri
de the above
policy) the policy) the
history of the device but it is RECOMMENDED that this only be history of the device, but it is <bcp14>RECOMMENDED</bcp14> that thi
configured if hardware assisted (i.e. TPM anchored) Network s only be
configured if hardware-assisted (i.e., Transport Performance Metrics
(TPM) anchored) Network
Endpoint Assessment (NEA) <xref target="RFC5209" format="default"/> is supported. Endpoint Assessment (NEA) <xref target="RFC5209" format="default"/> is supported.
</t> </t>
</section> </section>
</section> </section>
<section anchor="ESTintegration" numbered="true" toc="default"> <section anchor="ESTintegration" numbered="true" toc="default">
<name>EST Integration for PKI bootstrapping</name> <name>EST Integration for PKI Bootstrapping</name>
<t>The pledge SHOULD follow the BRSKI operations with EST enrollment ope
rations <t>The pledge <bcp14>SHOULD</bcp14> follow the BRSKI operations with EST
including "CA Certificates Request", "CSR Attributes" and "Client Certif enrollment operations
icate Request" including "CA Certificates Request", "CSR Attributes Request", and "Clie
nt Certificate Request"
or "Server-Side Key Generation", etc. This is a relatively seamless inte gration or "Server-Side Key Generation", etc. This is a relatively seamless inte gration
since BRSKI API calls provide an automated alternative to the manual boo tstrapping method since BRSKI API calls provide an automated alternative to the manual boo tstrapping method
described in <xref target="RFC7030" format="default"/>. As noted above, use of HTTP persistent described in <xref target="RFC7030" format="default"/>. As noted above, use of HTTP-persistent
connections simplifies the pledge state machine.</t> connections simplifies the pledge state machine.</t>
<!-- dealing with: https://github.com/anima-wg/anima-bootstrap/issues/24 -->
<t> <t>
Although EST allows clients to obtain multiple certificates by sending Although EST allows clients to obtain multiple certificates by sending
multiple Certificate Signing Requests (CSR) requests, BRSKI does not s multiple Certificate Signing Requests (CSRs), BRSKI does not support t
upport this mechanism directly. his mechanism directly.
This is because BRSKI pledges MUST use the CSR Attributes request This is because BRSKI pledges <bcp14>MUST</bcp14> use the CSR Attribut
(<xref target="RFC7030" format="default"/> section 4.5). es request
The registrar MUST validate the CSR against the expected (<xref target="RFC7030" sectionFormat="comma" section="4.5"/>).
The registrar <bcp14>MUST</bcp14> validate the CSR against the expecte
d
attributes. This implies that client requests will "look the same" attributes. This implies that client requests will "look the same"
and therefore result in a single logical certificate being issued and therefore result in a single logical certificate being issued
even if the client were to make multiple requests. Registrars MAY even if the client were to make multiple requests. Registrars <bcp14>M
contain more complex logic but doing so is out-of-scope of this AY</bcp14>
contain more complex logic, but doing so is out of scope of this
specification. specification.
BRSKI does not signal any enhancement or restriction to this BRSKI does not signal any enhancement or restriction to this
capability. capability.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>EST Distribution of CA Certificates</name> <name>EST Distribution of CA Certificates</name>
<t>The pledge SHOULD request the full EST Distribution of CA <t>The pledge <bcp14>SHOULD</bcp14> request the full EST Distribution
Certificates message. See RFC7030, section 4.1.</t> of CA
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 <t>This ensures that the pledge has the complete set of current CA
certificates beyond the pinned-domain-cert (see <xref target="PledgeAu thenticationOfProvisionalTLS" format="default"/> for a discussion of the certificates beyond the pinned-domain-cert (see <xref target="PledgeAu thenticationOfProvisionalTLS" format="default"/> for a discussion of the
limitations inherent in having a single certificate instead of a full limitations inherent in having a single certificate instead of a full
CA Certificates response.) Although these limitations are acceptable d uring initial bootstrapping, they are not appropriate for ongoing PKIX end entit y certificate validation.</t> CA certificate response). Although these limitations are acceptable du ring initial bootstrapping, they are not appropriate for ongoing PKIX end-entity certificate validation.</t>
</section> </section>
<section anchor="csrattributes" numbered="true" toc="default"> <section anchor="csrattributes" numbered="true" toc="default">
<name>EST CSR Attributes</name> <name>EST CSR Attributes</name>
<t>Automated bootstrapping occurs without local administrative <t>Automated bootstrapping occurs without local administrative
configuration of the pledge. In some deployments it is plausible that configuration of the pledge. In some deployments, it is plausible that
the pledge generates a certificate request containing only identity the pledge generates a certificate request containing only identity
information known to the pledge (essentially the X.509 IDevID informat ion) information known to the pledge (essentially the X.509 IDevID informat ion)
and ultimately receives a certificate containing domain specific and ultimately receives a certificate containing domain-specific
identity information. Conceptually the CA has complete control over identity information. Conceptually, the CA has complete control over
all fields issued in the end entity certificate. Realistically this all fields issued in the end-entity certificate. Realistically, this
is operationally difficult with the current status of PKI is operationally difficult with the current status of PKI
certificate authority deployments, where the CSR is submitted to the CA deployments, where the CSR is submitted to the
CA via a number of non-standard protocols. Even with all CA via a number of non-standard protocols. Even with all
standardized protocols used, it could operationally be problematic standardized protocols used, it could operationally be problematic
to expect that service specific certificate fields can be created to expect that service-specific certificate fields can be created
by a CA that is likely operated by a group that has no insight by a CA that is likely operated by a group that has no insight
into different network services/protocols used. For example, the into different network services/protocols used. For example, the
CA could even be outsourced.</t> CA could even be outsourced.</t>
<t>To alleviate these operational difficulties, the pledge MUST
<t>To alleviate these operational difficulties, the pledge <bcp14>MUST
</bcp14>
request the request the
EST "CSR Attributes" from the EST server and the EST server needs EST "CSR Attributes" from the EST server, and the EST server needs
to be able to reply with the attributes necessary for use of to be able to reply with the attributes necessary for use of
the certificate in its intended protocols/services. This approach the certificate in its intended protocols/services. This approach
allows for minimal CA integrations and instead allows for minimal CA integrations, and instead,
the local infrastructure (EST server) informs the pledge of the proper the local infrastructure (EST server) informs the pledge of the proper
fields to include in the generated CSR (such as rfc822Name). fields to include in the generated CSR (such as rfc822Name).
This approach is beneficial This approach is beneficial
to automated bootstrapping in the widest number of environments.</t> to automated bootstrapping in the widest number of environments.</t>
<t> <t>
In networks using the BRSKI enrolled certificate to authenticate In networks using the BRSKI enrolled certificate to authenticate
the ACP (Autonomic Control Plane), the EST CSR attributes MUST inclu the ACP, the EST CSR Attributes <bcp14>MUST</bcp14> include
de the ACP domain information fields defined in
the ACP Domain Information Fields defined in <xref target="RFC8994" sectionFormat="comma" section="6.2.2"/>.
<xref target="I-D.ietf-anima-autonomic-control-plane" format="defaul
t"/> section 6.1.1.
</t> </t>
<t>The registrar MUST also confirm that the resulting CSR is formatted as <t>The registrar <bcp14>MUST</bcp14> also confirm that the resulting C SR is formatted as
indicated before forwarding the request to a CA. If the registrar is indicated before forwarding the request to a CA. If the registrar is
communicating with the CA using a protocol such as full CMC, which communicating with the CA using a protocol such as full Certificate Ma
provides mechanisms to override the CSR attributes, then these nagement over CMS (CMC), which
mechanisms MAY be used even if the client ignores CSR Attribute provides mechanisms to override the CSR Attributes, then these
guidance.</t> mechanisms <bcp14>MAY</bcp14> be used even if the client ignores the g
uidance for the CSR Attributes.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>EST Client Certificate Request</name> <name>EST Client Certificate Request</name>
<t>The pledge MUST request a new client certificate. See RFC7030, <t>The pledge <bcp14>MUST</bcp14> request a new Client
section 4.2.</t> Certificate; see <xref target="RFC7030" sectionFormat="comma" section="4.2"/>.</
t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Enrollment Status Telemetry</name> <name>Enrollment Status Telemetry</name>
<t> <t>
For automated bootstrapping of devices, the administrative elements For automated bootstrapping of devices, the administrative elements
providing bootstrapping also provide indications to the system that provide bootstrapping also provide indications to the system
administrators concerning device lifecycle status. administrators concerning device life-cycle status.
This might include information concerning attempted bootstrapping This might include information concerning attempted bootstrapping
messages seen by the client. messages seen by the client.
The MASA provides logs and status of credential The MASA provides logs and the status of credential
enrollment. enrollment.
<xref target="RFC7030" format="default"/> assumes an end user and th Since an end user is assumed per <xref target="RFC7030" format="defa
erefore does ult"/>, a final success indication back to the server is not included. This is
not include a final success indication back to the server. This is
insufficient for automated use cases. insufficient for automated use cases.
</t> </t>
<t> <t>
The client MUST send an indicator to the Registrar about its The client <bcp14>MUST</bcp14> send an indicator to the registrar ab out its
enrollment status. It does this by using an HTTP POST of enrollment status. It does this by using an HTTP POST of
a JSON dictionary with the of attributes described below to a JSON dictionary with the attributes described below to
the new EST endpoint at "/.well-known/est/enrollstatus". the new EST endpoint at "/.well-known/brski/enrollstatus".
</t> </t>
<t> <t>
When indicating a successful enrollment the client SHOULD first When indicating a successful enrollment, the client <bcp14>SHOULD</b cp14> first
re-establish the EST TLS session using the newly obtained re-establish the EST TLS session using the newly obtained
credentials. TLS 1.2 supports doing this in-band, but credentials. TLS 1.3 supports doing this in-band, but
TLS 1.3 does not. The client SHOULD therefore always close the exis TLS 1.2 does not. The client <bcp14>SHOULD</bcp14> therefore always
ting close the existing
TLS connection, and start a new one. TLS connection and start a new one, using the same Join Proxy.
</t> </t>
<t> <t>
In the case of a failed enrollment, the client MUST send the In the case of a failed enrollment, the client <bcp14>MUST</bcp14> s end the
telemetry information over the same TLS telemetry information over the same TLS
connection that was used for the enrollment attempt, with a connection that was used for the enrollment attempt, with a
Reason string indicating why the most recent enrollment failed. Reason string indicating why the most recent enrollment failed.
(For failed attempts, the TLS connection is the most reliable way (For failed attempts, the TLS connection is the most reliable way
to correlate server-side information with what the client provides.) to correlate server-side information with what the client provides.)
</t> </t>
<t> <t>
The version and status fields <bcp14>MUST</bcp14> be present. The R
eason 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 om
itted.
</t>
<t>
The reason-context attribute is an arbitrary JSON object (literal The reason-context attribute is an arbitrary JSON object (literal
value or hash of values) which provides additional information value or hash of values) that provides additional information
specific to the failure to unroll from this pledge. specific to the failure to unroll from this pledge.
The contents of this field are not subject to The contents of this field are not subject to
standardization. This is represented by the group-socket standardization. This is represented by the group-socket
"$$arbitrary-map" in the CDDL. "$$arbitrary-map" in the CDDL.
</t> </t>
<t>
In the case of a SUCCESS the Reason string is omitted.
</t>
<figure anchor="cddl-enrollstatus"> <figure anchor="cddl-enrollstatus">
<name>CDDL for enrollment status POST</name> <name>CDDL for Enrollment Status POST</name>
<sourcecode name="enrollstatus.cddl" type="" markers="true"><![CDATA <sourcecode name="enrollstatus.cddl" type="CDDL" markers="true"><![C
[ DATA[
enrollstatus-post = { enrollstatus-post = {
"version": uint, "version": uint,
"status": bool, "status": bool,
"reason": text, ? "reason": text,
? "reason-context" : { $$arbitrary-map } ? "reason-context" : { $$arbitrary-map }
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t> <t>
An example status report can be seen below. It is sent with An example status report can be seen below. It is sent with
with the media type: application/json the media type: application/json
</t> </t>
<figure anchor="example-enrollstatus"> <figure anchor="example-enrollstatus">
<name>Example of <name>Example of Enrollment Status POST</name>
enrollment status POST</name> <sourcecode type="json">
<artwork name="" type="" align="left" alt=""><![CDATA[
{ {
"version":"1", "version": 1,
"status":true, "status":true,
"reason":"Informative human readable message", "reason":"Informative human readable message",
"reason-context": { "additional" : "JSON" } "reason-context": { "additional" : "JSON" }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<t>The server SHOULD respond with an HTTP 200 but MAY simply fail <t>The server <bcp14>SHOULD</bcp14> respond with an HTTP 200 but <bcp1 4>MAY</bcp14> simply fail
with an HTTP 404 error.</t> with an HTTP 404 error.</t>
<t> <t>
Within the server logs the server MUST capture if this message Within the server logs, the server <bcp14>MUST</bcp14> capture if th
was received over an TLS session with a matching client is message
certificate. was received over a TLS session with a matching Client
Certificate.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Multiple certificates</name> <name>Multiple Certificates</name>
<t> <t>
Pledges that require multiple certificates could establish Pledges that require multiple certificates could establish
direct EST connections to the registrar. direct EST connections to the registrar.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>EST over CoAP</name> <name>EST over CoAP</name>
<t>This document describes extensions to EST for the purposes <t>This document describes extensions to EST for the purpose
of bootstrapping of remote key infrastructures. of bootstrapping remote key infrastructures.
Bootstrapping is relevant for CoAP enrollment Bootstrapping is relevant for CoAP enrollment
discussions as well. The definition of EST and BRSKI over CoAP is not discussions as well. The definition of EST and BRSKI over CoAP is not
discussed within this document beyond ensuring proxy support for discussed within this document beyond ensuring proxy support for
CoAP operations. Instead it is anticipated that a definition of CoAP operations. Instead, it is anticipated that a definition of
CoAP mappings will occur in subsequent documents such as CoAP mappings will occur in subsequent documents such as
<xref target="I-D.ietf-ace-coap-est" format="default"/> and that <xref target="I-D.ietf-ace-coap-est" format="default"/> and that
CoAP mappings for BRSKI will be discussed either there or CoAP mappings for BRSKI will be discussed either there or
in future work.</t> in future work.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="estbase64" numbered="true" toc="default"> <section anchor="estbase64" numbered="true" toc="default">
<name>Clarification of transfer-encoding</name> <name>Clarification of Transfer-Encoding</name>
<t> <t>
<xref target="RFC7030" format="default"/> defines its endpoints to inclu <xref target="RFC7030" format="default"/> defines endpoints to include a
de a "Content-Transfer-Encoding" heading and payloads to be
"Content-Transfer-Encoding" heading, and the payloads to be base64-encoded DER <xref target="RFC4648" format="default"/>.
<xref target="RFC4648" format="default"/> Base64 encoded DER.
</t> </t>
<t> <t>
When used within BRSKI, the original RFC7030 EST endpoints remain When used within BRSKI, the original EST endpoints remain
Base64 encoded, but the new BRSKI end points which send and receive bina base64 encoded <xref target="RFC7030"/> (as clarified by <xref target="R
ry FC8951" format="default"/>), but the new BRSKI endpoints that send and receive b
artifacts (specifically, "/.well-known/est/requestvoucher") are inary
artifacts (specifically, "/.well-known/brski/requestvoucher") are
binary. That is, no encoding is used. binary. That is, no encoding is used.
</t> </t>
<t> <t>
In the BRSKI context, the EST "Content-Transfer-Encoding" header In the BRSKI context, the EST "Content-Transfer-Encoding" header
field if present, SHOULD be ignored. This header field does not need field <bcp14>SHOULD</bcp14> be ignored if present. This header field doe s not need
to be included. to be included.
</t> </t>
</section> </section>
<section anchor="reducedsecuritymodes" numbered="true" toc="default"> <section anchor="reducedsecuritymodes" numbered="true" toc="default">
<name>Reduced security operational modes</name> <name>Reduced Security Operational Modes</name>
<t> <t>
A common requirement of bootstrapping is to support less secure operatio nal A common requirement of bootstrapping is to support less secure operatio nal
modes for support specific use cases. This section suggests a range of modes for support-specific use cases. This section suggests a range of
mechanisms that would alter the security assurance of BRSKI to accommoda te mechanisms that would alter the security assurance of BRSKI to accommoda te
alternative deployment architectures and mitigate lifecycle management i ssues alternative deployment architectures and mitigate life-cycle management issues
identified in <xref target="privacyconsiderations" format="default"/>. They are presented here as informative identified in <xref target="privacyconsiderations" format="default"/>. They are presented here as informative
(non-normative) design guidance for future standardization (non-normative) design guidance for future standardization
activities. activities.
<xref target="acpapplicability" format="default"/> provides standardizat ion applicability statements <xref target="acpapplicability" format="default"/> provides standardizat ion applicability statements
for the ANIMA ACP. Other users for the ANIMA ACP. Other users
would be expected that subsets of these mechanisms could be profiled wit would expect that subsets of these mechanisms could be profiled with
h an
accompanying applicability statements similar to the one described in accompanying applicability statements similar to the one described in
<xref target="acpapplicability" format="default"/>. <xref target="acpapplicability" format="default"/>.
</t> </t>
<t> <t>
This section is considered non-normative in the generality of the This section is considered non-normative in the generality of the
protocol. Use of the suggested mechanisms here MUST be detailed in protocol. Use of the suggested mechanisms here <bcp14>MUST</bcp14> be d etailed in
specific profiles of BRSKI, such as in <xref target="acpapplicability" f ormat="default"/>. specific profiles of BRSKI, such as in <xref target="acpapplicability" f ormat="default"/>.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Trust Model</name> <name>Trust Model</name>
<t> <t>
This section explains the trust relationships detailed in <xref target=" flow" format="default"/>: This section explains the trust relationships detailed in <xref target=" flow" format="default"/>:
</t> </t>
<figure>
<name>Elements of BRSKI Trust Model</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Join | | Domain | |Manufacturer| | Pledge | | Join | | Domain | |Manufacturer|
| | | Proxy | | Registrar | | Service | | | | Proxy | | Registrar | | Service |
| | | | | | | (Internet) | | | | | | | | (Internet) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
]]></artwork> ]]></artwork>
<t keepWithPrevious="true">Figure 10</t> </figure>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Pledge:</dt> <dt>Pledge:</dt>
<dd>The pledge could be compromised and <dd>The pledge could be compromised and
providing an attack vector for malware. The entity is trusted to provide an attack vector for malware. The entity is trusted to
only imprint using secure methods described in this document. only imprint using secure methods described in this document.
Additional endpoint assessment techniques are RECOMMENDED but are Additional endpoint assessment techniques are <bcp14>RECOMMENDED</bc
out-of-scope of this document.</dd> p14> but are
out of scope of this document.</dd>
<dt>Join Proxy:</dt> <dt>Join Proxy:</dt>
<dd>Provides proxy functionalities but is not <dd>Provides proxy functionalities but is not
involved in security considerations.</dd> involved in security considerations.</dd>
<dt>Registrar:</dt> <dt>Registrar:</dt>
<dd>When interacting with a MASA a <dd>When interacting with a MASA, a
registrar makes all decisions. For Ownership Audit Vouchers (see <xr registrar makes all decisions. For Ownership Audit Vouchers (see <xr
ef target="RFC8366" format="default"/>) the registrar is provided an opportunity ef target="RFC8366" format="default"/>), the registrar is provided an opportunit
to y to
accept MASA decisions.</dd> accept MASA decisions.</dd>
<dt>Vendor Service, MASA:</dt> <dt>Vendor Service, MASA:</dt>
<dd>This form of manufacturer service is <dd>This form of manufacturer service is
trusted to accurately log all claim attempts and to provide trusted to accurately log all claim attempts and to provide
authoritative log information to registrars. The MASA does not authoritative log information to registrars. The MASA does not
know which devices are associated with which domains. These claims know which devices are associated with which domains. These claims
could be strengthened by using cryptographic log techniques to could be strengthened by using cryptographic log techniques to
provide append only, cryptographic assured, publicly auditable provide append only, cryptographic assured, publicly auditable
logs. </dd> logs. </dd>
<dt>Vendor Service, Ownership Validation:</dt> <dt>Vendor Service, Ownership Validation:</dt>
<dd>This form of <dd>This form of
manufacturer service is trusted to accurately know which device is o wned manufacturer service is trusted to accurately know which device is o wned
by which domain.</dd> by which domain.</dd>
</dl> </dl>
</section> </section>
<section anchor="pledgeReductions" numbered="true" toc="default"> <section anchor="pledgeReductions" numbered="true" toc="default">
<name>Pledge security reductions</name> <name>Pledge Security Reductions</name>
<t> <t>
The following is a list of alternative behaviours that the The following is a list of alternative behaviors that the
pledge can be programmed to implement. These behaviours are not pledge can be programmed to implement. These behaviors are not
mutually exclusive, nor are they dependent upon each other. mutually exclusive, nor are they dependent upon each other.
Some of these methods enable offline and emergency (touch based) Some of these methods enable offline and emergency (touch-based)
deployment use cases. Normative language is used as these behaviours deployment use cases. Normative language is used as these behaviors
are referenced in later sections in a normative fashion. are referenced in later sections in a normative fashion.
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
The pledge MUST accept nonceless vouchers. This allows for The pledge <bcp14>MUST</bcp14> accept nonceless vouchers. This a
a use case where the registrar can not connect to the MASA llows for
a use case where the registrar cannot connect to the MASA
at the deployment time. at the deployment time.
Logging and validity periods address the Logging and validity periods address the
security considerations of supporting these use cases. security considerations of supporting these use cases.
</li> </li>
<li> <li>
Many devices already support "trust on first use" for Many devices already support "trust on first use" for
physical interfaces such as console ports. This document does physical interfaces such as console ports. This document does
not change that reality. Devices supporting this protocol not change that reality. Devices supporting this protocol
MUST NOT support "trust on first use" on network <bcp14>MUST NOT</bcp14> support "trust on first use" on network
interfaces. This is because "trust on first use" over network interfaces. This is because "trust on first use" over network
interfaces would undermine the logging based security interfaces would undermine the logging based security
protections provided by this specification. protections provided by this specification.
</li> </li>
<li> <li>
The pledge MAY have an operational mode where it skips voucher The pledge <bcp14>MAY</bcp14> have an operational mode where it
validation one time. For example if a physical button is skips voucher
validation one time, for example, if a physical button is
depressed during the bootstrapping operation. This can be depressed during the bootstrapping operation. This can be
useful if the manufacturer service is unavailable. This useful if the manufacturer service is unavailable. This
behavior SHOULD be available via local configuration or behavior <bcp14>SHOULD</bcp14> be available via local configurat ion or
physical presence methods (such as use of a serial/craft physical presence methods (such as use of a serial/craft
console) to ensure new entities can always be deployed even console) to ensure new entities can always be deployed even
when autonomic methods fail. This allows for unsecured when autonomic methods fail. This allows for unsecured
imprint. imprint.
</li> </li>
<li> <li>
A craft/serial console could include a command such as A craft/serial console could include a command such as
"est-enroll [2001:db8:0:1]:443" that begins the "est-enroll [2001:db8:0:1]:443" that begins the
EST process from the point after the voucher is validated. EST process from the point after the voucher is validated.
This process SHOULD include server certificate verification usin g This process <bcp14>SHOULD</bcp14> include server certificate ve rification using
an on-screen fingerprint. an on-screen fingerprint.
</li> </li>
</ol> </ol>
<t>It is RECOMMENDED that "trust on first use" or any method of skipping <t>It is <bcp14>RECOMMENDED</bcp14> that "trust on first use" or any met
voucher hod of skipping voucher
validation (including use of craft serial console) only be available if validation (including use of a craft serial console) only be available i
hardware assisted Network Endpoint f hardware-assisted Network Endpoint
Assessment (NEA: <xref target="RFC5209" format="default"/>) Assessment (NEA) <xref target="RFC5209" format="default"/>
is supported. This recommendation ensures that domain network monitoring is supported. This recommendation ensures that domain network monitoring
can detect inappropriate use of offline or emergency can detect inappropriate use of offline or emergency
deployment procedures when voucher-based bootstrapping is not used.</t> deployment procedures when voucher-based bootstrapping is not used.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registrar security reductions</name> <name>Registrar Security Reductions</name>
<t> <t>
A registrar can choose to accept devices using less secure methods. A registrar can choose to accept devices using less secure methods.
They MUST NOT be the default behavior. They <bcp14>MUST NOT</bcp14> be the default behavior.
These methods may be acceptable in situations where threat These methods may be acceptable in situations where threat
models indicate that low security is adequate. models indicate that low security is adequate.
This includes situations where security decisions are being made by This includes situations where security decisions are being made by
the local administrator: the local administrator:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>A registrar MAY choose to accept all devices, or all devices of
a particular type, at the administrator's discretion. This could <li>A registrar <bcp14>MAY</bcp14> choose to accept all devices, or al
occur when informing all registrars of unique identifiers of new l devices of
entities might be operationally difficult.</li> a particular type. The administrator could make this choice in cases w
<li>A registrar MAY choose to accept devices that claim a unique here it
is operationally difficult to configure the registrar with the unique
identifier of each new device expected.</li>
<li>A registrar <bcp14>MAY</bcp14> choose to accept devices that claim
a unique
identity without the benefit of authenticating that claimed identity without the benefit of authenticating that claimed
identity. This could occur when the pledge does not include an identity. This could occur when the pledge does not include an
X.509 IDevID factory installed credential. New Entities without an X.509 IDevID factory-installed credential. New entities without an
X.509 IDevID credential MAY form the <xref target="RequestVoucherFro X.509 IDevID credential <bcp14>MAY</bcp14> form the request per <xre
mRegistrar" format="default"/> request using the f target="RequestVoucherFromRegistrar" format="default"/> using the
<xref target="RequestVoucherFromMASA" format="default"/> format to e format per <xref target="RequestVoucherFromMASA" format="default"/>
nsure the to ensure the
pledge's serial number information is provided to the registrar pledge's serial number information is provided to the registrar
(this includes the IDevID AuthorityKeyIdentifier value, which would (this includes the IDevID AuthorityKeyIdentifier value, which would
be statically configured on the pledge.) The pledge MAY refuse to be statically configured on the pledge). The pledge <bcp14>MAY</bcp1
provide a TLS client certificate (as one is not available.) The 4> refuse to
pledge SHOULD support HTTP-based or certificate-less TLS provide a TLS Client Certificate (as one is not available). The
authentication as described in EST RFC7030 section 3.3.2. A pledge <bcp14>SHOULD</bcp14> support HTTP-based or certificate-less
registrar MUST NOT accept unauthenticated New Entities unless it TLS
authentication as described in EST <xref target="RFC7030"
sectionFormat="comma" section="3.3.2"/>. A
registrar <bcp14>MUST NOT</bcp14> accept unauthenticated new entitie
s unless it
has been configured to do so by an administrator that has verified has been configured to do so by an administrator that has verified
that only expected new entities can communicate with a registrar that only expected new entities can communicate with a registrar
(presumably via a physically secured perimeter.)</li> (presumably via a physically secured perimeter.)</li>
<li>A registrar MAY submit a nonceless voucher-requests to the MASA <li>A registrar <bcp14>MAY</bcp14> submit a nonceless voucher-request
service (by not including a nonce in the voucher-request.) The resul to the MASA
ting service (by not including a nonce in the voucher-request). The resul
ting
vouchers can then be stored by the registrar until vouchers can then be stored by the registrar until
they are needed during bootstrapping operations. This is for use they are needed during bootstrapping operations. This is for use
cases where the target network is protected by an air gap and cases where the target network is protected by an air gap and
therefore cannot contact the MASA service during pledge therefore cannot contact the MASA service during pledge
deployment.</li> deployment.</li>
<li> <li>
A registrar MAY ignore unrecognized nonceless log A registrar <bcp14>MAY</bcp14> ignore unrecognized nonceless log
entries. This could occur when used equipment is purchased with a entries. This could occur when used equipment is purchased with a
valid history being deployed in air gap networks that valid history of being deployed in air gap networks that
required offline vouchers. required offline vouchers.
</li> </li>
<li>A registrar MAY accept voucher formats of future types that <li>A registrar <bcp14>MAY</bcp14> accept voucher formats of future ty
can not be parsed by the Registrar. This reduces the Registrar's pes that
cannot be parsed by the registrar. This reduces the registrar's
visibility into the exact voucher contents but does not change visibility into the exact voucher contents but does not change
the protocol operations.</li> the protocol operations.</li>
</ol> </ol>
</section> </section>
<section anchor="masasecurityreductions" numbered="true" toc="default"> <section anchor="masasecurityreductions" numbered="true" toc="default">
<name>MASA security reductions</name> <name>MASA Security Reductions</name>
<t> <t>
Lower security modes chosen by the MASA service affect all device Lower security modes chosen by the MASA service affect all device
deployments unless the lower-security behavior is tied to specific deployments unless the lower security behavior is tied to specific
device identities. device identities.
The modes described below can be applied to specific devices The modes described below can be applied to specific devices
via knowledge of what devices were sold. They can also be via knowledge of what devices were sold. They can also be
bound to specific customers (independent of the device identity) by bound to specific customers (independent of the device identity) by
authenticating the customer's Registrar. authenticating the customer's registrar.
</t> </t>
<section anchor="masasecurityreduction_nonce" numbered="true" toc="defau lt"> <section anchor="masasecurityreduction_nonce" numbered="true" toc="defau lt">
<name>Issuing Nonceless vouchers</name> <name>Issuing Nonceless Vouchers</name>
<t> <t>
A MASA has the option of not including a nonce in the voucher, A MASA has the option of not including a nonce in the voucher
and/or not requiring one to be present in the voucher-request. This and/or not requiring one to be present in the voucher-request. This
results in distribution of a voucher that may never expire and in results in distribution of a voucher that may never expire and, in
effect makes the specified Domain an always trusted entity to the effect, makes the specified domain an always trusted entity to the
pledge during any subsequent bootstrapping attempts. That a nonceles pledge during any subsequent bootstrapping attempts. The log informa
s tion captures when
voucher was issued a nonceless voucher is issued so that the registrar
is captured in the log information so that the registrar
can make appropriate security decisions when a pledge joins the can make appropriate security decisions when a pledge joins the
Domain. Nonceless vouchers are useful to support use cases where reg istrars might domain. Nonceless vouchers are useful to support use cases where reg istrars might
not be online during actual device deployment. not be online during actual device deployment.
</t> </t>
<t> <t>
While a nonceless voucher may include an expiry date, a typical While a nonceless voucher may include an expiry date, a typical
use for a nonceless voucher is for it to be long-lived. If use for a nonceless voucher is for it to be long lived. If
the device can be trusted to have an accurate clock (the MASA the device can be trusted to have an accurate clock (the MASA
will know), then a nonceless voucher CAN be issued with a limited will know), then a nonceless voucher CAN be issued with a limited
lifetime. lifetime.
</t> </t>
<t> <t>
A more typical case for a nonceless voucher is for use with A more typical case for a nonceless voucher is for use with
offline onboarding scenarios where it is not possible to pass offline onboarding scenarios where it is not possible to pass
a fresh voucher-request to the MASA. The use of a long-lived a fresh voucher-request to the MASA. The use of a long-lived
voucher also eliminates concern about the availability of the voucher also eliminates concern about the availability of the
MASA many years in the future. Thus many nonceless vouchers MASA many years in the future. Thus, many nonceless vouchers
will have no expiry dates. will have no expiry dates.
</t> </t>
<t> <t>
Thus, the long lived nonceless voucher does not require the proof Thus, the long-lived nonceless voucher does not require proof
that the device is online. Issuing such a thing is only accepted that the device is online. Issuing such a thing is only accepted
when the registrar is authenticated by the MASA and the when the registrar is authenticated by the MASA and the
MASA is authorized to provide this functionality to this MASA is authorized to provide this functionality to this
customer. customer.
The MASA is RECOMMENDED to use this The MASA is <bcp14>RECOMMENDED</bcp14> to use this
functionality only in concert with an enhanced level of ownership functionality only in concert with an enhanced level of ownership
tracking, the details of which are out of scope for this document. tracking, the details of which are out of scope for this document.
</t> </t>
<t> <t>
If the pledge device is known to have If the pledge device is known to have
a real-time-clock that is set from the factory, use of a voucher a real-time clock that is set from the factory, use of a voucher
validity period is RECOMMENDED. validity period is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
</section> </section>
<section anchor="masasecurityreduction_tofu" numbered="true" toc="defaul t"> <section anchor="masasecurityreduction_tofu" numbered="true" toc="defaul t">
<name>Trusting Owners on First Use</name> <name>Trusting Owners on First Use</name>
<t> <t>
A MASA has the option of not verifying ownership before A MASA has the option of not verifying ownership before
responding with a voucher. responding with a voucher.
This is expected to be a common operational model because This is expected to be a common operational model because
doing so relieves the manufacturer providing MASA services from doing so relieves the manufacturer providing MASA services from
having having to track ownership during shipping and throughout the
to track ownership during shipping and supply chain and allows supply chain, and it allows
for a very low overhead MASA service. A registrar uses the audit for a very low overhead MASA service.
log information as a defense in depth strategy to ensure that this A registrar uses the audit-log
does not occur unexpectedly (for example when purchasing new information as an in-depth defense strategy to ensure that this
equipment the registrar would throw an error if any audit log does not occur unexpectedly (for example, when purchasing new
information is reported.) The MASA SHOULD verify the equipment, the registrar would throw an error if any audit-log
'prior-signed-voucher-request' information for pledges that support information is reported). The MASA <bcp14>SHOULD</bcp14> verify the
prior-signed-voucher-request information for pledges that support
that functionality. This provides a proof-of-proximity that functionality. This provides a proof-of-proximity
check that reduces the need for ownership verification. The check that reduces the need for ownership verification. The
proof-of-proximity comes from the assumption that the pledge and proof-of-proximity comes from the assumption that the pledge and
Join Proxy are on the same link-local connection. Join Proxy are on the same link-local connection.
</t> </t>
<t> <t>
A MASA that practices Trust-on-First-Use (TOFU) for Registrar A MASA that practices TOFU for registrar
identity may wish to annotate the origin of the connection identity may wish to annotate the origin of the connection
by IP address or netblock, and restrict future use of that by IP address or netblock and restrict future use of that
identity from other locations. A MASA that does this SHOULD identity from other locations. A MASA that does this <bcp14>SHOULD<
/bcp14>
take care to not create nuisance situations for itself when take care to not create nuisance situations for itself when
a customer has multiple registrars, or uses outgoing IPv4 NAT44 a customer has multiple registrars or uses outgoing IPv4-to-IPv4 NAT (NAT44)
connections that change frequently. connections that change frequently.
</t> </t>
</section> </section>
<section anchor="masasecurityreduction_newanchor" numbered="true" toc="d efault"> <section anchor="masasecurityreduction_newanchor" numbered="true" toc="d efault">
<name>Updating or extending voucher trust anchors</name> <name>Updating or Extending Voucher Trust Anchors</name>
<t> <t>
This section deals with the problem of a MASA that is no longer This section deals with two problems: A MASA that is no longer avail
available due to a failed business, or the situation where a able due to
MASA is uncooperative to a secondary sale. a failed business and a MASA that is uncooperative to a secondary sal
e.
</t> </t>
<t> <t>
A manufacturer could offer a management mechanism that allows the A manufacturer could offer a management mechanism that allows the
list of voucher verification trust anchors to be extended. list of voucher verification trust anchors to be extended.
<xref target="I-D.ietf-netconf-keystore" format="default"/> is one s uch interface <xref target="I-D.ietf-netconf-keystore" format="default"/> describe s one such interface
that could be implemented using YANG. Pretty much any that could be implemented using YANG. Pretty much any
configuration mechanism used today could be extended to configuration mechanism used today could be extended to
provide the needed additional update. provide the needed additional update.
A manufacturer could even decide to install the domain CA A manufacturer could even decide to install the domain CA
trust anchors received during the EST "cacerts" step as voucher trust anchors received during the EST "cacerts" step as voucher
verification anchors. Some additional signals will be needed to verification anchors. Some additional signals will be needed to
clearly identify which keys have voucher validation authority from clearly identify which keys have voucher validation authority from
among those signed by the domain CA. This is future work. among those signed by the domain CA. This is future work.
</t> </t>
<t> <t>
With the above change to the list of anchors, vouchers can be With the above change to the list of anchors, vouchers can be
issued by an alternate MASA. This could be the previous owner issued by an alternate MASA. This could be the previous owner
(the seller), or some other trusted third party who is mediating (the seller) or some other trusted third party who is mediating
the sale. If it was a third party, then the seller would need the sale. If it is a third party, the seller would need
to have taken steps to introduce the third party configuration to to take steps to introduce the third-party configuration to
the device prior disconnection. The third party the device prior to disconnection. The third party
(e.g. a wholesaler of used equipment) could however (e.g., a wholesaler of used equipment) could, however,
use a mechanism described in <xref target="pledgeReductions" format= "default"/> use a mechanism described in <xref target="pledgeReductions" format= "default"/>
to take control of the device after receiving it physically. to take control of the device after receiving it physically.
This would permit the third party to act as the MASA for future This would permit the third party to act as the MASA for future
onboarding actions. As the IDevID certificate probably can not onboarding actions. As the IDevID certificate probably cannot
be replaced, the new owner's Registrar would have to support be replaced, the new owner's registrar would have to support
an override of the MASA URL. an override of the MASA URL.
</t> </t>
<t> <t>
To be useful for resale or other transfers of ownership one of To be useful for resale or other transfers of ownership, one of
two situations will need to occur. The simplest is that the two situations will need to occur. The simplest is that the
device is not put through any kind of factory default/reset device is not put through any kind of factory default/reset
before going through onboarding again. Some other secure, physical before going through onboarding again. Some other secure, physical
signal would be needed to initiate it. This is most suitable for signal would be needed to initiate it. This is most suitable for
redeploying a device within the same Enterprise. This would redeploying a device within the same enterprise. This would
entail having previous configuration in the system until entirely entail having previous configuration in the system until entirely
replaced by the new owner, and represents some level of risk. replaced by the new owner, and it represents some level of risk.
</t> </t>
<t> <t>
The second mechanism is that there would need to be two levels For the second scenario, there would need to be two levels
of factory reset. One would take the system back entirely to of factory reset. One would take the system back entirely to
manufacturer state, including removing any added trust anchors, manufacturer state, including removing any added trust anchors,
and the second (more commonly used) one would just restore the and the other (more commonly used) one would just restore the
configuration back to a known default without erasing trust configuration back to a known default without erasing trust
anchors. This weaker factory reset might leave valuable anchors. This weaker factory reset might leave valuable
credentials on the device and this may be unacceptable to credentials on the device, and this may be unacceptable to
some owners. some owners.
</t> </t>
<t> <t>
As a third option, the manufacturer's trust anchors could be As a third option, the manufacturer's trust anchors could be
entirely overwritten with local trust anchors. A factory default entirely overwritten with local trust anchors. A factory default
would never restore those anchors. This option comes with a lot would never restore those anchors. This option comes with a lot
of power, but also a lot of responsibility: if access to of power but is also a lot of responsibility: if access to
the private part of the new anchors the private part of the new anchors
are lost the manufacturer may be unable to help. are lost, the manufacturer may be unable to help.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requires the following IANA actions:</t> <t>Per this document, IANA has completed the following actions.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>The IETF XML Registry</name> <name>The IETF XML Registry</name>
<t> <t>
This document registers a URI in the "IETF XML This document registers a URI in the "IETF XML
Registry" <xref target="RFC3688" format="default"/>. Registry" <xref target="RFC3688" format="default"/>.
IANA is asked to register the following:</t> IANA has registered the following:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dl spacing="compact">
URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-voucher-request</dd>
Registrant Contact: The ANIMA WG of the IETF. <dt>Registrant Contact:</dt><dd>The ANIMA WG of the IETF.</dd>
XML: N/A, the requested URI is an XML namespace. <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
]]></artwork> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Module Names Registry</name> <name>YANG Module Names Registry</name>
<t> <t>
This document registers a YANG module in the This document registers a YANG module in the
"YANG Module Names" registry <xref target="RFC6020" format="default"/> . "YANG Module Names" registry <xref target="RFC6020" format="default"/> .
IANA is asked to register the following:</t> IANA has registered the following:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dl spacing="compact">
name: ietf-voucher-request <dt>Name:</dt><dd>ietf-voucher-request</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-voucher-re
prefix: vch quest</dd>
reference: THIS DOCUMENT <dt>Prefix:</dt><dd>vch</dd>
]]></artwork> <dt>Reference:</dt><dd>RFC 8995</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<name>Well-known EST registration</name> <section numbered="true" toc="default">
<t> <name>BRSKI Well-Known Considerations</name>
This document extends the definitions of "est" (so far defined via <section numbered="true" toc="default">
RFC7030) in the <name>BRSKI .well-known Registration</name>
"https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtm <t>
l" To the "Well-Known URIs" registry at
registry. IANA is asked to change the registration of "est" to <eref target="https://www.iana.org/assignments/well-known-uris/"/>,
include RFC7030 and this document. this document registers the well-known name "brski" with the
</t> following filled-in template from <xref target="RFC8615" format="def
ault"/>:
</t>
<dl newline="false" spacing="compact">
<dt>URI Suffix:</dt><dd>brski</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
</dl>
<t>
IANA has changed the registration of "est" to now only
include <xref target="RFC7030" format="default"/> and no longer this
document.
Earlier draft versions of this document used "/.well-known/est" rath
er
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>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>PKIX Registry</name> <name>PKIX Registry</name>
<t>IANA is requested to register the following:</t> <t>IANA has registered the following:</t>
<t> <t>
This document requests a number for id-mod-MASAURLExtn2016(TBD) a number for id-mod-MASAURLExtn2016(96)
from the pkix(7) id-mod(0) Registry. from the pkix(7) id-mod(0) Registry.
</t> </t>
<t> <t>
This document has received an early allocation from the id-pe registry IANA has assigned a number from the id-pe registry
(SMI Security for PKIX Certificate Extension) for id-pe-masa-url (Structure of Management Information (SMI) Security for PKIX Certifica
te Extension) for id-pe-masa-url
with the value 32, resulting in an OID of 1.3.6.1.5.5.7.1.32. 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-nu mbers-1.3.6.1.5.5.7.1 -->
</t> </t>
</section> </section>
<section anchor="pledgestatustelemetryregistry" numbered="true" toc="defau lt"> <section anchor="pledgestatustelemetryregistry" numbered="true" toc="defau lt">
<name>Pledge BRSKI Status Telemetry</name> <name>Pledge BRSKI Status Telemetry</name>
<t> <t>
IANA is requested to create a new Registry entitled: "BRSKI IANA has created a new registry entitled "BRSKI
Parameters", and within that Registry to create a table called: Parameters" and has created, within that registry, a table called:
"Pledge BRSKI Status Telemetry Attributes". "Pledge BRSKI Status Telemetry Attributes".
New items can be added using the New items can be added using the
Specification Required. The following items are to be in the Specification Required process. The following items are in the
initial registration, with this document (<xref target="pledgestatus" initial registration, with this document (see <xref target="pledgestat
format="default"/>) as the reference: us" format="default"/>) as the reference:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>version</li> <li>version</li>
<li>Status</li> <li>Status</li>
<li>Reason</li> <li>Reason</li>
<li>reason-context</li> <li>reason-context</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DNS Service Names</name> <name>DNS Service Names</name>
<t>IANA is requested to register the following Service Names:</t> <t>IANA 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 Bootstrapping Remote Secure Key
Infrastructures Proxy
Reference: [This document]
Service Name: brski-registrar <dl spacing="compact">
Transport Protocol(s): tcp <dt>Service Name:</dt><dd>brski-proxy</dd>
Assignee: IESG <iesg@ietf.org>. <dt>Transport Protocol(s):</dt><dd>tcp</dd>
Contact: IESG <iesg@ietf.org> <dt>Assignee:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
Description: The Bootstrapping Remote Secure Key <dt>Contact:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
Infrastructures Registrar <dt>Description:</dt><dd>The Bootstrapping Remote Secure Key Infrastructure
Reference: [This document] Proxy</dd>
]]></artwork> <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 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="de
fault"/> of this document.
</t>
</section> </section>
</section> </section>
<section anchor="acpapplicability" numbered="true" toc="default"> <section anchor="acpapplicability" numbered="true" toc="default">
<name>Applicability to the Autonomic Control Plane (ACP)</name> <name>Applicability to the Autonomic Control Plane (ACP)</name>
<t> <t>
This document provides a solution to the requirements for secure This document provides a solution to the requirements for secure
bootstrap set out in <xref target="RFC8368" format="default">Using an Au bootstrapping as defined in "<xref target="RFC8368"
tonomic Control Plane for format="title"/>" <xref target="RFC8368" format="default"/>,
Stable Connectivity of Network Operations, Administration, and "A Reference Model for Autonomic Networking" <xref target="RFC8993" forma
Maintenance </xref>, t="default"/>, and specifically
<xref target="I-D.ietf-anima-reference-model" format="default">A Referen "An Autonomic Control Plane (ACP)" <xref target="RFC8994" format="default
ce Model for "/>; see Sections <xref target="RFC8994" sectionFormat="bare" section="3.2"/> ("
Autonomic Networking</xref> and specifically the Secure Bootstrap over an Unconfigured Network") and
<xref target="I-D.ietf-anima-autonomic-control-plane" format="default">A <xref target="RFC8994" sectionFormat="bare" section="6.2"/> ("ACP Domain
n Autonomic , Certificate, and Network").
Control Plane (ACP)</xref>, section 3.2 (Secure Bootstrap), and
section 6.1 (ACP Domain, Certificate and Network).
</t> </t>
<t> <t>
The protocol described in this document has appeal in a number of The protocol described in this document has appeal in a number of
other non-ANIMA use cases. Such uses of the protocol will be other non-ANIMA use cases. Such uses of the protocol will be
deploying into other environments with different tradeoffs of deployed into other environments with different tradeoffs of
privacy, security, reliability and autonomy from manufacturers. privacy, security, reliability, and autonomy from manufacturers.
As such those use cases will need to provide their own applicability As such, those use cases will need to provide their own applicability
statements, and will need to address unique privacy and security statements and will need to address unique privacy and security
considerations for the environments in which they are used. considerations for the environments in which they are used.
</t> </t>
<t> <t>
The autonomic control plane (ACP) that is bootstrapped by The ACP that is bootstrapped by
the BRSKI protocol is typically used in medium to large Internet the BRSKI protocol is typically used in medium to large Internet
Service Provider organizations. Equivalent enterprises that have service provider organizations. Equivalent enterprises that have
significant layer-3 router connectivity also will find significant significant Layer 3 router connectivity also will find significant
benefit, particularly if the Enterprise has many sites. benefit, particularly if the enterprise has many sites.
(A network consisting of primarily layer-2 (A network consisting of primarily Layer 2
is not excluded, but the adjacencies that the ACP will create and is not excluded, but the adjacencies that the ACP will create and
maintain will not reflect the topology until all devices participate maintain will not reflect the topology until all devices participate
in the ACP). in the ACP.)
</t> </t>
<t> <t>
In the ACP, the Join Proxy is found to be proximal because In the ACP, the Join Proxy is found to be proximal because
communication between the pledge and the join proxy is exclusively communication between the pledge and the Join Proxy is exclusively
on IPv6 Link-Local addresses. The proximity of the on IPv6 link-local addresses. The proximity of the
Join Proxy to the Registrar is validated by the Registrar using ANI Join Proxy to the registrar is validated by the registrar using ANI
ACP IPv6 Unique Local Addresses (ULA). ACP IPv6 ULAs.
ULAs are not routable over the Internet, so as long as the Join ULAs are not routable over the Internet, so as long as the Join
Proxy is operating correctly the proximity asssertion is satisfied. Proxy is operating correctly, the proximity assertion is satisfied.
Other uses of BRSKI will need make similar analysis if they Other uses of BRSKI will need similar analysis if they
use proximity assertions. use proximity assertions.
</t> </t>
<t> <t>
As specified in the ANIMA charter, this work "..focuses on As specified in the ANIMA charter, this work "focuses on
professionally-managed networks." Such a network has an operator professionally-managed networks." Such a network has an operator
and can do things like install, configure and operate the and can do things like install, configure, and operate the
Registrar function. The operator makes purchasing decisions registrar function. The operator makes purchasing decisions
and is aware of what manufacturers it expects to see on its and is aware of what manufacturers it expects to see on its
network. network.
</t> </t>
<t> <t>
Such an operator is also capable of performing bootstrapping of a Such an operator is also capable of performing bootstrapping of a
device using a serial-console (craft console). The zero-touch device using a serial console (craft console). The zero-touch
mechanism presented in this and the ACP document <xref target="I-D.ietf- mechanism presented in this and the ACP document <xref target="RFC8994"
anima-autonomic-control-plane" format="default"/> format="default"/>
represents a represents a
significiant efficiency: in particular it reduces the need to significant efficiency: in particular, it reduces the need to
put senior experts on airplanes to configure devices in person. put senior experts on airplanes to configure devices in person.
</t> </t>
<t> <t>
There is a recognition as the technology evolves that not every As the technology evolves, there is recognition that not every
situation may work out, and occasionally a human may still have to situation may work out, and occasionally a human may still have to
visit. In recognition of this, some mechanisms are presented in visit. Given this, some mechanisms are presented in
<xref target="pledgeReductions" format="default"/>. The manufacturer MUS <xref target="pledgeReductions" format="default"/>. The manufacturer <bc
T provide at p14>MUST</bcp14> provide at
least one of the one-touch mechanisms described that permit least one of the one-touch mechanisms described that permit
enrollment to be proceed without availability of any manufacturer enrollment to proceed without the availability of any manufacturer
server (such as the MASA). server (such as the MASA).
</t> </t>
<t> <t>
The BRSKI protocol is going into environments where there have The BRSKI protocol is going into environments where there have
already been quite a number of vendor proprietary management already been quite a number of vendor proprietary management
systems. Those are not expected to go away quickly, but rather to systems. Those are not expected to go away quickly but rather to
leverage the secure credentials that are provisioned by BRSKI. The leverage the secure credentials that are provisioned by BRSKI. The
connectivity requirements of said management systems are provided connectivity requirements of the said management systems are provided
by the ACP. by the ACP.
</t> </t>
<section anchor="operationalrequirements" numbered="true" toc="default"> <section anchor="operationalrequirements" numbered="true" toc="default">
<name>Operational Requirements</name> <name>Operational Requirements</name>
<t> <t>
This section collects operational requirements based upon the three This section collects operational requirements based upon the three
roles involved in BRSKI: The Manufacturer Authorized Signing roles involved in BRSKI: the MASA, the (domain) owner, and the device.
Authority (MASA), the (Domain) Owner and the Device.
It should be recognized that the manufacturer may be involved in two It should be recognized that the manufacturer may be involved in two
roles, as it creates the software/firmware for the device, and also roles, as it creates the software/firmware for the device and
may be the operator of the MASA. may also be the operator of the MASA.
</t> </t>
<t> <t>
The requirements in this section are presented using BCP14 The requirements in this section are presented using BCP 14 language
(<xref target="RFC2119" format="default"/>, <xref target="RFC8174" for <xref target="RFC2119" format="default"/> <xref target="RFC8174" forma
mat="default"/>) t="default"/>.
language. These do not represent new normative statements, just a
These do not represent new normative statements, just a
review of a few such things in one place by role. They also apply 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 specifically to the ANIMA ACP use case. Other use cases likely
have similar, but MAY have different requirements. have similar, but <bcp14>MAY</bcp14> have different, requirements.
</t> </t>
<section anchor="masarequirements" numbered="true" toc="default"> <section anchor="masarequirements" numbered="true" toc="default">
<name>MASA Operational Requirements</name> <name>MASA Operational Requirements</name>
<t> <t>
The manufacturer MUST arrange for an online service to be available The manufacturer <bcp14>MUST</bcp14> arrange for an online service c
called the MASA. It MUST be available at the URL which is encoded alled the MASA to be available. It <bcp14>MUST</bcp14> be available at the URL t
hat is encoded
in the IDevID certificate extensions described in <xref target="MASA URL" format="default"/>. in the IDevID certificate extensions described in <xref target="MASA URL" format="default"/>.
</t> </t>
<t> <t>
The online service MUST have access to a private key with which to The online service <bcp14>MUST</bcp14> have access to a private key
sign <xref target="RFC8366" format="default"/> format voucher artifa with which to
cts. The public sign voucher artifacts <xref target="RFC8366" format="default"/>. T
key, certificate, or certificate chain MUST be built in to the he public
key, certificate, or certificate chain <bcp14>MUST</bcp14> be built
into the
device as part of the firmware. device as part of the firmware.
</t> </t>
<t> <t>
It is RECOMMENDED that the manufacturer arrange for this signing It is <bcp14>RECOMMENDED</bcp14> that the manufacturer arrange for t his signing
key (or keys) to be escrowed according to typical software source key (or keys) to be escrowed according to typical software source
code escrow practices <xref target="softwareescrow" format="default" />. code escrow practices <xref target="softwareescrow" format="default" />.
</t> </t>
<t> <t>
The MASA accepts voucher requests from Domain Owners according to The MASA accepts voucher-requests from domain owners according to
an operational practice appropriate for the device. This can range an operational practice appropriate for the device. This can range
from any domain owner (first-come first-served, on a TOFU-like from any domain owner (first-come first-served, on a TOFU-like
basis), to full sales channel integration where Domain Owners need basis), to full sales channel integration where domain owners need
to be positively identified by TLS Client Certicate pinned, or HTTP to be positively identified by TLS pinned Client Certificates or an
Authentication process. The MASA creates signed voucher artifacts HTTP
authentication process. The MASA creates signed voucher artifacts
according to its internally defined policies. according to its internally defined policies.
</t> </t>
<t> <t>
The MASA MUST operate an audit log for devices that is accessible. The MASA <bcp14>MUST</bcp14> operate an audit-log for devices that i
The audit log is designed to be easily cacheable and the MASA MAY s accessible.
find it useful to put this content on a CDN. The audit-log is designed to be easily cacheable, and the MASA <bcp1
4>MAY</bcp14>
find it useful to put this content on a Content Delivery Network (CD
N).
</t> </t>
</section> </section>
<section anchor="domainownerrequirements" numbered="true" toc="default"> <section anchor="domainownerrequirements" numbered="true" toc="default">
<name>Domain Owner Operational Requirements</name> <name>Domain Owner Operational Requirements</name>
<t> <t>
The domain owner MUST operate an EST (<xref target="RFC7030" format= "default"/>) The domain owner <bcp14>MUST</bcp14> operate an EST <xref target="RF C7030" format="default"/>
server with the extensions described in this document. This is server with the extensions described in this document. This is
the JRC or Registrar. This JRC/EST the JRC or registrar. This JRC/EST
server MUST announce itself using GRASP within the ACP. This EST server <bcp14>MUST</bcp14> announce itself using GRASP within the AC
P. This EST
server will typically reside with the Network Operations Center for server will typically reside with the Network Operations Center for
the organization. the organization.
</t> </t>
<t> <t>
The domain owner MAY operate an internal certificate authority (CA) The domain owner <bcp14>MAY</bcp14> operate an internal CA that
that is separate from the EST server, or it <bcp14>MAY</bcp14> combine al
is seperate from the EST server, or it MAY combine all activities l activities
into a single device. The determination of the architecture into a single device. The determination of the architecture
depends upon the scale and resiliency requirements of the depends upon the scale and resiliency requirements of the
organization. Multiple JRC instances MAY be announced into the ACP organization. Multiple JRC instances <bcp14>MAY</bcp14> be announce d into the ACP
from multiple locations to achieve an appropriate level of from multiple locations to achieve an appropriate level of
redundancy. redundancy.
</t> </t>
<t> <t>
In order to recognize which devices and which manufacturers are In order to recognize which devices and which manufacturers are
welcome on the domain owner's network, the domain owner SHOULD welcome on the domain owner's network, the domain owner <bcp14>SHOUL
maintain a white list of manufacturers. This MAY extend to D</bcp14>
maintain an acceptlist of manufacturers. This <bcp14>MAY</bcp14> ex
tend to
integration with purchasing departments to know the serial numbers integration with purchasing departments to know the serial numbers
of devices. of devices.
</t> </t>
<t> <t>
The domain owner SHOULD use the resulting overlay ACP network to The domain owner <bcp14>SHOULD</bcp14> use the resulting overlay ACP network to
manage devices, replacing legacy out-of-band mechanisms. manage devices, replacing legacy out-of-band mechanisms.
</t> </t>
<t> <t>
The domain owner SHOULD operate one or more EST servers which can The domain owner <bcp14>SHOULD</bcp14> operate one or more EST serve
be used to renew the domain certificates (LDevIDs) which are rs that can
deployed to devices. These servers MAY be the same as the JRC, or be used to renew the domain certificates (LDevIDs), which are
MAY be a distinct set of devices, as approriate for resiliency. deployed to devices. These servers <bcp14>MAY</bcp14> be the same a
s the JRC or
<bcp14>MAY</bcp14> be a distinct set of devices, as appropriate for
resiliency.
</t> </t>
<t> <t>
The organization MUST take appropriate precautions against loss of The organization <bcp14>MUST</bcp14> take appropriate precautions ag
access to the certificate authority private key. Hardware security ainst loss of
access to the CA private key. Hardware security
modules and/or secret splitting are appropriate. modules and/or secret splitting are appropriate.
</t> </t>
</section> </section>
<section anchor="devicerequirements" numbered="true" toc="default"> <section anchor="devicerequirements" numbered="true" toc="default">
<name>Device Operational Requirements</name> <name>Device Operational Requirements</name>
<t> <t>
Devices MUST come with built-in trust anchors that permit the device to Devices <bcp14>MUST</bcp14> come with built-in trust anchors that pe rmit the device to
validate vouchers from the MASA. validate vouchers from the MASA.
</t> </t>
<t> <t>
Device MUST come with (unique, per-device) IDevID certificates that Devices <bcp14>MUST</bcp14> come with (unique, per-device) IDevID ce
include their serial numbers, and the MASA URL extension. rtificates that
include their serial numbers and the MASA URL extension.
</t> </t>
<t> <t>
Devices are expected to find Join Proxies using GRASP, and then conn ect Devices are expected to find Join Proxies using GRASP, and then conn ect
to the JRC using the protocol described in this document. to the JRC using the protocol described in this document.
</t> </t>
<t> <t>
Once a domain owner has been validated with the voucher, devices Once a domain owner has been validated with the voucher, devices
are expected to enroll into the domain using EST. Devices are then are expected to enroll into the domain using EST. Devices are then
expected to form ACPs using IPsec over IPv6 Link-Local addresses as expected to form ACPs using IPsec over IPv6 link-local addresses as
described in <xref target="I-D.ietf-anima-autonomic-control-plane" described in <xref target="RFC8994" format="default"/>.
format="default"/>.
</t> </t>
<t> <t>
Once a device has been enrolled it SHOULD listen for the address Once a device has been enrolled, it <bcp14>SHOULD</bcp14> listen for
of the JRC using GRASP, and it SHOULD enable itself as a Join the address
Proxy, and announce itself on all links/interfaces using GRASP DULL. of the JRC using GRASP, and it <bcp14>SHOULD</bcp14> enable itself a
s a Join
Proxy and announce itself on all links/interfaces using GRASP DULL.
</t> </t>
<t> <t>
Devices are expected to renew their certificates before they Devices are expected to renew their certificates before they
expire. expire.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="privacyconsiderations" numbered="true" toc="default"> <section anchor="privacyconsiderations" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>MASA audit log</name> <name>MASA Audit-Log</name>
<t> <t>
The MASA audit log includes the domainID for each The MASA audit-log includes the domainID for each
domain a voucher has been issued to. This information is closely domain a voucher has been issued to. This information is closely
related to the actual domain identity. A MASA may need additional related to the actual domain identity. A MASA may need additional
defenses against Denial of Service attacks (<xref target="dosmasa" forma t="default"/>), defenses against Denial-of-Service attacks (<xref target="dosmasa" forma t="default"/>),
and this may involve collecting additional (unspecified here) and this may involve collecting additional (unspecified here)
information. This could provide sufficient information for the MASA information. This could provide sufficient information for the MASA
service to build a detailed understanding the devices that have been service to build a detailed understanding of the devices that have been
provisioned within a domain. provisioned within a domain.
</t> </t>
<t> <t>
There are a number of design choices that mitigate this There are a number of design choices that mitigate this
risk. The domain can maintain some privacy since it has not necessarily risk. The domain can maintain some privacy since it has not necessarily
been authenticated and is not authoritatively bound to the supply been authenticated and is not authoritatively bound to the supply
chain. chain.
</t> </t>
<t> <t>
Additionally the domainID captures only the unauthenticated Additionally, the domainID captures only the unauthenticated
subject key identifier of the domain. A privacy sensitive domain could subject key identifier of the domain. A privacy-sensitive domain could
theoretically generate a new domainID for each device being theoretically generate a new domainID for each device being
deployed. Similarly a privacy sensitive domain would likely purchase deployed. Similarly, a privacy-sensitive domain would likely purchase
devices that support proximity assertions from a manufacturer that does devices that support proximity assertions from a manufacturer that does
not require sales channel integrations. This would result in a not require sales channel integrations. This would result in a
significant level of privacy while maintaining the security significant level of privacy while maintaining the security
characteristics provided by Registrar based audit log inspection. characteristics provided by the registrar-based audit-log inspection.
</t> </t>
</section> </section>
<section anchor="idevidregistrar" numbered="true" toc="default"> <section anchor="idevidregistrar" numbered="true" toc="default">
<name>What BRSKI-EST reveals</name> <name>What BRSKI-EST Reveals</name>
<t> <t>
During the provisional phase of the BRSKI-EST connection between During the provisional phase of the BRSKI-EST connection between
the Pledge and the Registrar, each party reveals its the pledge and the registrar, each party reveals its
certificates to each other. For the Pledge, this includes the certificates to each other. For the pledge, this includes the
serialNumber attribute, the MASA URL, and the identity that serialNumber attribute, the MASA URL, and the identity that
signed the IDevID certificate. signed the IDevID certificate.
</t> </t>
<t> <t>
TLS 1.2 reveals the certificate identities to on-path observers, TLS 1.2 reveals the certificate identities to on-path observers,
including the Join Proxy. including the Join Proxy.
</t> </t>
<t> <t>
TLS 1.3 reveals the certificate identities only to the end TLS 1.3 reveals the certificate identities only to the end
parties, but as the connection is provisional, an on-path parties, but as the connection is provisional; an on-path
attacker (MTIM) can see the certificates. This includes not just attacker (MITM) can see the certificates. This includes not just
malicious attackers, but also Registrars that are visible malicious attackers but also registrars that are visible
to the Pledge, but which are not part of the intended domain. to the pledge but are not part of the intended domain.
</t> </t>
<t> <t>
The certificate of the Registrar is rather arbitrary from the The certificate of the registrar is rather arbitrary from the
point of view of the BRSKI protocol. As no <xref target="RFC6125" fo point of view of the BRSKI protocol. As no
rmat="default"/> validations <xref target="RFC6125" format="default"/> are expected t
validations are expected to be done, the contents could be easily o be done, the contents could be easily
pseudonymized. Any device that can see a join proxy would be pseudonymized. Any device that can see a Join Proxy would be
able to connect to the Registrar and learn the identity of the able to connect to the registrar and learn the identity of the
network in question. Even if the contents of the certificate network in question. Even if the contents of the certificate
are pseudonymized, it would be possible to correlate different are pseudonymized, it would be possible to correlate different
connections in different locations belong to the same connections in different locations that belong to the same
entity. This is unlikely to present a significant privacy concern entity. This is unlikely to present a significant privacy concern
to ANIMA ACP uses of BRSKI, but may be a concern to other users to ANIMA ACP uses of BRSKI, but it may be a concern to other users
of BRSKI. of BRSKI.
</t> </t>
<t> <t>
The certificate of the Pledge could be revealed by a malicious The certificate of the pledge could be revealed by a malicious
Join Proxy that performed a MITM attack on the provisional TLS Join Proxy that performed a MITM attack on the provisional TLS
connection. Such an attacker would be able to reveal the connection. Such an attacker would be able to reveal the
identity of the Pledge to third parties if it chose to so. identity of the pledge to third parties if it chose to do so.
</t> </t>
<t> <t>
Research into a mechanism to do multi-step, multi-party authenticate Research into a mechanism to do multistep, multiparty authenticated
d key agreement, incorporating some kind of zero-knowledge proof,
key agreement, incorporating some kind of zero-knowledge proof
would be valuable. Such a mechanism would ideally avoid would be valuable. Such a mechanism would ideally avoid
disclosing identities until pledge, registrar and MASA agree to disclosing identities until the pledge, registrar, and MASA agree to
the transaction. Such a mechanism would need to discover the the transaction. Such a mechanism would need to discover the
location of the MASA without knowing the identity of the pledge, location of the MASA without knowing the identity of the pledge
or the identity of the MASA. This part of the problem may be unsolv or the identity of the MASA. This part of the problem may be unsolv
eable. able.
</t> </t>
</section> </section>
<section anchor="idevidprivacy" numbered="true" toc="default"> <section anchor="idevidprivacy" numbered="true" toc="default">
<name>What BRSKI-MASA reveals to the manufacturer</name> <name>What BRSKI-MASA Reveals to the Manufacturer</name>
<t> <t>
With consumer-oriented devices, the "call-home" mechanism in IoT With consumer-oriented devices, the "call-home" mechanism in IoT
devices raises significant privacy concerns. See devices raises significant privacy concerns. See
<xref target="livingwithIoT" format="default"/> and <xref target="Io <xref target="livingwithIoT" format="default"/> and <xref target="Io
TstrangeThings" format="default"/> for exemplars. The Autonomic Control TstrangeThings" format="default"/> for exemplars. The ACP usage of BRSKI is not
Plane (ACP) usage of BRSKI is not targeted at individual usage of targeted at individual usage of
IoT devices, but rather at the Enterprise and ISP creation of IoT devices but rather at the enterprise and ISP creation of
networks in a zero-touch fashion where the "call-home" represents networks in a zero-touch fashion where the "call-home" represents
a different class of privacy and lifecycle management concerns. a different class of privacy and life-cycle management concerns.
</t> </t>
<t> <t>
It needs to be re-iterated that the BRSKI-MASA mechanism It needs to be reiterated that the BRSKI-MASA mechanism
only occurs once during the commissioning of the device. It is only occurs once during the commissioning of the device. It is
well defined, and although encrypted with TLS, it could in theory well defined, and although encrypted with TLS, it could in theory
be made auditable as the contents are well defined. be made auditable as the contents are well defined.
This connection does not occur when the device powers on or is This connection does not occur when the device powers on or is
restarted for normal routines. restarted for normal routines.
(It is conceivable, but remarkably unusual, that a device could (It is conceivable, but remarkably unusual, that a device could
be forced to go through a full factory reset during an exceptional f irmware update be forced to go through a full factory reset during an exceptional f irmware update
situation, after which enrollment would have be repeated, and a situation, after which enrollment would have to be repeated, and a
new connection would occur) new connection would occur.)
</t> </t>
<t> <t>
The BRSKI call-home mechanism is mediated via the owner's The BRSKI call-home mechanism is mediated via the owner's
Registrar, and the information that is transmitted is directly registrar, and the information that is transmitted is directly
auditable by the device owner. This is in stark contrast to auditable by the device owner. This is in stark contrast to
many "call-home" protocols where the device autonomously calls many "call-home" protocols where the device autonomously calls
home and uses an undocumented protocol. home and uses an undocumented protocol.
</t> </t>
<t> <t>
While the contents of the signed part of the pledge voucher request While the contents of the signed part of the pledge voucher-request
can not be changed, they are not encrypted at the registrar. cannot be changed, they are not encrypted at the registrar.
The ability to audit the messages by the owner of the network The ability to audit the messages by the owner of the network
is a mechanism to defend against exfiltration of data by a nefarious is a mechanism to defend against exfiltration of data by a nefarious
pledge. Both are, to re-iterate, encrypted by TLS while in transit. pledge. Both are, to reiterate, encrypted by TLS while in transit.
</t> </t>
<t> <t>
The BRSKI-MASA exchange reveals the following information to the The BRSKI-MASA exchange reveals the following information to the
manufacturer: manufacturer:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
the identity of the device being enrolled. This is revealed the identity of the device being enrolled. This is revealed
by transmission of a signed voucher-request containing the by transmission of a signed voucher-request containing the
serial-number. The manufacturer can usually link the serial serial-number. The manufacturer can usually link the serial
number to a device model. number to a device model.
</li> </li>
<li> <li>
an identity of the domain owner in the form of the domain an identity of the domain owner in the form of the domain
trust anchor. However, this is not a global PKI anchored trust anchor. However, this is not a global PKI-anchored
name within the WebPKI, so this identity could be name within the WebPKI, so this identity could be
pseudonymous. If there is sales channel integration, then pseudonymous. If there is sales channel integration, then
the MASA will have authenticated the domain owner, either via the MASA will have authenticated the domain owner, via either
pinned certificate, or perhaps another HTTP authentication a pinned certificate or perhaps another HTTP authentication
method, as per <xref target="MASAauthenticationOfRegistrar" form at="default"/>. method, as per <xref target="MASAauthenticationOfRegistrar" form at="default"/>.
</li> </li>
<li> <li>
the time the device is activated, the time the device is activated.
</li> </li>
<li> <li>
the IP address of the domain Owner's Registrar. the IP address of the domain owner's registrar.
For ISPs and Enterprises, the IP address provides very clear For ISPs and enterprises, the IP address provides very clear
geolocation of the owner. No amount of IP address privacy geolocation of the owner. No amount of IP address privacy
extensions (<xref target="RFC4941" format="default"/>) can do an ything about extensions <xref target="RFC8981" format="default"/> can do anyt hing about
this, as a simple whois lookup likely identifies the ISP or this, as a simple whois lookup likely identifies the ISP or
Enterprise from the upper bits anyway. A passive attacker enterprise from the upper bits anyway. A passive attacker
who observes the connection definitely may conclude that the who observes the connection definitely may conclude that the
given enterprise/ISP is a customer of the particular given enterprise/ISP is a customer of the particular
equipment vendor. The precise model that is being enrolled equipment vendor. The precise model that is being enrolled
will remain private. will remain private.
</li> </li>
</ul> </ul>
<t> <t>
Based upon the above information, the manufacturer is able to Based upon the above information, the manufacturer is able to
track a specific device from pseudonymous domain identity to the track a specific device from pseudonymous domain identity to the
next pseudonymous domain identity. If there is sales-channel next pseudonymous domain identity. If there is sales-channel
integration, then the identities are not pseudonymous. integration, then the identities are not pseudonymous.
</t> </t>
<t> <t>
The manufacturer knows the IP address of the Registrar, but it The manufacturer knows the IP address of the registrar, but it
can not see the IP address of the device itself. The cannot see the IP address of the device itself. The
manufacturer can not track the device to a detailed physical manufacturer cannot track the device to a detailed physical
or network location, only to the location of the Registrar. or network location, only to the location of the registrar.
That is likely to be at the Enterprise or ISPs headquarters. That is likely to be at the enterprise or ISP's headquarters.
</t> </t>
<t> <t>
The above situation is to be distinguished from a The above situation is to be distinguished from a
residential/individual person who registers a device from a residential/individual person who registers a device from a
manufacturer. Individuals do not tend to have multiple offices, manufacturer. Individuals do not tend to have multiple offices,
and their registrar is likely on the same network as the device. and their registrar is likely on the same network as the device.
A manufacturer that sells switching/routing products to enterprises A manufacturer that sells switching/routing products to enterprises
should hardly be surprised if additional purchases should hardly be surprised if additional purchases of
switching/routing products are made. switching/routing products are made.
Deviations from a historical trend or Deviations from a historical trend or
an establish baseline would, however, be notable. an established baseline would, however, be notable.
</t> </t>
<t> <t>
The situation is not improved by the enterprise/ISP using The situation is not improved by the enterprise/ISP using
anonymization services such as anonymization services such as Tor <xref target="Dingledine" format=
<xref target="Dingledine2004" format="default">ToR</xref>, as a TLS "default"/>, as a TLS 1.2 connection
1.2 connection
will reveal the ClientCertificate used, clearly identifying will reveal the ClientCertificate used, clearly identifying
the enterprise/ISP involved. TLS 1.3 is better in this regard, the enterprise/ISP involved. TLS 1.3 is better in this regard,
but an active attacker can still discover the parties involved by but an active attacker can still discover the parties involved by
performing a Man-In-The-Middle-Attack on the first attempt performing a MITM attack on the first attempt
(breaking/killing it with a TCP RST), and then letting subsequent (breaking/killing it with a TCP reset (RST)), and then letting subse
quent
connection pass through. connection pass through.
</t> </t>
<t> <t>
A manufacturer could attempt to mix the BRSKI-MASA traffic in A manufacturer could attempt to mix the BRSKI-MASA traffic in
with general traffic their site by hosting the MASA behind the with general traffic on their site by hosting the MASA behind the
same (set) of load balancers that the companies normal marketing same (set) of load balancers that the company's normal marketing
site is hosted behind. This makes lots of sense from a straight site is hosted behind. This makes a lot of sense from a straight
capacity planning point of view as the same set of services capacity planning point of view as the same set of services
(and the same set of Distributed Denial of Service mitigations) (and the same set of Distributed Denial-of-Service mitigations)
may be used. Unfortunately, as the BRSKI-MASA connections may be used. Unfortunately, as the BRSKI-MASA connections
include TLS ClientCertificate exchanges, this may easily be include TLS ClientCertificate exchanges, this may easily be
observed in TLS 1.2, and a traffic analysis may reveal it even in 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 TLS 1.3. This does not make such a plan irrelevant. There may
be other organizational reasons to keep the marketing site (which be other organizational reasons to keep the marketing site (which
is often subject to frequent re-designs, outsourcing, etc.) is often subject to frequent redesigns, outsourcing, etc.)
separate from the MASA, which may need to operate reliably for separate from the MASA, which may need to operate reliably for
decades. decades.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Manufacturers and Used or Stolen Equipment</name> <name>Manufacturers and Used or Stolen Equipment</name>
<t> <t>
As explained above, the manufacturer receives information each As explained above, the manufacturer receives information each
time that a device which is in factory-default mode does a time a device that is in factory-default mode does a
zero-touch bootstrap, and attempts to enroll into a domain zero-touch bootstrap and attempts to enroll into a domain
owner's registrar. owner's registrar.
</t> </t>
<t> <t>
The manufacturer is therefore in a position to decline to The manufacturer is therefore in a position to decline to
issue a voucher if it detects that the new owner is not the issue a voucher if it detects that the new owner is not the
same as the previous owner. same as the previous owner.
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
This can be seen as a feature if the equipment is believed to This can be seen as a feature if the equipment is believed to
have been stolen. If the legitimate owner notifies the have been stolen. If the legitimate owner notifies the
manufacturer of the theft, then when the new owner brings the manufacturer of the theft, then when the new owner brings the
device up, if they use the zero-touch mechanism, the new device up, if they use the zero-touch mechanism, the new
(illegitimate) owner reveals their location and identity. (illegitimate) owner reveals their location and identity.
</li> </li>
<li> <li>
In the case of Used equipment, the initial owner could inform In the case of used equipment, the initial owner could inform
the manufacturer of the sale, or the manufacturer may just the manufacturer of the sale, or the manufacturer may just
permit resales unless told otherwise. In which case, the permit resales unless told otherwise. In which case, the
transfer of ownership simply occurs. transfer of ownership simply occurs.
</li> </li>
<li> <li>
A manufacturer could however decide not to issue a new A manufacturer could, however, decide not to issue a new
voucher in response to a transfer of ownership. voucher in response to a transfer of ownership.
This is essentially the same as the stolen case, with the This is essentially the same as the stolen case, with the
manufacturer having decided that the sale was not legitimate. manufacturer having decided that the sale was not legitimate.
</li> </li>
<li> <li>
There is a fourth case, if the manufacturer is providing There is a fourth case, if the manufacturer is providing
protection against stolen devices. The manufacturer then protection against stolen devices. The manufacturer then
has a responsibility to protect the legitimate owner against has a responsibility to protect the legitimate owner against
fraudulent claims that the equipment was stolen. fraudulent claims that the equipment was stolen.
In the absence of such manufacturer protection, In the absence of such manufacturer protection,
such a claim would cause the manufacturer to refuse such a claim would cause the manufacturer to refuse
to issue a new voucher. Should the device go through to issue a new voucher. Should the device go through
a deep factory reset (for instance, replacement of a damaged a deep factory reset (for instance, replacement of a damaged
main board component, the device would not bootstrap. main board component), the device would not bootstrap.
</li> </li>
<li> <li>
Finally, there is a fifth case: the manufacturer has decided to Finally, there is a fifth case: the manufacturer has decided to
end-of-line the device, or the owner has not paid a yearly end-of-line the device, or the owner has not paid a yearly
support amount, and the manufacturer refuses to issue new support amount, and the manufacturer refuses to issue new
vouchers at that point. This last case is not new to the vouchers at that point. This last case is not new to the
industry: many license systems are already deployed that have industry: many license systems are already deployed that have
significantly worse effect. a significantly worse effect.
</li> </li>
</ol> </ol>
<t> <t>
This section has outlined five situations in which a manufacturer This section has outlined five situations in which a manufacturer
could use the voucher system to enforce what are clearly could use the voucher system to enforce what are clearly
license terms. license terms.
A manufacturer that attempted to A manufacturer that attempted to
enforce license terms via vouchers would find it rather enforce license terms via vouchers would find it rather
ineffective as the terms would only be enforced when the device ineffective as the terms would only be enforced when the device
is enrolled, and this is not (to repeat), a daily or even monthly is enrolled, and this is not (to repeat) a daily or even monthly
occurrence. occurrence.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Manufacturers and Grey market equipment</name> <name>Manufacturers and Grey Market Equipment</name>
<t> <t>
Manufacturers of devices often sell different products into Manufacturers of devices often sell different products into
different regional markets. Which product is available in which different regional markets. Which product is available in which
market can be driven by price differentials, support issues (some market can be driven by price differentials, support issues (some
markets may require manuals and tech-support to be done in the markets may require manuals and tech support to be done in the
local language), government export regulation (such as whether local language), and government export regulation (such as whether
strong crypto is permitted to be exported, or permitted to be strong crypto is permitted to be exported or permitted to be
used in a particular market). When an domain owner obtains a used in a particular market). When a domain owner obtains a
device from a different market (they can be new) and transfers it device from a different market (they can be new) and transfers it
to a different location, this is called a Grey Market. to a different location, this is called a Grey Market.
</t> </t>
<t> <t>
A manufacturer could decide not to issue a voucher to an A manufacturer could decide not to issue a voucher to an
enterprise/ISP based upon their location. There are a number of enterprise/ISP based upon their location. There are a number of
ways which this could be determined: from the geolocation of the ways that this could be determined: from the geolocation of the
registrar, from sales channel knowledge about the customer, and registrar, from sales channel knowledge about the customer, and
what products are (un-)available in that market. If the device from what products are available or unavailable in that market. If
has a GPS the coordinates of the device could even be placed into the device
has a GPS, the coordinates of the device could even be placed into
an extension of the voucher. an extension of the voucher.
</t> </t>
<t> <t>
The above actions are not illegal, and not new. Many The above actions are not illegal, and not new. Many
manufacturers have shipped crypto-weak (exportable) versions of manufacturers have shipped crypto-weak (exportable) versions of
firmware as the default on equipment for decades. The first task firmware as the default on equipment for decades. The first task
of an enterprise/ISP has always been to login to a manufacturer of an enterprise/ISP has always been to login to a manufacturer
system, show one's "entitlement" (country information, proof that system, show one's "entitlement" (country information, proof that
support payments have been made), and receive either a new support payments have been made), and receive either a new
updated firmware, or a license key that will activate the correct updated firmware or a license key that will activate the correct
firmware. firmware.
</t> </t>
<t> <t>
BRSKI permits the above process to automated (in an autonomic BRSKI permits the above process to be automated (in an autonomic
fashion), and therefore perhaps encourages this kind of fashion) and therefore perhaps encourages this kind of
differentiation by reducing the cost of doing it. differentiation by reducing the cost of doing it.
</t> </t>
<t> <t>
An issue that manufacturers will need to deal with in the above An issue that manufacturers will need to deal with in the above
automated process is when a device is shipped to one country automated process is when a device is shipped to one country
with one set of rules (or laws or entitlements), but the domain with one set of rules (or laws or entitlements), but the domain
registry is in another one. Which rules apply is something registry is in another one. Which rules apply is something
will have to be worked out: the manufacturer could come to that will have to be worked out: the manufacturer could
believe they are dealing with Grey market equipment, when it believe they are dealing with Grey Market equipment when they
is simply dealing with a global enterprise. are simply dealing with a global enterprise.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Some mitigations for meddling by manufacturers</name> <name>Some Mitigations for Meddling by Manufacturers</name>
<t> <t>
The most obvious mitigation is not to buy the product. The most obvious mitigation is not to buy the product.
Pick manufacturers that are up-front about their policies, who do Pick manufacturers that are up front about their policies and who do
not change them gratuitously. not change them gratuitously.
</t> </t>
<t> <t>
<xref target="masasecurityreduction_newanchor" format="default"/> <xref target="masasecurityreduction_newanchor" format="default"/>
describes some ways in which a manufacturer could provide a describes some ways in which a manufacturer could provide a
mechanism to manage the trust mechanism to manage the trust
anchors and built-in certificates (IDevID) as an extension. anchors and built-in certificates (IDevID) as an extension.
There are a variety of mechanism, and some may take a substantial There are a variety of mechanisms, and some may take a substantial
amount of work to get exactly correct. These mechanisms do amount of work to get exactly correct. These mechanisms do
not change the flow of the protocol described here, but rather not change the flow of the protocol described here but rather
allow the starting trust assumptions to be changed. allow the starting trust assumptions to be changed.
This is an area for This is an area for
future standardization work. future standardization work.
</t> </t>
<t> <t>
Replacement of the voucher validation anchors (usually pointing Replacement of the voucher validation anchors (usually pointing
to the original manufacturer's MASA) with those of the new to the original manufacturer's MASA) with those of the new
owner permits the new owner to issue vouchers to subsequent owner permits the new owner to issue vouchers to subsequent
owners. This would be done by having the selling (old) owner owners. This would be done by having the selling (old) owner
to run a MASA. run a MASA.
</t> </t>
<t> <t>
The BRSKI protocol depends upon a trust anchor on the device The BRSKI protocol depends upon a trust anchor
and an identity on the device. Management of these and an identity on the device. Management of these
entities facilitates a few new operational modes without entities facilitates a few new operational modes without
making any changes to the BRSKI protocol. Those modes include: making any changes to the BRSKI protocol. Those modes include:
offline modes where the domain owner operates an internal offline modes where the domain owner operates an internal
MASA for all devices, resell modes where the first domain owner MASA for all devices, resell modes where the first domain owner
becomes the MASA for the next (resold-to) domain owner, becomes the MASA for the next (resold-to) domain owner,
and services where an aggregator acquires a large variety and services where an aggregator acquires a large variety
of devices, and then acts as a pseudonymized MASA for a variety of devices and then acts as a pseudonymized MASA for a variety
of devices from a variety of manufacturers. of devices from a variety of manufacturers.
</t> </t>
<t> <t>
Although replacement of the IDevID is not required for all Although replacement of the IDevID is not required for all
modes described above, a manufacturers could support such a modes described above, a manufacturer could support such a
thing. Some may wish to consider replacement of the IDevID thing. Some may wish to consider replacement of the IDevID
as an indication that the device's warrantee is terminated. as an indication that the device's warranty is terminated.
For others, the privacy requirements of some deployments might For others, the privacy requirements of some deployments might
consider this a standard operating practice. consider this a standard operating practice.
</t> </t>
<t> <t>
As discussed at the end of <xref target="MASAauditlog" format="defau lt"/>, As discussed at the end of <xref target="MASAauditlog" format="defau lt"/>,
new work could be done to use a new work could be done to use a
distributed consensus technology for the audit log. distributed consensus technology for the audit-log.
This would permit the audit log to continue to be useful, This would permit the audit-log to continue to be useful,
even when there is a chain of MASA due to changes of ownership. even when there is a chain of MASA due to changes of ownership.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Death of a manufacturer</name> <name>Death of a Manufacturer</name>
<t> <t>
A common concern has been that a manufacturer could go out of A common concern has been that a manufacturer could go out of
business, leaving owners of devices unable to get new vouchers business, leaving owners of devices unable to get new vouchers
for existing products. Said products might have been previously for existing products. Said products might have been previously
deployed, but need to be re-initialized, they might have been deployed but need to be reinitialized, used, or kept in a warehouse
purchased used, or they might have kept in a warehouse as as
long-term spares. long-term spares.
</t> </t>
<t> <t>
The MASA was named the Manufacturer *Authorized* Signing The MASA was named the Manufacturer *Authorized* Signing
Authority to emphasize that it need not be the manufacturer Authority to emphasize that it need not be the manufacturer
itself that performs this. It is anticipated that specialist itself that performs this. It is anticipated that
service providers will come to exist that deal with the creation specialist service providers will come to exist that deal with the c
reation
of vouchers in much the same way that many companies have of vouchers in much the same way that many companies have
outsourced email, advertising and janitorial services. outsourced email, advertising, and janitorial services.
</t> </t>
<t> <t>
Further, it is expected that as part of any service agreement Further, it is expected that as part of any service agreement,
that the manufacturer would arrange to escrow appropriate private the manufacturer would arrange to escrow appropriate private
keys such that a MASA service could be provided by a third keys such that a MASA service could be provided by a third
party. This has routinely been done for source code for decades. party. This has routinely been done for source code for decades.
</t> </t>
</section> </section>
</section> </section>
<section anchor="securityconsiderations" numbered="true" toc="default"> <section anchor="securityconsiderations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This document details a protocol for bootstrapping that balances This document details a protocol for bootstrapping that balances
operational concerns against security concerns. As detailed in the intro duction, operational concerns against security concerns. As detailed in the intro duction,
and touched on again in <xref target="reducedsecuritymodes" format="defa ult"/>, and touched on again in <xref target="reducedsecuritymodes" format="defa ult"/>,
the protocol allows for reduced security modes. the protocol allows for reduced security modes.
These attempt to deliver additional These attempt to deliver additional
control to the local administrator and owner in cases where control to the local administrator and owner in cases where
less security provides operational benefits. This less security provides operational benefits. This
section goes into more detail about a variety of specific section goes into more detail about a variety of specific
considerations. considerations.
</t> </t>
<t> <t>
To facilitate logging and administrative oversight, in addition To facilitate logging and administrative oversight, in addition
to triggering Registrar verification of MASA logs, the pledge reports to triggering registrar verification of MASA logs, the pledge reports
on voucher parsing status to the registrar. In the case of a on the voucher parsing status to the registrar. In the case of a
failure, this information is informative to a potentially malicious failure, this information is informative to a potentially malicious
registrar. This is mandated anyway because of the operational registrar. This is mandated anyway because of the operational
benefits of an informed administrator in cases where the failure is benefits of an informed administrator in cases where the failure is
indicative of a problem. The registrar is RECOMMENDED to verify MASA logs indicative of a problem. The registrar is <bcp14>RECOMMENDED</bcp14> to ve rify MASA logs
if voucher status telemetry is not received.</t> if voucher status telemetry is not received.</t>
<t>To facilitate truly limited clients EST RFC7030 section 3.3.2
requirements that the client MUST support a client authentication model <t>To facilitate truly limited clients, EST
have been reduced in <xref target="reducedsecuritymodes" format="default"/ requires that the client <bcp14>MUST</bcp14> support a client authenticati
> to a on model (see <xref target="RFC7030" sectionFormat="comma" section="3.3.2"/>);
statement that the registrar "MAY" choose to accept devices <xref target="reducedsecuritymodes" format="default"/> updates these requi
rements by stating that the registrar <bcp14>MAY</bcp14> choose to accept device
s
that fail cryptographic authentication. This reflects that fail cryptographic authentication. This reflects
current (poor) practices in shipping devices without a cryptographic current (poor) practices in shipping devices without a cryptographic
identity that are NOT RECOMMENDED.</t> identity that are <bcp14>NOT RECOMMENDED</bcp14>.</t>
<t>During the provisional period of the connection the pledge MUST treat a
ll HTTP header and <t>During the provisional period of the connection, the pledge <bcp14>MUST
</bcp14> treat all HTTP header and
content data as untrusted data. HTTP libraries are content data as untrusted data. HTTP libraries are
regularly exposed to non-secured HTTP traffic: mature libraries regularly exposed to non-secured HTTP traffic: mature libraries
should not have any problems. should not have any problems.
</t> </t>
<t>Pledges might chose to engage in protocol operations with <t>Pledges might chose to engage in protocol operations with
multiple discovered registrars in parallel. As noted above they multiple discovered registrars in parallel. As noted above, they
will only do so with distinct nonce values, but the end result will only do so with distinct nonce values, but the end result
could be multiple vouchers issued from the MASA if all registrars could be multiple vouchers issued from the MASA if all registrars
attempt to claim the device. This is not a failure and the pledge attempt to claim the device. This is not a failure, and the pledge
choses whichever voucher to accept based on internal logic. The chooses whichever voucher to accept based on internal logic. The
registrars verifying log information will see multiple entries registrars verifying log information will see multiple entries
and take this into account for their analytics purposes.</t> and take this into account for their analytic purposes.</t>
<section anchor="dosmasa" numbered="true" toc="default"> <section anchor="dosmasa" numbered="true" toc="default">
<name>Denial of Service (DoS) against MASA</name> <name>Denial of Service (DoS) against MASA</name>
<t>There are uses cases where the MASA could be unavailable or <t>There are use cases where the MASA could be unavailable or
uncooperative to the Registrar. They include active DoS attacks, planned uncooperative to the registrar. They include active DoS attacks, planned
and unplanned and unplanned
network partitions, changes to MASA policy, or other instances where network partitions, changes to MASA policy, or other instances where
MASA policy rejects a claim. These introduce an operational risk to the MASA policy rejects a claim. These introduce an operational risk to the
Registrar owner in that MASA behavior might limit the ability to registrar owner in that MASA behavior might limit the ability to
bootstrap a pledge device. For example this might be an issue during bootstrap a pledge device. For example, this might be an issue during
disaster recovery. This risk can be mitigated by Registrars that disaster recovery. This risk can be mitigated by registrars that
request and maintain long term copies of "nonceless" vouchers. In request and maintain long-term copies of "nonceless" vouchers. In
that way they are guaranteed to be able to bootstrap their devices.</t> that way, they are guaranteed to be able to bootstrap their devices.</t>
<t>The issuance of nonceless vouchers themselves creates a security <t>The issuance of nonceless vouchers themselves creates a security
concern. If the Registrar of a previous domain can intercept protocol concern. If the registrar of a previous domain can intercept protocol
communications then it can use a previously issued nonceless voucher to communications, then it can use a previously issued nonceless voucher to
establish management control of a pledge device even after having sold establish management control of a pledge device even after having sold
it. This risk is mitigated by recording the issuance of such vouchers it. This risk is mitigated by recording the issuance of such vouchers
in the MASA audit log that is verified by the subsequent Registrar in the MASA audit-log that is verified by the subsequent registrar
and by Pledges only bootstrapping when in a factory default state. This and by pledges only bootstrapping when in a factory default state. This
reflects a balance between enabling MASA independence during reflects a balance between enabling MASA independence during
future bootstrapping and the security of bootstrapping itself. future bootstrapping and the security of bootstrapping itself.
Registrar control over requesting and auditing nonceless vouchers Registrar control over requesting and auditing nonceless vouchers
allows device owners to choose an appropriate balance.</t> allows device owners to choose an appropriate balance.</t>
<t>The MASA is exposed to DoS attacks wherein attackers claim <t>The MASA is exposed to DoS attacks wherein attackers claim
an unbounded number of devices. Ensuring a registrar is an unbounded number of devices. Ensuring a registrar is
representative of a valid manufacturer customer, even without validating representative of a valid manufacturer customer, even without validating
ownership of specific pledge devices, helps to mitigate this. Pledge ownership of specific pledge devices, helps to mitigate this. Pledge
signatures on the pledge voucher-request, as forwarded by the signatures on the pledge voucher-request, as forwarded by the
registrar in the prior-signed-voucher-request field of the registrar vou cher-request, significantly registrar in the prior-signed-voucher-request field of the registrar vou cher-request, significantly
reduce this risk by ensuring the MASA can confirm proximity reduce this risk by ensuring the MASA can confirm proximity
between the pledge and the registrar making the request. Supply between the pledge and the registrar making the request. Supply-chain
chain integration ("know your customer") is an additional integration ("know your customer") is an additional
step that MASA providers and device vendors can explore.</t> step that MASA providers and device vendors can explore.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DomainID must be resistant to second-preimage attacks</name> <name>DomainID Must Be Resistant to Second-Preimage Attacks</name>
<t> <t>
The domainID is used as the reference in the audit log to the The domainID is used as the reference in the audit-log to the
domain. The domainID is expected to be calculated by a hash that domain. The domainID is expected to be calculated by a hash that
is resistant to a second-preimage attack. is resistant to a second-preimage attack.
Such an attack would allow a second registrar to create audit log Such an attack would allow a second registrar to create audit-log
entries that are fake. entries that are fake.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Availability of good random numbers</name> <name>Availability of Good Random Numbers</name>
<t> <t>
The nonce used by the Pledge in the voucher-request SHOULD be The nonce used by the pledge in the voucher-request <bcp14>SHOULD</bcp
generated by a Strong Cryptographic Sequence (<xref target="RFC4086" f 14> be
ormat="default"/> section 6.2). TLS has a similar requirement. generated by a Strong Cryptographic Sequence (<xref target="RFC4086"
sectionFormat="comma" section="6.2"/>). TLS has a similar requirement.
</t> </t>
<t> <t>
In particular implementations should pay attention to the advance In particular, implementations should pay attention to the advance
in <xref target="RFC4086" format="default"/> section 3, particularly s in <xref target="RFC4086" format="default"/>; see Sections <xref targ
ection 3.4. et="RFC4086" sectionFormat="bare" section="3"/> and, in particular,
The random seed used by a device at boot MUST be <xref target="RFC4086" sectionFormat="bare" section="3.4"/>.
The random seed used by a device at boot <bcp14>MUST</bcp14> be
unique across all devices and all bootstraps. Resetting a device to unique across all devices and all bootstraps. Resetting a device to
factory default state does not obviate this requirement. factory default state does not obviate this requirement.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Freshness in Voucher-Requests</name> <name>Freshness in Voucher-Requests</name>
<t> <t>
A concern has been raised that the pledge voucher-request should conta in some content (a nonce) provided by the registrar and/or MASA A concern has been raised that the pledge voucher-request should conta in 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. in order for those actors to verify that the pledge voucher-request is fresh.
</t> </t>
skipping to change at line 4389 skipping to change at line 4563
from the MASA to the pledge. It is somewhat easier to collect a 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 random value from the registrar, but as the registrar is not yet
vouched for, such a registrar nonce has little value. vouched for, such a registrar nonce has little value.
There are privacy and logistical challenges to addressing these There are privacy and logistical challenges to addressing these
operational issues, so if operational issues, so if
such a thing were to be considered, it would have to provide some such a thing were to be considered, it would have to provide some
clear value. This section examines the impacts of not having a clear value. This section examines the impacts of not having a
fresh pledge voucher-request. fresh pledge voucher-request.
</t> </t>
<t> <t>
Because the registrar authenticates the pledge, a full Man-in-the-Midd le Because the registrar authenticates the pledge, a full MITM
attack is not possible, despite the provisional TLS authentication attack is not possible, despite the provisional TLS authentication
by the pledge (see <xref target="ProtocolDetails" format="default"/>.) by the pledge (see <xref target="ProtocolDetails" format="default"/>.)
Instead we examine the case of a fake registrar (Rm) Instead, we examine the case of a fake registrar (Rm)
that communicates with the pledge in parallel or in close time proximi that communicates with the pledge in parallel or in close-time proximi
ty ty
with the intended registrar. (This scenario is intentionally supported as with the intended registrar. (This scenario is intentionally supported as
described in <xref target="discovery" format="default"/>.) described in <xref target="discovery" format="default"/>.)
</t> </t>
<t> <t>
The fake registrar (Rm) can obtain a voucher signed by the MASA The fake registrar (Rm) can obtain a voucher signed by the MASA
either directly or through arbitrary intermediaries. either directly or through arbitrary intermediaries.
Assuming that the MASA accepts the registrar voucher-request (either b Assuming that the MASA accepts the registrar voucher-request (because
ecause either the Rm is collaborating with a legitimate registrar according t
Rm is collaborating with a legitimate registrar according to supply ch o supply-chain
ain information or the MASA is in audit-log only mode), then
information, or because the MASA is in audit-log only mode), then
a voucher linking the pledge to the registrar Rm is issued. a voucher linking the pledge to the registrar Rm is issued.
</t> </t>
<t> <t>
Such a voucher, when passed back to the pledge, would link the Such a voucher, when passed back to the pledge, would link the
pledge to registrar Rm, and would permit the pledge to pledge to registrar Rm and permit the pledge to
end the provisional state. It now trusts Rm and, if it has any end the provisional state. It now trusts the Rm and, if it has any
security vulnerabilities leveragable by an Rm with full security vulnerabilities leverageable by an Rm with full
administrative control, can be assumed to be a administrative control, can be assumed to be a
threat against the intended registrar. threat against the intended registrar.
</t> </t>
<t> <t>
This flow is mitigated by the intended registrar verifying the audit This flow is mitigated by the intended registrar verifying the audit-l
logs available from the MASA as described in ogs
<xref target="authzLogRequest" format="default"/>. Rm might chose to c available from the MASA as described in
ollect <xref target="authzLogRequest" format="default"/>. The Rm might chose
a voucher-request but wait until after the intended registrar complete to collect
s the authorization process before submitting it. This pledge voucher-request wo a voucher-request but wait until after the intended registrar complete
uld be 'stale' in that it has a nonce that no longer matches the internal state s the authorization process before submitting it. This pledge voucher-request wo
of the pledge. In order to successfully use any resulting voucher the Rm would n uld be "stale" in that it has a nonce that no longer matches the internal state
eed to remove the stale nonce or anticipate the pledge's future nonce state. Red of the pledge. In order to successfully use any resulting voucher, the Rm would
ucing the possibility of this is why the pledge is mandated to generate a strong need to remove the stale nonce or anticipate the pledge's future nonce state. Re
random or pseudo-random number nonce.</t> ducing the possibility of this is why the pledge is mandated to generate a stron
g random or pseudo-random number nonce.</t>
<t> <t>
Additionally, in order to successfully use the resulting voucher the R Additionally, in order to successfully use the resulting voucher, the
m Rm
would have to attack the pledge and return it to a bootstrapping would have to attack the pledge and return it to a bootstrapping-enabl
enabled state. This would require wiping the pledge of current ed
configuration and triggering a re-bootstrapping of the pledge. state. This would require wiping the pledge of current
configuration and triggering a rebootstrapping of the pledge.
This is no more likely than simply taking control of the pledge This is no more likely than simply taking control of the pledge
directly but if this is a consideration the target network is directly, but if this is a consideration, it is
RECOMMENDED to take the following steps: <bcp14>RECOMMENDED</bcp14> that the target network take the following
steps:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Ongoing network monitoring for unexpected bootstrapping attempts b y pledges.</li> <li>Ongoing network monitoring for unexpected bootstrapping attempts b y pledges.</li>
<li>Retrieval and examination of MASA log information upon the occurre nce <li>Retrieval and examination of MASA log information upon the occurre nce
of any such unexpected events. Rm will be listed in the logs along with nonce information for analysis.</li> of any such unexpected events. The Rm will be listed in the logs a long with nonce information for analysis.</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Trusting manufacturers</name> <name>Trusting Manufacturers</name>
<t> <t>
The BRSKI extensions to EST permit a new pledge to be completely The BRSKI extensions to EST permit a new pledge to be completely
configured with domain specific trust anchors. The link from configured with domain-specific trust anchors. The link from
built-in manufacturer-provided trust anchors to domain-specific built-in manufacturer-provided trust anchors to domain-specific
trust anchors is mediated by the signed voucher artifact. trust anchors is mediated by the signed voucher artifact.
</t> </t>
<t> <t>
If the manufacturer's IDevID signing key is not properly validated, If the manufacturer's IDevID signing key is not properly validated,
then there is a risk that the network will accept a pledge that 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 should not be a member of the network. As the address of the
manufacturer's MASA is provided in the IDevID using the extension manufacturer's MASA is provided in the IDevID using the extension
from <xref target="IDevIDextension" format="default"/>, the malicious pledge will have no problem from <xref target="IDevIDextension" format="default"/>, the malicious pledge will have no problem
collaborating with it's MASA to produce a completely valid voucher. collaborating with its MASA to produce a completely valid voucher.
</t> </t>
<t> <t>
BRSKI does not, however, fundamentally change the trust model from BRSKI does not, however, fundamentally change the trust model from
domain owner to manufacturer. Assuming that the pledge used domain owner to manufacturer. Assuming that the pledge used
its IDevID with RFC7030 EST and BRSKI, the domain (registrar) still ne its IDevID with EST <xref target="RFC7030"/> and BRSKI, the domain
eds to (registrar) still needs to trust the manufacturer.
trust the manufacturer.
</t> </t>
<t> <t>
Establishing this trust between domain and manufacturer is outside Establishing this trust between domain and manufacturer is outside
the scope of BRSKI. There are a number of mechanisms that can the scope of BRSKI. There are a number of mechanisms that can be
adopted including: adopted including:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Manually configuring each manufacturer's trust anchor. Manually configuring each manufacturer's trust anchor.
</li> </li>
<li> <li>
A Trust-On-First-Use (TOFU) mechanism. A human would be queried up on A TOFU mechanism. A human would be queried upon
seeing a manufacturer's trust anchor for the first time, and seeing a manufacturer's trust anchor for the first time, and
then the trust anchor would be installed to the trusted store. then the trust anchor would be installed to the trusted store.
There are risks with this; even if the key to name mapping is vali dated There are risks with this; even if the key to name mapping is vali dated
using something like the WebPKI, there remains the possibility using something like the WebPKI, there remains the possibility
that the name is a look alike: e.g, dem0.example. vs that the name is a look alike: e.g., dem0.example. vs.
demO.example. demO.example.
</li> </li>
<li> <li>
scanning the trust anchor from a QR code that came with the scanning the trust anchor from a QR code that came with the
packaging (this is really a manual TOFU mechanism) packaging (this is really a manual TOFU mechanism).
</li> </li>
<li> <li>
some sales integration process where trust anchors are provided some sales integration processing where trust anchors are provided
as part of the sales process, probably included in a digital as part of the sales process, probably included in a digital
packing "slip", or a sales invoice. packing "slip", or a sales invoice.
</li> </li>
<li> <li>
consortium membership, where all manufacturers of a particular consortium membership, where all manufacturers of a particular
device category (e.g, a light bulb, or a cable-modem) are device category (e.g, a light bulb or a cable modem) are
signed by an certificate authority specifically for this. signed by a CA specifically for this.
This is done by CableLabs today. It is used for authentication This is done by CableLabs today.
and authorization as part of TR-79: <xref target="docsisroot" form
at="default"/> and <xref target="TR069" format="default"/>. It is used for authentication
and authorization as part of <xref target="docsisroot" format="def
ault"/> and <xref target="TR069" format="default"/>.
</li> </li>
</ul> </ul>
<t> <t>
The existing WebPKI provides a reasonable anchor between manufacturer The existing WebPKI provides a reasonable anchor between manufacturer
name and public key. It authenticates the key. It does not provide a name and public key. It authenticates the key. It does not provide a
reasonable authorization for the manufacturer, so it is not directly reasonable authorization for the manufacturer, so it is not directly
useable on it's own. usable on its own.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Manufacturer Maintenance of trust anchors</name> <name>Manufacturer Maintenance of Trust Anchors</name>
<t> <t>
BRSKI depends upon the manufacturer building in trust anchors BRSKI depends upon the manufacturer building in trust anchors
to the pledge device. The voucher artifact which is signed by the to the pledge device. The voucher artifact that is signed by the
MASA will be validated by the pledge using that anchor. This MASA will be validated by the pledge using that anchor. This
implies that the manufacturer needs to maintain access to a signing implies that the manufacturer needs to maintain access to a signing
key that the pledge can validate. key that the pledge can validate.
</t> </t>
<t> <t>
The manufacturer will need to The manufacturer will need to
maintain the ability to make signatures that can be validated for maintain the ability to make signatures that can be validated for
the lifetime that the device could be onboarded. Whether the lifetime that the device could be onboarded. Whether
this onboarding lifetime is less than the device lifetime depends this onboarding lifetime is less than the device lifetime depends
upon how the device is used. An inventory of devices kept in a upon how the device is used. An inventory of devices kept in a
warehouse as spares might not be onboarded for many decades. warehouse as spares might not be onboarded for many decades.
</t> </t>
<t> <t>
There are good cryptographic hygiene reasons why a manufacturer There are good cryptographic hygiene reasons why a manufacturer
would not want to maintain access to a private key for many would not want to maintain access to a private key for many
decades. A manufacturer in that situation can leverage a long-term decades. A manufacturer in that situation can leverage a long-term
certificate authority anchor, built-in to the pledge, and then CA anchor, built-in to the pledge, and then
a certificate chain may be incorporated using the normal CMS a certificate chain may be incorporated using the normal CMS
certificate set. This may increase the size of the voucher certificate set. This may increase the size of the voucher
artifacts, but that is not a significant issues in non-constrained artifacts, but that is not a significant issue in non-constrained
environments. environments.
</t> </t>
<t> <t>
There are a few other operational variations that manufacturers There are a few other operational variations that manufacturers
could consider. For instance, there is no reason that every device could consider. For instance, there is no reason that every device
need have the same need have the same
set of trust anchors pre-installed. Devices built in different set of trust anchors preinstalled. Devices built in different
factories, or on different days, or any other consideration could factories, or on different days, or in any other consideration, could
have different trust anchors built in, and the record of which have different trust anchors built in, and the record of which
batch the device is in would be recorded in the asset database. batch the device is in would be recorded in the asset database.
The manufacturer would then know which anchor to sign an artifact The manufacturer would then know which anchor to sign an artifact
against. against.
</t> </t>
<t> <t>
Aside from the concern about long-term access to private keys, a Aside from the concern about long-term access to private keys, a
major limiting factor for the shelf-life of many devices will be major limiting factor for the shelf life of many devices will be
the age of the cryptographic algorithms included. A device the age of the cryptographic algorithms included. A device
produced in 2019 will have hardware and software capable of produced in 2019 will have hardware and software capable of
validating algorithms common in 2019, and will have no defense validating algorithms common in 2019 and will have no defense
against attacks (both quantum and von-neuman brute force attacks) against attacks (both quantum and von Neumann brute-force attacks)
which have not yet been invented. This concern is orthogonal to that have not yet been invented. This concern is orthogonal to
the concern about access to private keys, but this concern likely the concern about access to private keys, but this concern likely
dominates and limits the lifespan of a device in a warehouse. dominates and limits the life span of a device in a warehouse.
If any update to firmware to support new cryptographic mechanism If any update to the firmware to support new cryptographic mechanisms
were possible (while the device was in a warehouse), updates to were possible (while the device was in a warehouse), updates to
trust anchors would also be done at the same time. trust anchors would also be done at the same time.
</t> </t>
<t> <t>
The set of standard operating procedures for maintaining The set of standard operating procedures for maintaining
high value private keys is well documented. For instance, high-value private keys is well documented. For instance,
the WebPKI provides a number of options for audits at the WebPKI provides a number of options for audits in
<xref target="cabforumaudit" format="default"/>, and the DNSSEC root o perations are well <xref target="cabforumaudit" format="default"/>, and the DNSSEC root o perations are well
documented at <xref target="dnssecroot" format="default"/>. documented in <xref target="dnssecroot" format="default"/>.
</t> </t>
<t> <t>
It is not clear if Manufacturers will take this level of It is not clear if manufacturers will take this level of
precaution, or how strong the economic incentives are to maintain precaution, or how strong the economic incentives are to maintain
an appropriate level of security. an appropriate level of security.
</t> </t>
<t> <t>
This next section examines the risk due to a compromised The next section examines the risk due to a compromised
manufacturer IDevID signing key. This is followed by examination of manufacturer IDevID signing key. This is followed by examination of
the risk due to a compromised MASA key. The third section the risk due to a compromised MASA key. The third section
sections below examines the situation where MASA web server itself below examines the situation where a MASA web server itself
is under attacker control, but that the MASA signing key itself is under attacker control, but the MASA signing key itself
is safe in a not-directly connected hardware module. is safe in a not-directly connected hardware module.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Compromise of Manufacturer IDevID signing keys</name> <name>Compromise of Manufacturer IDevID Signing Keys</name>
<t> <t>
An attacker that has access to the key that the manufacturer uses An attacker that has access to the key that the manufacturer uses
to sign IDevID certificates can create counterfeit devices. to sign IDevID certificates can create counterfeit devices.
Such devices can claim to be from a particular manufacturer, Such devices can claim to be from a particular manufacturer
but be entirely different devices: Trojan horses in effect. but can be entirely different devices: Trojan horses in effect.
</t> </t>
<t> <t>
As the attacker controls the MASA URL in the certificate, As the attacker controls the MASA URL in the certificate,
the registrar can be convinced to talk to the attackers' MASA. the registrar can be convinced to talk to the attacker's MASA.
The Registrar does not need to be in any kind of promiscuous mode The registrar does not need to be in any kind of promiscuous mode
to be vulnerable. to be vulnerable.
</t> </t>
<t> <t>
In addition to creating fake devices, the attacker may also In addition to creating fake devices, the attacker may also
be able to issue revocations for existing certificates if the be able to issue revocations for existing certificates if the
IDevID certificate process relies upon CRL lists that are IDevID certificate process relies upon CRL lists that are
distributed. distributed.
</t> </t>
<t> <t>
There does not otherwise seem to be any risk from this compromise There does not otherwise seem to be any risk from this compromise
to devices which are already deployed, or which are sitting to devices that are already deployed or that are sitting
locally in boxes waiting for deployment (local spares). locally in boxes waiting for deployment (local spares).
The issue is that operators will be unable to trust devices The issue is that operators will be unable to trust devices
which have been in an uncontrolled warehouse as they do not know that have been in an uncontrolled warehouse as they do not know
if those are real devices. if those are real devices.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Compromise of MASA signing keys</name> <name>Compromise of MASA Signing Keys</name>
<t> <t>
There are two periods of time in which to consider: when the MASA There are two periods of time in which to consider: when the MASA
key has fallen into the hands of an attacker, and after the MASA key has fallen into the hands of an attacker and after the MASA
recognizes that the key has been compromised. recognizes that the key has been compromised.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Attacker opportunties with compromised MASA key</name> <name>Attacker Opportunities with a Compromised MASA Key</name>
<t> <t>
An attacker that has access to the MASA signing key could create An attacker that has access to the MASA signing key could create
vouchers. These vouchers could be for existing deployed vouchers. These vouchers could be for existing deployed
devices, or for devices which are still in a warehouse. devices or for devices that are still in a warehouse.
In order to exploit these vouchers two things need to occur: In order to exploit these vouchers, two things need to occur:
the device has to go through a factory default boot cycle, and the the device has to go through a factory default boot cycle, and the
registrar has to be convinced to contact the attacker's MASA. registrar has to be convinced to contact the attacker's MASA.
</t> </t>
<t> <t>
If the attacker controls a Registrar which is visible to the If the attacker controls a registrar that is visible to the
device, then there is no difficulty in delivery of the false device, then there is no difficulty in delivery of the false
voucher. A possible practical example of an attack like this voucher. A possible practical example of an attack like this
would be in a data center, at an ISP peering point (whether a would be in a data center, at an ISP peering point (whether a
public IX, or a private peering point). In such a situation, public IX or a private peering point). In such a situation,
there are already cables attached to the equipment that lead there are already cables attached to the equipment that lead
to other devices (the peers at the IX), and through those to other devices (the peers at the IX), and through those
links, the false voucher could be delivered. The difficult links, the false voucher could be delivered. The difficult
part would be get the device put through a factory reset. part would be to put the device through a factory reset.
This might be accomplished through social engineering of data This might be accomplished through social engineering of data
center staff. Most locked cages have ventilation holes, and center staff. Most locked cages have ventilation holes, and
possibly a long "paperclip" could reach through to depress a possibly a long "paperclip" could reach through to depress a
factory reset button. Once such a piece of ISP equipment has factory reset button. Once such a piece of ISP equipment has
been compromised, it could be used to compromise equipment that been compromised, it could be used to compromise equipment that
was connected to (through long haul links even), assuming that it was connected to (through long haul links even), assuming that
those pieces of equipment could also be forced through a those pieces of equipment could also be forced through a
factory reset. factory reset.
</t> </t>
<t> <t>
The above scenario seems rather unlikely as it requires some The above scenario seems rather unlikely as it requires some
element of physical access; but were there a remote exploit element of physical access; but if there was a remote exploit
that did not cause a direct breach, but rather a fault that that did not cause a direct breach, but rather a fault that
resulted in a factory reset, this could provide a reasonable resulted in a factory reset, this could provide a reasonable
path. path.
</t> </t>
<t> <t>
The above deals with ANI uses of BRSKI. For cases where 802.11 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 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 device is eliminated, but the need to do a factory reset is
not. Physical possession of the device is not required as not. Physical possession of the device is not required as
above, provided that there is some way to force a factory above, provided that there is some way to force a factory
reset. With some consumers devices with low overall reset. With some consumer devices that have low overall
implementation quality, the end users might be familiar with implementation quality, end users might be familiar with the
needing to reset the device regularly. need to reset the device regularly.
</t> </t>
<t> <t>
The authors are unable to come up with an attack scenario where The authors are unable to come up with an attack scenario where
a compromised voucher signature enables an attacker to a compromised voucher signature enables an attacker to
introduce a compromised pledge into an existing operator's introduce a compromised pledge into an existing operator's
network. This is the case because the operator controls the network. This is the case because the operator controls the
communication between Registrar and MASA, and there is no communication between registrar and MASA, and there is no
opportunity to introduce the fake voucher through that conduit. opportunity to introduce the fake voucher through that conduit.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Risks after key compromise is known</name> <name>Risks after Key Compromise is Known</name>
<t> <t>
Once the operator of the MASA realizes that the voucher signing Once the operator of the MASA realizes that the voucher signing
key has been compromised it has to do a few things. key has been compromised, it has to do a few things.
</t> </t>
<t> <t>
First, it MUST issue a firmware update to all devices that First, it <bcp14>MUST</bcp14> issue a firmware update to all devic es that
had that key as a trust anchor, such that they will no longer had that key as a trust anchor, such that they will no longer
trust vouchers from that key. This will affect devices in the trust vouchers from that key. This will affect devices in the
field which are operating, but those devices, being in field that are operating, but those devices, being in
operation, are not performing onboarding operations, so this operation, are not performing onboarding operations, so this
is not a critical patch. is not a critical patch.
</t> </t>
<t> <t>
Devices in boxes (in warehouses) are vulnerable, and remain Devices in boxes (in warehouses) are vulnerable and remain
vulnerable until patched. An operator would be prudent to vulnerable until patched. An operator would be prudent to
unbox the devices, onboard them in a safe environment, and unbox the devices, onboard them in a safe environment, and
then perform firmware updates. This does not have to be then perform firmware updates. This does not have to be
done by the end-operator; it could be done by a distributor done by the end-operator; it could be done by a distributor
that stores the spares. A recommended practice for high value that stores the spares. A recommended practice for high-value
devices (which typically have a &lt;4hr service window) may be to devices (which typically have a &lt;4hr service window) may be to
validate the device operation on a regular basis anyway. validate the device operation on a regular basis anyway.
</t> </t>
<t> <t>
If the onboarding process includes attestations about firmware If the onboarding process includes attestations about firmware
versions, then through that process the operator would be versions, then through that process, the operator would be
advised to upgrade the firmware before going into production. advised to upgrade the firmware before going into production.
Unfortunately, this does not help against situations where the Unfortunately, this does not help against situations where the
attacker operates their own Registrar (as listed above). attacker operates their own registrar (as listed above).
</t> </t>
<t> <t>
<xref target="RFC8366" format="default"/> section 6.1 explains the The need for short-lived vouchers is explained in <xref target="RF
need C8366" sectionFormat="comma" section="6.1"/>. The nonce guarantees freshness,
for short-lived vouchers. The nonce guarantees freshness,
and the short-lived nature of the voucher means that the window and the short-lived nature of the voucher means that the window
to deliver a fake voucher is very short. A nonceless, to deliver a fake voucher is very short. A nonceless,
long-lived voucher would be the only option for the attacker, long-lived voucher would be the only option for the attacker,
and devices in the warehouse would be vulnerable to such a and devices in the warehouse would be vulnerable to such a
thing. thing.
</t> </t>
<t> <t>
A key operational recommendation is for manufacturers to sign A key operational recommendation is for manufacturers to sign
nonceless, long-lived vouchers with a different key that they nonceless, long-lived vouchers with a different key than what is u sed to
sign short-lived vouchers. That key needs significantly better sign short-lived vouchers. That key needs significantly better
protection. If both keys come from a common trust-anchor protection. If both keys come from a common trust-anchor
(the manufacturer's CA), then a compromise of the (the manufacturer's CA), then a compromise of the
manufacturer's CA would compromise both keys. Such a manufacturer's CA would compromise both keys. Such a
compromise of the manufacturer's CA likely compromises compromise of the manufacturer's CA likely compromises
all keys outlined in this section. all keys outlined in this section.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Compromise of MASA web service</name> <name>Compromise of MASA Web Service</name>
<t> <t>
An attacker that takes over the MASA web service has a number of An attacker that takes over the MASA web service can inflict a numbe r of
attacks. The most obvious one is simply to take the database attacks. The most obvious one is simply to take the database
listing customers and devices and to sell this data to other listing of customers and devices and sell the data to other
attackers who will now know where to find potentially vulnerable attackers who will now know where to find potentially vulnerable
devices. devices.
</t> </t>
<t> <t>
The second most obvious thing that the attacker can do is to The second most obvious thing that the attacker can do is to
kill the service, or make it operate unreliably, making kill the service, or make it operate unreliably, making
customers frustrated. This could have a serious affect on customers frustrated. This could have a serious effect on
ability to deploy new services by customers, and would be a the ability to deploy new services by customers and would be a
significant issue during disaster recovery. significant issue during disaster recovery.
</t> </t>
<t> <t>
While the compromise of the MASA web service may lead to the While the compromise of the MASA web service may lead to the
compromise of the MASA voucher signing key, if the signing occurs compromise of the MASA voucher signing key, if the signing occurs
offboard (such as in a hardware signing module, HSM), then the offboard (such as in a hardware signing module (HSM)), then the
key may well be safe, but control over it resides with the attacker. key may well be safe, but control over it resides with the attacker.
</t> </t>
<t> <t>
Such an attacker can issue vouchers for any device presently in Such an attacker can issue vouchers for any device presently in
service. Said device still needs to be convinced to do through a service.
Said device still needs to be convinced to go through a
factory reset process before an attack. factory reset process before an attack.
</t> </t>
<t> <t>
If the attacker has access to a key that is trusted for If the attacker has access to a key that is trusted for
long-lived nonceless vouchers, then they could issue vouchers for long-lived nonceless vouchers, then they could issue vouchers for
devices which are not yet in service. This attack may be very devices that are not yet in service. This attack may be very
hard to verify and as it would involve doing firmware updates hard to verify as it would involve doing firmware updates
on every device in warehouses (a potentially ruinously expensive on every device in warehouses (a potentially ruinously expensive
process), a manufacturer might be reluctant to admit this process); a manufacturer might be reluctant to admit this
possibility. possibility.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Module Security Considerations</name> <name>YANG Module Security Considerations</name>
<t> <t>
As described in the Security Considerations section of <xref target="R FC8366" format="default"/> (section 7.4), the YANG module specified As described in Section <xref target="RFC8366" section="7.4" sectionFo rmat="bare"/> (Security Considerations) of <xref target="RFC8366" format="defaul t"/>, the YANG module specified
in this document defines the schema for data that is subsequently in this document defines the schema for data that is subsequently
encapsulated by a CMS signed-data content type, as described in encapsulated by a CMS signed-data content type, as described in
Section 5 of <xref target="RFC5652" format="default"/>. <xref target="RFC5652" sectionFormat="of" section="5"/>.
As such, all of the YANG modeled data is protected from modification. As such, all of the YANG-modeled data is protected from modification.
</t> </t>
<t> <t>
The use of YANG to define data structures, via the 'yang-data' The use of YANG to define data structures, via the "yang-data"
statement, is relatively new and distinct from the traditional use statement, is relatively new and distinct from the traditional use
of YANG to define an API accessed by network management protocols of YANG to define an API accessed by network management protocols
such as NETCONF <xref target="RFC6241" format="default"/> and RESTCON such as NETCONF <xref target="RFC6241" format="default"/> and RESTCON
F <xref target="RFC8040" format="default"/>. For this F <xref target="RFC8040" format="default"/>. For this
reason, these guidelines do not follow template described by reason, these guidelines do not follow the template described by
Section 3.7 of <xref target="RFC8407" format="default"/>. <xref target="RFC8407" sectionFormat="of" section="3.7"/>.
</t> </t>
</section> </section>
</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> </middle>
<back> <back>
<displayreference target="I-D.ietf-ace-coap-est" to="ACE-COAP-EST"/>
<displayreference target="I-D.richardson-anima-state-for-joinrouter" to="ANIMA-S
TATE"/>
<displayreference target="I-D.ietf-anima-constrained-voucher" to="ANIMA-CONSTRAI
NED-VOUCHER"/>
<displayreference target="I-D.ietf-netconf-keystore" to="YANG-KEYSTORE"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21 xml"/>
19.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.
le> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7030.
<seriesInfo name="RFC" value="2119"/> xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.
<author initials="S." surname="Bradner" fullname="S. Bradner"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
</author> xml"/>
<date year="1997" month="March"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.
<abstract> xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5272.
nify the requirements in the specification. These words are often capitalized. xml"/>
This document defines these words as they should be interpreted in IETF document <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.
s. This document specifies an Internet Best Current Practices for the Internet xml"/>
Community, and requests discussion and suggestions for improvements.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.
</reference> xml"/>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4519.
174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81 xml"/>
74.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.
<front> xml"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.
tle> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3927.
<seriesInfo name="RFC" value="8174"/> xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.
<author initials="B." surname="Leiba" fullname="B. Leiba"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.
</author> xml"/>
<date year="2017" month="May"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.
<abstract> xml"/>
<t>RFC 2119 specifies common key words that may be used in protoco <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.
l specifications. This document aims to reduce the ambiguity by clarifying tha xml"/>
t only UPPERCASE usage of the key words have the defined special meanings.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.
</reference> xml"/>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.
648" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.46 xml"/>
48.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7469.
<front> xml"/>
<title>The Base16, Base32, and Base64 Data Encodings</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8366.
<seriesInfo name="DOI" value="10.17487/RFC4648"/> xml"/>
<seriesInfo name="RFC" value="4648"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8368.
<author initials="S." surname="Josefsson" fullname="S. Josefsson"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
</author> xml"/>
<date year="2006" month="October"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
<abstract> xml"/>
<t>This document describes the commonly used base 64, base 32, and <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.
base 16 encoding schemes. It also discusses the use of line-feeds in encoded d xml"/>
ata, use of padding in encoded data, use of non-alphabet characters in encoded d <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.
ata, use of different encoding alphabets, and canonical encodings. [STANDARDS-T xml"/>
RACK]</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8407.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.
</reference> xml"/>
<reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8951.
030" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.70 xml"/>
30.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8981.
<front> xml"/>
<title>Enrollment over Secure Transport</title>
<seriesInfo name="DOI" value="10.17487/RFC7030"/> <!-- [I-D.ietf-anima-autonomic-control-plane] part of C325 -->
<seriesInfo name="RFC" value="7030"/> <reference anchor='RFC8994'>
<author initials="M." surname="Pritikin" fullname="M. Pritikin" role <front>
="editor"> <title>An Autonomic Control Plane (ACP)</title>
<organization/> <author initials='T' surname='Eckert' fullname='Toerless Eckert' role="editor">
</author> <organization />
<author initials="P." surname="Yee" fullname="P. Yee" role="editor"> </author>
<organization/> <author initials='M' surname='Behringer' fullname='Michael Behringer' role="edit
</author> or">
<author initials="D." surname="Harkins" fullname="D. Harkins" role=" <organization />
editor"> </author>
<organization/> <author initials='S' surname='Bjarnason' fullname='Steinthor Bjarnason'>
</author> <organization />
<date year="2013" month="October"/> </author>
<abstract> <date month='May' year='2021' />
<t>This document profiles certificate enrollment for clients using </front>
Certificate Management over CMS (CMC) messages over a secure transport. This p <seriesInfo name="RFC" value="8994"/>
rofile, called Enrollment over Secure Transport (EST), describes a simple, yet f <seriesInfo name="DOI" value="10.17487/RFC8994"/>
unctional, certificate management protocol targeting Public Key Infrastructure ( </reference>
PKI) clients that need to acquire client certificates and associated Certificati
on Authority (CA) certificates. It also supports client-generated public/privat <!-- [I-D.ietf-anima-grasp] part of C325 -->
e key pairs as well as key pairs generated by the CA.</t> <reference anchor='RFC8990'>
</abstract> <front>
</front> <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
</reference> <author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5 <organization />
652" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.56 </author>
52.xml"> <author initials='B' surname='Carpenter' fullname='Brian Carpenter' role="editor
<front> ">
<title>Cryptographic Message Syntax (CMS)</title> <organization />
<seriesInfo name="DOI" value="10.17487/RFC5652"/> </author>
<seriesInfo name="RFC" value="5652"/> <author initials='B' surname='Liu' fullname='Bing Liu' role="editor">
<seriesInfo name="STD" value="70"/> <organization />
<author initials="R." surname="Housley" fullname="R. Housley"> </author>
<organization/> <date month='May' year='2021' />
</author> </front>
<date year="2009" month="September"/> <seriesInfo name="RFC" value="8990"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC8990"/>
<t>This document describes the Cryptographic Message Syntax (CMS). </reference>
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitr
ary message content. [STANDARDS-TRACK]</t> <reference anchor="ITU.X690" target="https://www.itu.int/rec/T-REC-X.690
</abstract> ">
</front>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<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 Secu
rity (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 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
80.xml">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate 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 certif
icate revocation list (CRL) for use in the Internet. An overview of this approa
ch and model is provided as an introduction. The X.509 v3 certificate format is
described in detail, with additional information regarding the format and seman
tics of Internet name forms. Standard certificate extensions are described and
two Internet-specific extensions are defined. A set of required certificate ext
ensions is specified. The X.509 v2 CRL format is described in detail along with
standard and Internet-specific extensions. An algorithm for X.509 certificatio
n path validation is described. An ASN.1 module and examples are provided in th
e appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5272" target="https://www.rfc-editor.org/info/rfc5
272" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
72.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 Ma
nagement protocol using the Cryptographic Message Syntax (CMS). This protocol ad
dresses two immediate needs within the Internet Public Key Infrastructure (PKI)
community:</t>
<t>1. The need for an interface to public key certification produ
cts and services based on CMS and PKCS #10 (Public Key Cryptography Standard), a
nd</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 req
uirements usage document along with this document for a full definition. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.82
59.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 ECMAScri
pt 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 interoperabi
lity guidance.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.79
50.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" ro
le="editor">
<organization/>
</author>
<date year="2016" month="August"/>
<abstract>
<t>YANG is a data modeling language used to model configuration da
ta, 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 langua
ge, addressing ambiguities and defects in the original specification. There are
a small number of backward incompatibilities from YANG version 1. This documen
t also specifies the YANG mappings to the Network Configuration Protocol (NETCON
F).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7
951" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.79
51.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 configura
tion data, state data, parameters of Remote Procedure Call (RPC) operations or a
ctions, 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/rfc4
519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.45
19.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" ro
le="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 specifi
cation of attribute types and object classes intended for use by LDAP directory
clients for many directory services, such as White Pages. These objects are wid
ely 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. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
762" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.67
62.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 ub
iquitous, the ability to operate with less configured infrastructure is increasi
ngly 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 convention
al managed DNS server is useful.</t>
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like o
perations on the local link in the absence of any conventional Unicast DNS serve
r. In addition, Multicast DNS designates a portion of the DNS namespace to be f
ree 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 r
equire little or no administration or configuration to set them up, (ii) they wo
rk 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/rfc6
763" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.67
63.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 clie
nt 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 des
ired service, using standard DNS queries. This mechanism is referred to as DNS-b
ased Service Discovery, or DNS-SD.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3927" target="https://www.rfc-editor.org/info/rfc3
927" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.39
27.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 c
onfigured with IP addresses for its interfaces, either manually by the user or a
utomatically from a source on the network such as a Dynamic Host Configuration P
rotocol (DHCP) server. Unfortunately, such address configuration information ma
y not always be available. It is therefore beneficial for a host to be able to d
epend on a useful subset of IP networking functions even when no address configu
ration is available. This document describes how a host may automatically confi
gure an interface with an IPv4 address within the 169.254/16 prefix that is vali
d for communication with other devices connected to the same physical (or logica
l) link.</t>
<t>IPv4 Link-Local addresses are not suitable for communication wi
th devices not directly connected to the same physical (or logical) link, and ar
e only used where stable, routable addresses are not available (such as on ad ho
c or isolated networks). This document does not recommend that IPv4 Link-Local
addresses and routable addresses be configured simultaneously on the same interf
ace. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3
339" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.33
39.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 Interne
t protocols that is a profile of the ISO 8601 standard for representation of dat
es and times using the Gregorian calendar.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.40
86.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 3
rd">
<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 t
hat foil pattern analysis attempts. However, the security of these systems is d
ependent on generating secret quantities for passwords, cryptographic keys, and
similar quantities. The use of pseudo-random processes to generate secret quant
ities 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 wh
ole 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 techni
ques for generating such quantities. It recommends the use of truly random hard
ware 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 hard
ware solution is not available, and it gives examples of how large such quantiti
es need to be for some applications. This document specifies an Internet Best C
urrent Practices for the Internet Community, and requests discussion and suggest
ions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
862" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.48
62.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 statel
ess 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/rfc4
941" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.49
41.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 a
dvertised by routers. Addresses are formed by combining network prefixes with a
n interface identifier. On an interface that contains an embedded IEEE Identifi
er, the interface identifier is typically derived from it. On other interface t
ypes, the interface identifier is generated through other means, for example, vi
a random number generation. This document describes an extension to IPv6 statel
ess address autoconfiguration for interfaces whose interface identifier is deriv
ed from an IEEE identifier. Use of the extension causes nodes to generate globa
l scope addresses from interface identifiers that change over time, even in case
s where the interface contains an embedded IEEE identifier. Changing the interf
ace identifier (and the global scope addresses generated from it) over time make
s it more difficult for eavesdroppers and other information collectors to identi
fy when different addresses used in different transactions actually correspond t
o the same node. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3
748" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.37
48.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" ro
le="editor">
<organization/>
</author>
<date year="2004" month="June"/>
<abstract>
<t>This document defines the Extensible Authentication Protocol (E
AP), an authentication framework which supports multiple authentication methods.
EAP typically runs directly over data link layers such as Point-to-Point Proto
col (PPP) or IEEE 802, without requiring IP. EAP provides its own support for d
uplicate elimination and retransmission, but is reliant on lower layer ordering
guarantees. Fragmentation is not supported within EAP itself; however, individu
al EAP methods may support this. This document obsoletes RFC 2284. A summary o
f the changes between this document and RFC 2284 is available in Appendix A. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6
125" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.61
25.xml">
<front>
<title>Representation and Verification of Domain-Based Application S
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
tificates 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 betwe
en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX
) certificates in the context of Transport Layer Security (TLS). This document s
pecifies procedures for representing and verifying the identity of application s
ervices in such interactions. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7
230" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
30.xml">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Ro
uting</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 applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document provides an overview of HTTP architecture and its associated ter
minology, defines the "http" and "https" Uniform Resource Identifier (URI) schem
es, 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/rfc7
231" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
31.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 \%applica
tion- level protocol for distributed, collaborative, hypertext information syste
ms. This document defines the semantics of HTTP/1.1 messages, as expressed by r
equest methods, request header fields, response status codes, and response heade
r fields, along with the payload of messages (metadata and body content) and mec
hanisms for content negotiation.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7469" target="https://www.rfc-editor.org/info/rfc7
469" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.74
69.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 op
erators to instruct user agents to remember ("pin") the hosts' cryptographic ide
ntities 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 Publi
c Key Info structure whose fingerprint matches one of the pinned fingerprints fo
r 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 i
ncidence of man-in-the-middle attacks due to compromised Certification Authoriti
es.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-anima-autonomic-control-plane" xml:base="htt
ps://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-autonomi
c-control-plane.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-anim
a-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 Bjarnas
on">
<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 ide
ally be self-managing, and as independent as possible of configuration. This do
cument 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 "v
irtual 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 eve
n when the network is not configured, or misconfigured.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8
366" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83
66.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 manu
facturer. 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) struct
ure. Other YANG-derived formats are possible. The voucher artifact is normally
generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signi
ng 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/rfc8
368" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83
68.xml">
<front>
<title>Using an Autonomic Control Plane for Stable Connectivity of N
etwork 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="ed
itor">
<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 1
61, for data networks is often subject to the problem of circular dependencies w
hen relying on connectivity provided by the network to be managed for the OAM pu
rposes.</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 pro
tocols are not secure enough to be carried across the network without security c
oncerns.</t>
<t>This document describes how to integrate OAM processes with an
autonomic control plane in order to provide stable and secure connectivity for t
hose OAM processes. This connectivity is not subject to the aforementioned circ
ular 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 Protoco
l (GRASP), which enables autonomic nodes and autonomic service agents to dynamic
ally discover peers, to synchronize state with each other, and to negotiate para
meter settings with each other. GRASP depends on an external security environme
nt that is described elsewhere. The technical objectives and parameters for spe
cific application scenarios are to be described in separate documents. Appendic
es briefly discuss requirements for the protocol and existing protocols with com
parable features.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.86
10.xml">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.80
40.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 c
oncepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.60
20.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" ro
le="editor">
<organization/>
</author>
<date year="2010" month="October"/>
<abstract>
<t>YANG is a data modeling language used to model configuration an
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.62
41.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" ro
le="editor">
<organization/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" 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 do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data enco
ding for the configuration data as well as the protocol messages. The NETCONF p
rotocol 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/rfc8
407" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
07.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 spec
ifications containing YANG modules. Recommendations and procedures are defined,
which are intended to increase interoperability and usability of Network Config
uration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YA
NG modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
</reference>
<reference anchor="ITU.X690.1994" xml:base="https://xml2rfc.tools.ietf.o
rg/public/rfc/bibxml2/reference.ITU.X690.1994.xml">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information Technology - 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> <author>
<organization>International Telecommunications Union</organization <organization>ITU-T</organization>
>
</author>
<date month="" year="1994"/>
</front>
</reference>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
688" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.36
88.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> </author>
<date year="2004" month="January"/> <date month="August" year="2015"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF st
andards which use Extensible Markup Language (XML) related items such as Namespa
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew
ork (RDF) Schemas.</t>
</abstract>
</front>
</reference>
<reference anchor="IDevID" target="http://standards.ieee.org/findstds/st
andard/802.1AR-2009.html">
<front>
<title>IEEE 802.1AR Secure Device Identifier</title>
<author surname="IEEE Standard"/>
<date month="December" year="2009"/>
</front> </front>
<refcontent>ITU-T Recommendation X.690</refcontent>
<refcontent>ISO/IEC 8825-1:2015</refcontent>
</reference> </reference>
<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/d
issertation/top.htm"> <reference anchor="IDevID" target="https://1.ieee802.org/security/802-
1ar">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Secure
Device 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/d
issertation/fielding_dissertation.pdf">
<front> <front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title> <title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author initials="R.F." surname="Fielding" fullname="Roy Fielding"> <author initials="R.F." surname="Fielding" fullname="Roy Fielding">
<organization>University of California, Irvine</organization> <organization>University of California, Irvine</organization>
</author> </author>
<date year="2000"/> <date year="2000"/>
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-anima-reference-model" xml:base="https://xml
2rfc.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-mode
l-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 Network
ing for managed networks. It defines the behaviour of an autonomic node, how th
e various elements in an autonomic context work together, and how autonomic serv
ices can use the infrastructure.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7
435" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.74
35.xml">
<front>
<title>Opportunistic Security: Some Protection Most of the Time</tit
le>
<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 t
he context of communications protocols. Protocol designs based on Opportunistic
Security use encryption even when authentication is not available, and use auth
entication when possible, thereby removing barriers to the widespread use of enc
ryption on the Internet.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7
575" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.75
75.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 fundamenta
l 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 referenc
e model illustrates how functional elements in an Autonomic Network interact. T
his 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/rfc7
228" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
28.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 devic
es 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/rfc7
258" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
58.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 mitig
ated in the design of IETF protocols, where possible.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5785" target="https://www.rfc-editor.org/info/rfc5
785" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.57
85.xml">
<front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</titl
e>
<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-Lah
av">
<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. [STANDARD
S-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2663" target="https://www.rfc-editor.org/info/rfc2
663" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.26
63.xml">
<front>
<title>IP Network Address Translator (NAT) Terminology and Considera
tions</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, and to define the terminology use
d to identify various flavors of NAT. This memo provides information for the In
ternet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
960" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.69
60.xml">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S
tatus 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>
<author initials="M." surname="Myers" fullname="M. Myers">
<organization/>
</author>
<author initials="R." surname="Ankney" fullname="R. Ankney">
<organization/>
</author>
<author initials="A." surname="Malpani" fullname="A. Malpani">
<organization/>
</author>
<author initials="S." surname="Galperin" fullname="S. Galperin">
<organization/>
</author>
<author initials="C." surname="Adams" fullname="C. Adams">
<organization/>
</author>
<date year="2013" month="June"/>
<abstract>
<t>This document specifies a protocol useful in determining the cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (CRLs). Additional mechanisms addressing PKIX operational requirements are
specified in separate documents. This document obsoletes RFCs 2560 and 6277. I
t also updates RFC 5912.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6961" target="https://www.rfc-editor.org/info/rfc6
961" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.69
61.xml">
<front>
<title>The Transport Layer Security (TLS) Multiple Certificate Statu
s 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) Certif
icate Status Version 2 Extension to allow clients to specify and support several
certificate status methods. (The use of the Certificate Status extension is co
mmonly referred to as "OCSP stapling".) Also defined is a new method based on t
he Online Certificate Status Protocol (OCSP) that servers can use to provide sta
tus information about not only the server's own certificate but also the status
of intermediate certificates in the chain.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83
40.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="ed
itor">
<organization/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for
this definition. This syntax may be updated from time to time based on the evol
ution of the YANG language.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-ace-coap-est" xml:base="https://xml2rfc.tool
s.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">
<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" fullname="Peter van der Stok">
<organization/>
</author>
<author initials="P" surname="Kampanakis" fullname="Panos Kampanakis
">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization/>
</author>
<author initials="S" surname="Raza" fullname="Shahid Raza">
<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 lightweig
ht Constrained Application Protocol (CoAP) for message exchanges. This document
defines how to transport EST payloads over secure CoAP (EST-coaps), which allow
s constrained devices to use existing EST functionality for provisioning certifi
cates.</t>
</abstract>
</front>
</reference>
<!-- not referenced anymore: <?rfc
include="reference.I-D.ietf-anima-stable-connectivity" ?> -->
<reference anchor="I-D.richardson-anima-state-for-joinrouter" xml:base="ht
tps://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.richardson-anima-s
tate-for-joinrouter.xml" target="http://www.ietf.org/internet-drafts/draft-richa
rdson-anima-state-for-joinrouter-02.txt">
<front>
<title>Considerations for stateful vs stateless join router in ANIMA
bootstrap</title>
<seriesInfo name="Internet-Draft" value="draft-richardson-anima-stat
e-for-joinrouter-02"/>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization/>
</author>
<date month="January" day="25" year="2018"/>
<abstract>
<t>This document explores a number of issues affecting the decisio
n to use a stateful or stateless forwarding mechanism by the join router (aka jo
in 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-constr
ained-voucher-08.txt">
<front>
<title>Constrained Voucher Artifacts for Bootstrapping Protocols</ti
tle>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constraine
d-voucher-08"/>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<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 man
ufacturer. This artifact is known as a "voucher". This document builds upon th
e work in [RFC8366], encoding the resulting artifact in CBOR. Use with two sign
ature technologies are described. Additionally, this document explains how cons
trained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-es
t] 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" targe
t="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/>
</author>
<date month="July" day="10" year="2020"/>
<abstract>
<t>This document defines a YANG 1.1 module called "ietf-keystore"
that enables centralized configuration of both symmetric and asymmetric keys. T
he secret value for both key types may be encrypted. Asymmetric keys may be asso
ciated with certificates. Notifications are sent when certificates are about to
expire. Editorial Note (To be removed by RFC Editor) This draft contains plac
eholder values that need to be replaced with finalized values at the time of pub
lication. This note summarizes all of the substitutions that are needed. No ot
her RFC Editor instructions are specified elsewhere in this document. Artwork i
n this document contains shorthand references to drafts in progress. Please app
ly the following replacements: * "AAAA" --&gt; the assigned RFC value for draf
t-ietf-netconf-crypto- types * "CCCC" --&gt; the assigned RFC value for this d
raft Artwork in this document contains placeholder values for the date of publi
cation of this draft. Please apply the following replacement: * "2020-07-10"
--&gt; the publication date of this draft The following Appendix section is to
be removed prior to publication: * Appendix A. Change Log</t>
</abstract>
</front>
</reference>
<!-- not referenced anywhere: <?rfc include="reference.RFC.8572" ?> -->
<reference anchor="W3C.WD-capability-urls-20140218" target="http://www.w3. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.
org/TR/2014/WD-capability-urls-20140218" xml:base="https://xml2rfc.tools.ietf.or xml"/>
g/public/rfc/bibxml4/reference.W3C.WD-capability-urls-20140218.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='RFC8993' target='https://www.rfc-editor.org/info/rfc8993'>
<front>
<title>A Reference Model for Autonomic Networking</title>
<author initials='M' surname='Behringer' fullname='Michael Behringer' role='edit
or'>
<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='May' year='2021' />
</front>
<seriesInfo name='RFC' value='8993' />
<seriesInfo name='DOI' value='10.17487/RFC8993' />
</reference>
<!-- [I-D.ietf-ace-coap-est] in MISSREF state 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.ietf-ac
e-coap-est.xml"/>-->
<reference anchor="I-D.ietf-ace-coap-est">
<front>
<title>EST over secure CoAP (EST-coaps)</title>
<author initials="P" surname="van der Stok" fullname="Peter van der Stok">
<organization>Consultant</organization>
</author>
<author fullname="Panos Kampanakis">
<organization>Cisco Systems</organization>
</author>
<author fullname="Michael Richardson">
<organization>Sandelman Software Works</organization>
</author>
<author fullname="Shahid Raza">
<organization>RISE SICS</organization>
</author>
<date month="January" day="6" year="2020" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18" />
</reference>
<!-- [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.richard
son-anima-state-for-joinrouter.xml"/>-->
<reference anchor="I-D.richardson-anima-state-for-joinrouter">
<front>
<title>Considerations for stateful vs stateless join router in ANIMA boots
trap</title>
<author fullname="Michael Richardson">
<organization>Sandelman Software Works</organization>
</author>
<date month="September" day="22" year="2020" />
<abstract>
<t> This document explores a number of issues affecting the decision t
o
use a stateful or stateless forwarding mechanism by the join router
(aka join assistant) during the bootstrap process for ANIMA.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-richardson-anima-state-for-joi
nrouter-03" />
</reference>
<!-- [I-D.ietf-anima-constrained-voucher] Active: IESG state I-D Exists as of 20
21-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.ietf-an
ima-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>
<!-- [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-ne
tconf-keystore.xml"/>
<reference anchor="W3C.capability-urls" target="https://www.w3.org/TR/2014
/WD-capability-urls">
<front> <front>
<title>Good Practices for Capability URLs</title> <title>Good Practices for Capability URLs</title>
<seriesInfo name="World Wide Web Consortium WD" value="WD-capability -urls-20140218"/> <seriesInfo name="World Wide Web Consortium WD" value="WD-capability -urls-20140218"/>
<author initials="J." surname="Tennison" fullname="Jeni Tennison"> <author initials="J." surname="Tennison" fullname="Jeni Tennison">
<organization/> <organization/>
</author> </author>
<date month="February" day="18" year="2014"/> <date month="February" year="2014"/>
</front>
</reference>
<reference anchor="RFC5209" target="https://www.rfc-editor.org/info/rfc5
209" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
09.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 protoco
l requirements between the components of the NEA (Network Endpoint Assessment) r
eference model. NEA provides owners of networks (e.g., an enterprise offering r
emote access) a mechanism to evaluate the posture of a system. This may take pl
ace 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 t
o a variety of compliance-oriented decisions. The posture information is freque
ntly 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> </front>
<refcontent>W3C First Public Working Draft</refcontent>
</reference> </reference>
<reference anchor="docsisroot" target="https://www.cablelabs.com/resourc es/digital-certificate-issuance-service/"> <reference anchor="docsisroot" target="https://www.cablelabs.com/resourc es/digital-certificate-issuance-service/">
<front> <front>
<title>CableLabs Digital Certificate Issuance Service</title> <title>CableLabs Digital Certificate Issuance Service</title>
<author surname="CableLabs"/> <author surname="CableLabs"/>
<date month="February" year="2018"/> <date month="February" year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="slowloris" target="https://en.wikipedia.org/wiki/Slow
loris_(computer_security)/"> <reference anchor="slowloris" target="https://en.wikipedia.org/w/index.p
hp?title=Slowloris_(computer_security)&amp;oldid=1001473290/">
<front> <front>
<title>Slowloris (computer security)</title> <title>Slowloris (computer security)</title>
<author surname="Wikipedia"/> <author><organization>Wikipedia</organization></author>
<date month="February" year="2019"/> <date month="January" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="openssl" target="https://www.openssl.org/docs/man1.1. 1/man1/openssl-x509.html/"> <reference anchor="openssl" target="https://www.openssl.org/docs/man1.1. 1/man1/openssl-x509.html/">
<front> <front>
<title>OpenSSL X509 utility</title> <title>OpenSSL X509 Utility</title>
<author surname="Openssl"/> <author><organization>OpenSSL</organization></author>
<date month="September" year="2019"/> <date month="September" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="TR069" target="https://www.broadband-forum.org/standa
rds-and-software/technical-specifications/tr-069-files-tools"> <reference anchor="TR069" target="https://www.broadband-forum.org/downlo
ad/TR-069_Amendment-6.pdf">
<front> <front>
<title>TR-69: CPE WAN Management Protocol</title> <title>CPE WAN Management Protocol</title>
<author surname="Broadband Forum"/> <author><organization>Broadband Forum</organization></author>
<date month="February" year="2018"/> <date month="March" year="2018"/>
</front> </front>
<refcontent>TR-069, Issue 1, Amendment 6</refcontent>
</reference> </reference>
<reference anchor="imprinting" target="https://en.wikipedia.org/wiki/Imp
rinting_(psychology)"> <reference anchor="imprinting" target="https://en.wikipedia.org/w/index.
php?title=Imprinting_(psychology)&amp;=999211441">
<front> <front>
<title>Wikipedia article: Imprinting</title> <title>Imprinting (psychology)</title>
<author surname="Wikipedia"/> <author><organization>Wikipedia</organization></author>
<date month="July" year="2015"/> <date month="January" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="softwareescrow" target="https://en.wikipedia.org/wiki
/Source_code_escrow"> <reference anchor="softwareescrow" target="https://en.wikipedia.org/w/in
dex.php?title=Source_code_escrow)&amp;oldid=948073074">
<front> <front>
<title>Wikipedia article: Software Escrow</title> <title>Source code escrow</title>
<author surname="Wikipedia"/> <author><organization>Wikipedia</organization></author>
<date month="October" year="2019"/> <date month="March" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="IoTstrangeThings" target="https://www.welivesecurity. com/2017/03/03/internet-of-things-security-privacy-iot-update/"> <reference anchor="IoTstrangeThings" target="https://www.welivesecurity. com/2017/03/03/internet-of-things-security-privacy-iot-update/">
<front> <front>
<title>IoT of toys stranger than fiction: Cybersecurity and data <title>IoT of toys stranger than fiction: Cybersecurity and data
privacy update (accessed 2018-12-02)</title> privacy update</title>
<author surname="Internet"/> <author><organization>ESET</organization></author>
<date month="March" year="2017"/> <date month="March" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="livingwithIoT" target="https://www.siliconrepublic.co m/machines/iot-smart-devices-reality"> <reference anchor="livingwithIoT" target="https://www.siliconrepublic.co m/machines/iot-smart-devices-reality">
<front> <front>
<title>What is it actually like to live in a house filled with IoT <title>What is it actually like to live in a house filled with IoT
devices? (accessed 2018-12-02)</title> devices?</title>
<author surname="Internet"/> <author><organization>Silicon Republic</organization></author>
<date month="February" year="2018"/> <date month="February" year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="brewski" target="https://www.urbandictionary.com/defi ne.php?term=brewski"> <reference anchor="brewski" target="https://www.urbandictionary.com/defi ne.php?term=brewski">
<front> <front>
<title>Urban Dictionary: Brewski</title> <title>brewski</title>
<author surname="Internet"/> <author><organization>Urban Dictionary</organization></author>
<date month="October" year="2019"/> <date month="March" year="2003"/>
</front> </front>
</reference> </reference>
<reference anchor="cabforumaudit" target="https://cabforum.org/informati on-for-auditors-and-assessors/"> <reference anchor="cabforumaudit" target="https://cabforum.org/informati on-for-auditors-and-assessors/">
<front> <front>
<title>Information for Auditors and Assessors</title> <title>Information for Auditors and Assessors</title>
<author surname="CA/Browser Forum"/> <author><organization>CA/Browser Forum</organization></author>
<date month="August" year="2019"/> <date month="August" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="dnssecroot" target="https://www.iana.org/dnssec/dps/z
sk-operator/dps-zsk-operator-v2.0.pdf"> <reference anchor="dnssecroot" target="https://www.iana.org/dnssec/proce
dures/zsk-operator/dps-zsk-operator-v2.1.pdf">
<front> <front>
<title>DNSSEC Practice Statement for the Root Zone ZSK Operator</tit le> <title>DNSSEC Practice Statement for the Root Zone ZSK Operator</tit le>
<author surname="Verisign"/> <author surname="Verisign"/>
<date month="December" year="2017"/> <date month="December" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="Stajano99theresurrecting" target="https://www.cl.cam. ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf"> <reference anchor="Stajano99theresurrecting" target="https://www.cl.cam. ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf">
<front> <front>
<title>The resurrecting duckling: security issues for ad-hoc <title>The Resurrecting Duckling: Security Issues for Ad-hoc
wireless networks</title> Wireless Networks</title>
<author fullname="Frank Stajano" initials="F." surname="Stajano"/> <author fullname="Frank Stajano" initials="F." surname="Stajano"/>
<author fullname="Ross Anderson" initials="R." surname="Anderson"/> <author fullname="Ross Anderson" initials="R." surname="Anderson"/>
<date year="1999"/> <date year="1999"/>
</front> </front>
</reference> </reference>
<reference anchor="minerva" target="https://minerva.sandelman.ca/"> <reference anchor="minerva" target="https://minerva.sandelman.ca/">
<front> <front>
<title>Minerva reference implementation for BRSKI</title> <title>Minerva reference implementation for BRSKI</title>
<author fullname="Michael Richardson" initials="M." surname="Richard sdon"/> <author fullname="Michael Richardson" initials="M." surname="Richard son"/>
<date year="2020"/> <date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="minervagithub" target="https://github.com/ANIMAgus-mi nerva"> <reference anchor="minervagithub" target="https://github.com/ANIMAgus-mi nerva">
<front> <front>
<title>GITHUB hosting of Minerva reference code</title> <title>ANIMA Minerva toolkit</title>
<author fullname="Michael Richardson" initials="M." surname="Richard <author/>
sdon"/> <date/>
<date year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="Dingledine2004" target="https://spec.torproject.org/t
or-spec"> <reference anchor="Dingledine" target="https://svn-archive.torproject.or
g/svn/projects/design-paper/tor-design.pdf">
<front> <front>
<title>Tor: the second-generation onion router</title> <title>Tor: The Second-Generation Onion Router</title>
<author initials="R." surname="Dingledine"> <author initials="R." surname="Dingledine">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Mathewson"> <author initials="N." surname="Mathewson">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Syverson"> <author initials="P." surname="Syverson">
<organization/> <organization/>
</author> </author>
<date year="2004"/> <date month="August" year="2004"/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="IPv4operations" numbered="true" toc="default"> <section anchor="IPv4operations" numbered="true" toc="default">
<name>IPv4 and non-ANI operations</name> <name>IPv4 and Non-ANI Operations</name>
<t> <t>
The specification of BRSKI in <xref target="proxydetails" format="defaul t"/> The specification of BRSKI in <xref target="proxydetails" format="defaul t"/>
intentionally only covers the mechanisms for an IPv6 pledge using intentionally covers only the mechanisms for an IPv6 pledge using
Link-Local addresses. This section describes non-normative link-local addresses. This section describes non-normative
extensions that can be used in other environments. extensions that can be used in other environments.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IPv4 Link Local addresses</name> <name>IPv4 Link-Local Addresses</name>
<t>Instead of an IPv6 link-local address, an IPv4 address may be <t>Instead of an IPv6 link-local address, an IPv4 address may be
generated using <xref target="RFC3927" format="default"/> Dynamic Configu generated using "Dynamic Configuration of
ration of IPv4 Link-Local Addresses" <xref target="RFC3927" format="default"/>.
IPv4 Link-Local Addresses.
</t> </t>
<t> In the case that an IPv4 Link-Local address is formed, then the <t> In the case where an IPv4 link-local address is formed, the
bootstrap process would continue as in the IPv6 case by looking for bootstrap process would continue, as in an IPv6 case, by looking for
a (circuit) proxy. a (circuit) proxy.
</t> </t>
</section> </section>
<section anchor="IPv4dhcp" numbered="true" toc="default"> <section anchor="IPv4dhcp" numbered="true" toc="default">
<name>Use of DHCPv4</name> <name>Use of DHCPv4</name>
<t> <t>
The Pledge MAY obtain an IP address via The pledge <bcp14>MAY</bcp14> obtain an IP address via
DHCP [RFC2131]. The DHCP provided parameters for the Domain Name DHCP (<xref target="RFC2131" format="default"/>. The DHCP-provided param
eters for the Domain Name
System can be used to perform DNS operations if all System can be used to perform DNS operations if all
local discovery attempts fail. local discovery attempts fail.
</t> </t>
</section> </section>
</section> </section>
<section anchor="mdnsmethods" numbered="true" toc="default"> <section anchor="mdnsmethods" numbered="true" toc="default">
<name>mDNS / DNSSD proxy discovery options</name> <name>mDNS / DNS-SD Proxy Discovery Options</name>
<t>Pledge discovery of the proxy (<xref target="discovery" format="default <t>Pledge discovery of the proxy (<xref target="discovery" format="default
"/>) MAY be performed with DNS-based Service Discovery <xref target="RFC6763" fo "/>) <bcp14>MAY</bcp14> be performed with DNS-based Service Discovery <xref targ
rmat="default"/> over Multicast DNS <xref target="RFC6762" format="default"/> to et="RFC6763" format="default"/> over Multicast DNS <xref target="RFC6762" format
discover the proxy at ="default"/> to discover the proxy at
"_brski-proxy._tcp.local.". </t> "_brski-proxy._tcp.local.". </t>
<t>Proxy discovery of the registrar (<xref target="JRCgrasp" format="defau lt"/>) MAY be performed with DNS-based Service Discovery over Multicast DNS to d iscover registrars by searching for the service <t>Proxy discovery of the registrar (<xref target="JRCgrasp" format="defau lt"/>) <bcp14>MAY</bcp14> be performed with DNS-based Service Discovery over Mul ticast DNS to discover registrars by searching for the service
"_brski-registrar._tcp.local.".</t> "_brski-registrar._tcp.local.".</t>
<t> <t>
To prevent unaccceptable levels of To prevent unacceptable levels of
network traffic, when using mDNS, the congestion avoidance mechanisms network traffic, when using mDNS, the congestion avoidance mechanisms
specified in specified in
<xref target="RFC6762" format="default"/> section 7 MUST be followed. Th <xref target="RFC6762" sectionFormat="comma" section="7"/> <bcp14>MUST</
e bcp14> be followed. The
pledge SHOULD listen for an unsolicited broadcast response as pledge <bcp14>SHOULD</bcp14> listen for an unsolicited broadcast respons
e as
described in <xref target="RFC6762" format="default"/>. This allows devi ces described in <xref target="RFC6762" format="default"/>. This allows devi ces
to avoid announcing their presence via mDNS broadcasts and to avoid announcing their presence via mDNS broadcasts and
instead silently join a network by watching for periodic instead silently join a network by watching for periodic
unsolicited broadcast responses. unsolicited broadcast responses.
</t> </t>
<t> <t>
Discovery of registrar MAY also be performed with DNS-based Discovery of the registrar <bcp14>MAY</bcp14> also be performed with DNS
service discovery by searching for the service "_brski-registrar._tcp.ex -based
ample.com". Service Discovery by searching for the service "_brski-registrar._tcp.ex
In this case the domain ample.com".
"example.com" is discovered as described in <xref target="RFC6763" forma In this case, the domain
t="default"/> section 11 (<xref target="IPv4dhcp" format="default"/> "example.com" is discovered as described in <xref target="RFC6763"
sectionFormat="comma" section="11"/> (<xref target="IPv4dhcp" format="default"/>
of this document
suggests the use of DHCP parameters). suggests the use of DHCP parameters).
</t> </t>
<t> <t>
If no local proxy or registrar service is located using the GRASP If no local proxy or registrar service is located using the GRASP
mechanisms or the above mentioned DNS-based Service Discovery mechanisms or the above-mentioned DNS-based Service Discovery
methods, the pledge MAY contact a well methods, the pledge <bcp14>MAY</bcp14> contact a well-known
known manufacturer provided bootstrapping server by performing a DNS manufacturer-provided bootstrapping server by performing a DNS
lookup using a well known URI such as lookup using a well-known URI such as
"brski-registrar.manufacturer.example.com". The details of the URI are "brski-registrar.manufacturer.example.com". The details of the URI are
manufacturer specific. Manufacturers that leverage this method on the manufacturer specific. Manufacturers that leverage this method on the
pledge pledge
are responsible for providing the registrar service. are responsible for providing the registrar service.
Also see <xref target="cloudregistrar" format="default"/>. Also see <xref target="cloudregistrar" format="default"/>.
</t> </t>
<t> <t>
The current DNS services returned The current DNS services returned
during each query are maintained until bootstrapping is completed. If during each query are maintained until bootstrapping is completed. If
bootstrapping fails and the pledge returns to the Discovery state, it bootstrapping fails and the pledge returns to the Discovery state, it
picks up where it left off and continues attempting bootstrapping. picks up where it left off and continues attempting bootstrapping.
For example, if the first Multicast DNS _bootstrapks._tcp.local For example, if the first Multicast DNS _bootstrapks._tcp.local
response doesn't work then the second and third responses are tried. response doesn't work, then the second and third responses are tried.
If these fail the pledge moves on to normal DNS-based Service If these fail, the pledge moves on to normal DNS-based Service
Discovery. Discovery.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Example Vouchers</name> <name>Example Vouchers</name>
<t> <t>
Three entities are involved in a voucher: the MASA issues (signs) Three entities are involved in a voucher: the MASA issues (signs)
it, the registrar's public key is mentioned in the voucher, and the it, the registrar's public key is mentioned in it, and the
pledge validates it. In order to provide reproduceable examples pledge validates it. In order to provide reproducible examples,
the public and private keys for an example MASA and registrar are the public and private keys for an example MASA and registrar are
first listed. listed first.
</t> </t>
<t> <t>
The keys come from an open source reference implementation of BRSKI, The keys come from an open source reference implementation of BRSKI,
called "Minerva" <xref target="minerva" format="default"/>. called "Minerva" <xref target="minerva" format="default"/>.
It is available on github <xref target="minervagithub" format="default"/ >. It is available on GitHub <xref target="minervagithub" format="default"/ >.
The keys presented here are used in the unit and integration tests. The keys presented here are used in the unit and integration tests.
The MASA code is called "highway", the Registrar code is called The MASA code is called "highway", the registrar code is called
"fountain", and the example client is called "reach". "fountain", and the example client is called "reach".
</t> </t>
<t> <t>
The public key components of each are presented as both base64 The public key components of each are presented as base64
certificates, as well as being decoded by openssl's x509 certificates and are decoded by openssl's x509
utility so that the extensions can be seen. This was version utility so that the extensions can be seen. This was version
1.1.1c of the <xref target="openssl" format="default"/> library and util ity. 1.1.1c of the library and utility of <xref target="openssl" format="defa ult"/>.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Keys involved</name> <name>Keys Involved</name>
<t> <t>
The Manufacturer has a Certificate Authority that signs the The manufacturer has a CA that signs the
pledge's IDevID. In addition the Manufacturer's signing authority pledge's IDevID. In addition, the Manufacturer's signing authority
(the MASA) signs the vouchers, and that certificate must (the MASA) signs the vouchers, and that certificate must
distributed to the devices at manufacturing time so that vouchers distributed to the devices at manufacturing time so that vouchers
can be validated. can be validated.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Manufacturer Certificate Authority for IDevID signatures</name> <name>Manufacturer Certification Authority for IDevID Signatures</name >
<t> <t>
This private key is Certificate Authority that signs IDevID certific ates: This private key is the CA that signs IDevID certificates:
</t> </t>
<sourcecode name="vendor.key" type="" markers="true"><![CDATA[ <sourcecode name="vendor.key" type="" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G
8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH 8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
juF8QkoAbT8pMrY83MS8y76wZ7AalNQ= juF8QkoAbT8pMrY83MS8y76wZ7AalNQ=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></sourcecode> ]]></sourcecode>
<t> <t>
skipping to change at line 6015 skipping to change at line 5445
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G
8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH 8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
juF8QkoAbT8pMrY83MS8y76wZ7AalNQ= juF8QkoAbT8pMrY83MS8y76wZ7AalNQ=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></sourcecode> ]]></sourcecode>
<t> <t>
This public key validates IDevID certificates: This public key validates IDevID certificates:
</t> </t>
<t keepWithPrevious="true">file: examples/vendor.key</t> <t keepWithPrevious="true">file: examples/vendor.key</t>
<sourcecode name="vendor.cert" type="" markers="true"><![CDATA[ <sourcecode name="vendor.cert" type="example-crypto-material" markers= "true"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 519772114 (0x1efb17d2) Serial Number: 1216069925 (0x487bc125)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.exam ple.com CA Issuer: CN = highway-test.example.com CA
Validity Validity
Not Before: Feb 12 22:22:21 2019 GMT Not Before: Apr 13 20:34:24 2021 GMT
Not After : Feb 11 22:22:21 2021 GMT Not After : Apr 13 20:34:24 2023 GMT
Subject: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.exa Subject: CN = highway-test.example.com CA
mple.com CA
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit) Public-Key: (384 bit)
pub: pub:
04:2e:e7:fc:a4:b4:96:c5:2e:33:02:f3:b8:7b:6f: 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: 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: 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: 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: 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: e1:7c:42:4a:00:6d:3f:29:32:b6:3c:dc:c4:bc:cb:
be:b0:67:b0:1a:94:d4 be:b0:67:b0:1a:94:d4
ASN1 OID: secp384r1 ASN1 OID: secp384r1
NIST CURVE: P-384 NIST CURVE: P-384
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Key Usage: critical X509v3 Key Usage: critical
Certificate Sign, CRL Sign Certificate Sign, CRL Sign
X509v3 Subject Key Identifier: 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: X509v3 Authority Key Identifier:
keyid:5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76:8C:53:8A:0 keyid:5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:
8 80:76:8C:53:8A:08
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:65:02:30:5f:21:fd:c6:ab:d6:94:a6:cd:ca:37:2c:81:33: 30:64:02:30:60:37:a0:66:89:80:27:e1:0d:e5:43:9a:62:f1:
87:fe:7b:e1:b5:1a:e8:6c:05:43:a6:8b:4e:22:b5:55:e9:48: 02:bc:0f:72:6d:a9:e9:cb:84:a5:c6:44:d3:41:9e:5d:ce:7d:
0c:b5:97:f3:c9:1a:65:d9:97:4b:f0:21:86:0d:cb:26:02:31: 46:16:6e:15:de:f7:cc:e8:3e:61:f9:03:7c:20:c4:b7:02:30:
00:e3:2d:0d:08:49:4d:a3:f5:dc:57:1f:a7:13:26:a4:e0:d6: 7f:e9:f3:12:bb:06:c6:24:00:2b:41:aa:21:6b:d8:25:ed:81:
3a:c2:d5:4a:50:83:62:26:2e:79:2b:d0:a5:ee:66:d5:bf:16: 07:11:ef:66:8f:06:bf:c8:be:f0:58:74:24:45:39:4d:04:fc:
9a:33:75:b4:d1:8d:ba:d3:50:77:6b:92:df 31:69:6f:cf:db:fe:61:7b:c3:24:31:ff
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICTDCCAdKgAwIBAgIEHvsX0jAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h MIIB3TCCAWSgAwIBAgIESHvBJTAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjAzNDI0WhcNMjMwNDEz
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjIyMVoX MjAzNDI0WjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0Ew
DTIxMDIxMTIyMjIyMVowXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh djAQBgcqhkjOPQIBBgUrgQQAIgNiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH
cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP
eGFtcGxlLmNvbSBDQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABC7n/KS0lsUuMwLz juF8QkoAbT8pMrY83MS8y76wZ7AalNSjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYD
uHtv7JOt4W4XwbB7AocviZLSvR1UBC5uoNRBxOuO+letcKlOiOIsLOCnx/ORxQOR VR0PAQH/BAQDAgEGMB0GA1UdDgQWBBReDKlSWozfqQ8DFOmW8YB2jFOKCDAfBgNV
n0sP8z3QsOKmIs0g6Q+O4XxCSgBtPykytjzcxLzLvrBnsBqU1KNjMGEwDwYDVR0T HSMEGDAWgBReDKlSWozfqQ8DFOmW8YB2jFOKCDAKBggqhkjOPQQDAgNnADBkAjBg
AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFF4MqVJajN+pDwMU N6BmiYAn4Q3lQ5pi8QK8D3JtqenLhKXGRNNBnl3OfUYWbhXe98zoPmH5A3wgxLcC
6ZbxgHaMU4oIMB8GA1UdIwQYMBaAFF4MqVJajN+pDwMU6ZbxgHaMU4oIMAoGCCqG MH/p8xK7BsYkACtBqiFr2CXtgQcR72aPBr/IvvBYdCRFOU0E/DFpb8/b/mF7wyQx
SM49BAMCA2gAMGUCMF8h/car1pSmzco3LIEzh/574bUa6GwFQ6aLTiK1VelIDLWX /w==
88kaZdmXS/Ahhg3LJgIxAOMtDQhJTaP13FcfpxMmpODWOsLVSlCDYiYueSvQpe5m
1b8WmjN1tNGNutNQd2uS3w==
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>MASA key pair for voucher signatures</name> <name>MASA Key Pair for Voucher Signatures</name>
<t> <t>
The MASA is the Manufacturer Authorized Signing Authority. This The MASA is the Manufacturer Authorized Signing Authority. This
keypair signs vouchers. An example TLS certificate key pair signs vouchers. An example TLS certificate (see <xref targ
<xref target="brskimasatls" format="default"/> HTTP authentication i et="brskimasatls" format="default"/>)
s not provided as it is a HTTP authentication is not provided as it is a
common form. common form.
</t> </t>
<t> <t>
This private key signs the vouchers which are presented below: This private key signs the vouchers that are presented below:
</t> </t>
<sourcecode name="masa.key" type="" markers="true"><![CDATA[ <sourcecode name="masa.key" type="example-crypto-material" markers="tr ue"><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49
AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+
gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></sourcecode> ]]></sourcecode>
<t> <t>
This public key validates vouchers, and it has been signed by the This public key validates vouchers, and it has been signed by the
CA above: CA above:
</t> </t>
<t keepWithPrevious="true">file: examples/masa.key</t> <t keepWithPrevious="true">file: examples/masa.key</t>
<sourcecode name="masa.cert" type="" markers="true"><![CDATA[ <sourcecode name="masa.cert" type="example-crypto-material" markers="t rue"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 463036244 (0x1b995f54) Serial Number: 193399345 (0xb870a31)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.exam ple.com CA Issuer: CN = highway-test.example.com CA
Validity Validity
Not Before: Feb 12 22:22:41 2019 GMT Not Before: Apr 13 21:40:16 2021 GMT
Not After : Feb 11 22:22:41 2021 GMT Not After : Apr 13 21:40:16 2023 GMT
Subject: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.exa Subject: CN = highway-test.example.com MASA
mple.com MASA
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:aa:04:15:a3:44:b9:e2:44:f8:c9:f9:1b:07:1b: 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: 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: 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: 5f:48:9d:22:13:0b:7c:92:cc:df:59:72:b8:ac:b8:
09:4b:69:a7:a5 09:4b:69:a7:a5
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:FALSE CA:FALSE
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:66:02:31:00:bd:55:e5:9b:0e:fb:fc:5e:95:29:e3:81:b3: 30:66:02:31:00:ae:cb:61:2d:d4:5c:8d:6e:86:aa:0b:06:1d:
15:35:aa:93:18:a2:04:be:44:72:b2:51:7d:4d:6d:eb:d1:d5: c6:d3:60:ba:32:73:36:25:d3:23:85:49:87:1c:ce:94:23:79:
c1:10:3a:b2:39:7b:57:3f:c5:cc:b0:a3:0e:e7:99:46:ba:02: 1a:9e:41:55:24:1d:15:22:a1:48:bb:0a:c0:ab:3c:13:73:02:
31:00:f6:7f:44:7d:b7:14:fa:d1:67:6a:d4:11:c3:4b:ae:e6: 31:00:86:3c:67:b3:95:a2:e2:e5:f9:ad:f9:1d:9c:c1:34:32:
fb:9a:98:56:fa:85:21:2e:5c:48:4c:f0:3f:f2:9b:3f:ae:88: 78:f5:cf:ea:d5:47:03:9f:00:bf:d0:59:cb:51:c2:98:04:81:
20:a7:ae:f9:72:ff:5b:f9:78:68:cf:0f:48:c9 24:8a:51:13:50:b1:75:b2:2f:9d:a8:b4:f4:b9
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h MIIBcDCB9qADAgECAgQLhwoxMAoGCCqGSM49BAMCMCYxJDAiBgNVBAMMG2hpZ2h3
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0yMTA0MTMyMTQwMTZaFw0yMzA0MTMy
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX MTQwMTZaMCgxJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBNQVNB
DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S54kT4yfkbBxumdHOcHrps
cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l qbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpaMQMA4w
eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5 DAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEArsthLdRcjW6GqgsGHcbT
4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf YLoyczYl0yOFSYcczpQjeRqeQVUkHRUioUi7CsCrPBNzAjEAhjxns5Wi4uX5rfkd
WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA nME0Mnj1z+rVRwOfAL/QWctRwpgEgSSKURNQsXWyL52otPS5
vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6
AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP
D0jJ
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registrar Certificate Authority</name> <name>Registrar Certification Authority</name>
<t> <t>
This Certificate Authority enrolls the pledge once it is This CA enrolls the pledge once it is
authorized, and it also signs the Registrar's certificate. authorized, and it also signs the registrar's certificate.
</t> </t>
<sourcecode name="ownerca_secp384r1.key" type="" markers="true"><![CDA TA[ <sourcecode name="ownerca_secp384r1.key" type="example-crypto-material " markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R
EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW
gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd
0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ= 0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ=
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></sourcecode> ]]></sourcecode>
<t> <t>
The public key is indicated in a pledge voucher-request to show prox imity. The public key is indicated in a pledge voucher-request to show prox imity.
</t> </t>
<t keepWithPrevious="true">file: examples/ownerca_secp384r1.key</t> <t keepWithPrevious="true">file: examples/ownerca_secp384r1.key</t>
<sourcecode name="ownerca_secp384r1.cert" type="" markers="true"><![CD ATA[ <sourcecode name="ownerca_secp384r1.cert" type="example-crypto-materia l" markers="true"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 694879833 (0x296b0659) Serial Number: 694879833 (0x296b0659)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Issuer: DC = ca, DC = sandelman,
Fountain Root CA CN = fountain-test.example.com Unstrung Fountain Root CA
Validity Validity
Not Before: Feb 25 21:31:45 2020 GMT Not Before: Feb 25 21:31:45 2020 GMT
Not After : Feb 24 21:31:45 2022 GMT Not After : Feb 24 21:31:45 2022 GMT
Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrun Subject: DC = ca, DC = sandelman,
g Fountain Root CA CN = fountain-test.example.com Unstrung Fountain Root CA
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit) Public-Key: (384 bit)
pub: pub:
04:1b:7f:59:ba:17:c3:1a:bc:66:8d:8c:6c:e0:c3: 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: 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: 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: 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: 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: f0:bf:f5:ca:8f:30:01:7f:f8:c2:5f:d3:f5:20:03:
44:8b:8b:f2:07:6c:b4 44:8b:8b:f2:07:6c:b4
ASN1 OID: secp384r1 ASN1 OID: secp384r1
NIST CURVE: P-384 NIST CURVE: P-384
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Key Usage: critical X509v3 Key Usage: critical
Certificate Sign, CRL Sign Certificate Sign, CRL Sign
X509v3 Subject Key Identifier: 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: X509v3 Authority Key Identifier:
keyid:B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC:87:B3:74:2 keyid:B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:
6 10:BC:87:B3:74:26
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:64:02:30:20:83:06:ce:8d:98:a4:54:7a:66:4c:4a:3a:70: 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: 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: 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: 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: 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 ea:02:a4:5f:17:51:26:fb:d9:2f:d2:5c
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIICazCCAfKgAwIBAgIEKWsGWTAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB MIICazCCAfKgAwIBAgIEKWsGWTAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB
skipping to change at line 6221 skipping to change at line 5654
29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR23dLw 29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR23dLw
v/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud v/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud
DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0j DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0j
BBgwFoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMG BBgwFoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMG
zo2YpFR6ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBv zo2YpFR6ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBv
OPmvEu0w1YUpfLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lw= OPmvEu0w1YUpfLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lw=
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registrar key pair</name> <name>Registrar Key Pair</name>
<t> <t>
The Registrar is the representative of the domain owner. The registrar is the representative of the domain owner.
This key signs registrar voucher-requests, and terminates This key signs registrar voucher-requests and terminates
the TLS connection from the pledge. the TLS connection from the pledge.
</t> </t>
<sourcecode name="jrc_prime256v1.key" type="" markers="true"><![CDATA[ <sourcecode name="jrc_prime256v1.key" type="example-crypto-material" m arkers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49
AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E
jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></sourcecode> ]]></sourcecode>
<t> <t>
The public key is indicated in a pledge voucher-request to show prox imity. The public key is indicated in a pledge voucher-request to show prox imity.
</t> </t>
<sourcecode name="jrc_prime256v1.cert" type="" markers="true"><![CDATA [ <sourcecode name="jrc_prime256v1.cert" type="example-crypto-material" markers="true"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 1066965842 (0x3f989b52) Serial Number: 1066965842 (0x3f989b52)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Issuer: DC = ca, DC = sandelman,
Fountain Root CA CN = fountain-test.example.com Unstrung Fountain Root CA
Validity Validity
Not Before: Feb 25 21:31:54 2020 GMT Not Before: Feb 25 21:31:54 2020 GMT
Not After : Feb 24 21:31:54 2022 GMT Not After : Feb 24 21:31:54 2022 GMT
Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com Subject: DC = ca, DC = sandelman,
CN = fountain-test.example.com
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:96:65:50:72:34:ba:9f:e5:dd:e6:5f:f6:f0:81: 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: 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: 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: c9:88:8d:15:b4:42:1f:d7:f2:6a:b7:e4:ce:05:f8:
a7:4c:d3:8b:3a a7:4c:d3:8b:3a
ASN1 OID: prime256v1 ASN1 OID: prime256v1
skipping to change at line 6287 skipping to change at line 5722
aW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZl aW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZl
UHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRC UHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRC
H9fyarfkzgX4p0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1Ud H9fyarfkzgX4p0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1Ud
DwEB/wQEAwIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaH DwEB/wQEAwIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaH
myPAvLvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAd myPAvLvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAd
I8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U= I8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U=
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Pledge key pair</name> <name>Pledge Key Pair</name>
<t> <t>
The pledge has an IDevID key pair built in at manufacturing time: The pledge has an IDevID key pair built in at manufacturing time:
</t> </t>
<sourcecode name="idevid_00-D0-E5-F2-00-02.key" type="" markers="true" ><![CDATA[ <sourcecode name="idevid_00-D0-E5-F2-00-02.key" type="example-crypto-m aterial" markers="true"><![CDATA[
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49 MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49
AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx
FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw== FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></sourcecode> ]]></sourcecode>
<t> <t>
The certificate is used by the registrar to find the MASA. The certificate is used by the registrar to find the MASA.
</t> </t>
<sourcecode name="idevid_00-D0-E5-F2-00-02.cert" type="" markers="true "><![CDATA[ <sourcecode name="idevid_00-D0-E5-F2-00-02.cert" type="example-crypto- material" markers="true"><![CDATA[
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 226876461 (0xd85dc2d) Serial Number: 521731815 (0x1f18fee7)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.exam ple.com CA Issuer: CN = highway-test.example.com CA
Validity Validity
Not Before: Feb 3 06:47:20 2020 GMT Not Before: Apr 27 18:29:30 2021 GMT
Not After : Dec 31 00:00:00 2999 GMT Not After : Dec 31 00:00:00 2999 GMT
Subject: serialNumber = 00-D0-E5-F2-00-02 Subject: serialNumber = 00-D0-E5-F2-00-02
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:03:a3:75:43:87:b3:7c:c0:0a:9a:87:9c:ad:f6: 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: 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: 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: 7d:80:b1:a7:d9:3b:13:50:9b:a6:27:a5:4f:c3:96:
7f:4c:fe:21:27 7f:4c:fe:21:27
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: 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: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
1.3.6.1.5.5.7.1.32: 1.3.6.1.5.5.7.1.32:
..highway-test.example.com:9443 ..highway-test.example.com:9443
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:65:02:30:23:e1:a9:2e:ef:22:12:34:5a:a5:c2:15:d6:28: 30:65:02:30:62:2a:db:be:34:f7:1b:cb:85:de:26:8e:43:00:
bd:ed:3d:96:d6:ce:04:95:ef:a7:c8:dc:18:a8:31:c7:b8:04: f9:0d:88:c8:77:a8:dd:3c:08:40:54:bc:ec:3d:b6:dc:70:2b:
34:f2:b7:4d:79:8a:67:22:24:03:4f:c5:cd:d6:06:ba:02:31: c3:7f:ca:19:21:9a:a0:ab:c5:51:8e:aa:df:36:de:8b:02:31:
00:b3:8d:5c:0a:d0:fe:04:83:90:d3:4f:6d:72:97:b3:3e:02: 00:b2:5d:59:f8:47:c7:ed:03:97:a8:c0:c7:a8:81:fa:a8:86:
ea:f1:c8:5a:32:72:58:b7:45:02:50:78:bc:04:1d:23:5e:22: ed:67:64:37:51:7a:6e:9c:a3:82:4d:6d:ad:bc:f3:35:9e:9d:
6f:c3:7f:8c:7c:d7:9b:70:20:91:b4:e1:7f 6a:a2:6d:7f:7f:25:1c:03:ef:f0:ba:9b:71
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIB5jCCAWygAwIBAgIEDYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h MIIBrzCCATWgAwIBAgIEHxj+5zAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdo
ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE d2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwIBcNMjEwNDI3MTgyOTMwWhgPMjk5OTEy
AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoY MzEwMDAwMDBaMBwxGjAYBgNVBAUTETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZI
DzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZ zj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsT
MBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/g SyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYE
QE5BefBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0G FEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYd
A1UdDgQWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUF aGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDaAAwZQIw
BwEgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMC YirbvjT3G8uF3iaOQwD5DYjId6jdPAhAVLzsPbbccCvDf8oZIZqgq8VRjqrfNt6L
A2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TXmKZyIk AjEAsl1Z+EfH7QOXqMDHqIH6qIbtZ2Q3UXpunKOCTW2tvPM1np1qom1/fyUcA+/w
A0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vAQdI14ib8N/ uptx
jHzXm3AgkbThfw==
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="exampleprocess" numbered="true" toc="default"> <section anchor="exampleprocess" numbered="true" toc="default">
<name>Example process</name> <name>Example Process</name>
<t> <t>
The JSON examples below are wrapped at 60 columns. The JSON examples below are wrapped at 60 columns.
This results in strings that have newlines in them, which This results in strings that have newlines in them, which
makes them invalid JSON as is. The strings would otherwise makes them invalid JSON as is. The strings would otherwise
be too long, so they need to be unwrapped before processing. be too long, so they need to be unwrapped before processing.
</t> </t>
<t> <t>
For readability, the output of the asn1parse has been truncated at For readability, the output of the asn1parse has been truncated at
72 columns rather than wrapped. 68 columns rather than wrapped.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Pledge to Registrar</name> <name>Pledge to Registrar</name>
<t> <t>
As described in <xref target="RequestVoucherFromRegistrar" format="d efault"/>, As described in <xref target="RequestVoucherFromRegistrar" format="d efault"/>,
the pledge will sign a pledge voucher-request containing the the pledge will sign a pledge voucher-request containing the
registrar's public key in the proximity-registrar-cert field. registrar's public key in the proximity-registrar-cert field.
The base64 has been wrapped at 60 characters for presentation reason s. The base64 has been wrapped at 60 characters for presentation reason s.
</t> </t>
<sourcecode name="vr_00-D0-E5-F2-00-02.b64" type="" markers="true"><![ CDATA[ <sourcecode name="vr_00-D0-E5-F2-00-02.b64" type="" markers="true"><![ CDATA[
MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGg MIIGcAYJKoZIhvcNAQcCoIIGYTCCBl0CAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG
ggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3Nl
aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLCJzZXJp cnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0Mzoy
YWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6ImFNamd1ZUtVVC0yMndWaW1q My43NDctMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJu
NnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1 b25jZSI6Ii1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFy
aWJVakFLQmdncWhrak9QUVFEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdv LWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUVFEQWpC
SmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJs dE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYUprL0lzWkFFWkZn
YzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVG bHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJsYzNRdVpYaGhi
dzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsv WEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5
SXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFV TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lh
RUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VH SmsvSXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJq
Q0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNCYitsSW5vRU1FZ2M3Um8rWFpDdGpB RWlNQ0FHQTFVRUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpN
STBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0Ex Qk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNC
VWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtq YitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlm
T1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2 eWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3
WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhT TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtqT1BRUURBZ05vQURCbEFqQm1U
OFhBUjVrMUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIE MkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212
DYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW8xEjAQ RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVr
BgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAX MUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggGyMIIBrjCCATWgAwIBAgIE
DTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0w DYOv2TAKBggqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5j
MC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5B b20gQ0EwIBcNMjEwNDEzMjAzNzM5WhgPMjk5OTEyMzEwMDAwMDBaMBwxGjAYBgNVBAUM
efBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDgQWBBRFiMyW ETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEA6N1Q4ez
lgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBwEgBB8MHWhpZ2h3YXktdGVzdC5l fMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLxFjDOuwB9gLGn2TsTUJumJ6VP
eGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXv w5Z/TP4hJ6NZMFcwHQYDVR0OBBYEFEWIzJaWAGQ3sLojZWRkVAgGbFatMAkGA1UdEwQC
p8jcGKgxx7gENPK3TXmKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4 MAAwKwYIKwYBBQUHASAEHxYdaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYI
vAQdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYD KoZIzj0EAwIDZwAwZAIwTmlG8sXkKGNbwbKQcYMapFbmSbnHHURFUoFuRqvbgYX7FlXp
VQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l BczfwF2kllNuujigAjAow1kc4r55EmiH+OMEXjBNlWlBSZC5QuJjEf0Jsmxssc+pucjO
eGFtcGxlLmNvbSBDQQIEDYXcLTALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN J4ShqnexMEy7bjAxggEEMIIBAAIBATAuMCYxJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l
AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6IrwstHF eGFtcGxlLmNvbSBDQQIEDYOv2TALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJ
609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIBxwA1UlkIkuQDf/j7kZ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MTMyMTQzMjNaMC8GCSqGSIb3DQEJ
/MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bmiEUpefCEhxSv2xLYurGlugv0dfr/E= BDEiBCBJwhyYibIjeqeR3bOaLURzMlGrc3F2X+kvJ1errtoCtTAKBggqhkjOPQQDAgRH
MEUCIQCmYuCE61HFQXH/E16GDOCsVquDtgr+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2
vZFQAKXUbimkiHKzXBA8md0VHbU=
]]></sourcecode> ]]></sourcecode>
<t> <t>
The ASN1 decoding of the artifact: The ASN1 decoding of the artifact:
</t> </t>
<t keepWithPrevious="true">file: examples/vr_00-D0-E5-F2-00-02.b64</t> <t keepWithPrevious="true">file: examples/vr_00-D0-E5-F2-00-02.b64</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0:d=0 hl=4 l=1759 cons: SEQUENCE 0:d=0 hl=4 l=1648 cons: SEQUENCE
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=1744 cons: cont [ 0 ] 15:d=1 hl=4 l=1633 cons: cont [ 0 ]
19:d=2 hl=4 l=1740 cons: SEQUENCE 19:d=2 hl=4 l=1629 cons: SEQUENCE
23:d=3 hl=2 l= 1 prim: INTEGER :01 23:d=3 hl=2 l= 1 prim: INTEGER :01
26:d=3 hl=2 l= 13 cons: SET 26:d=3 hl=2 l= 13 cons: SET
28:d=4 hl=2 l= 11 cons: SEQUENCE 28:d=4 hl=2 l= 11 cons: SEQUENCE
30:d=5 hl=2 l= 9 prim: OBJECT :sha256 30:d=5 hl=2 l= 9 prim: OBJECT :sha256
41:d=3 hl=4 l= 905 cons: SEQUENCE 41:d=3 hl=4 l= 905 cons: SEQUENCE
45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
56:d=4 hl=4 l= 890 cons: cont [ 0 ] 56:d=4 hl=4 l= 890 cons: cont [ 0 ]
60:d=5 hl=4 l= 886 prim: OCTET STRING :{"ietf-voucher-request:v 60:d=5 hl=4 l= 886 prim: OCTET STRING :{"ietf-voucher-request:v
950:d=3 hl=4 l= 490 cons: cont [ 0 ] 950:d=3 hl=4 l= 434 cons: cont [ 0 ]
954:d=4 hl=4 l= 486 cons: SEQUENCE 954:d=4 hl=4 l= 430 cons: SEQUENCE
958:d=5 hl=4 l= 364 cons: SEQUENCE 958:d=5 hl=4 l= 309 cons: SEQUENCE
962:d=6 hl=2 l= 3 cons: cont [ 0 ] 962:d=6 hl=2 l= 3 cons: cont [ 0 ]
964:d=7 hl=2 l= 1 prim: INTEGER :02 964:d=7 hl=2 l= 1 prim: INTEGER :02
967:d=6 hl=2 l= 4 prim: INTEGER :0D85DC2D 967:d=6 hl=2 l= 4 prim: INTEGER :0D83AFD9
973:d=6 hl=2 l= 10 cons: SEQUENCE 973:d=6 hl=2 l= 10 cons: SEQUENCE
975:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 975:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
985:d=6 hl=2 l= 93 cons: SEQUENCE 985:d=6 hl=2 l= 38 cons: SEQUENCE
987:d=7 hl=2 l= 15 cons: SET 987:d=7 hl=2 l= 36 cons: SET
989:d=8 hl=2 l= 13 cons: SEQUENCE 989:d=8 hl=2 l= 34 cons: SEQUENCE
991:d=9 hl=2 l= 3 prim: OBJECT :countryName 991:d=9 hl=2 l= 3 prim: OBJECT :commonName
996:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 996:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com
1004:d=7 hl=2 l= 16 cons: SET 1025:d=6 hl=2 l= 32 cons: SEQUENCE
1006:d=8 hl=2 l= 14 cons: SEQUENCE 1027:d=7 hl=2 l= 13 prim: UTCTIME :210413203739Z
1008:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1042:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z
1013:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1059:d=6 hl=2 l= 28 cons: SEQUENCE
1022:d=7 hl=2 l= 18 cons: SET 1061:d=7 hl=2 l= 26 cons: SET
1024:d=8 hl=2 l= 16 cons: SEQUENCE 1063:d=8 hl=2 l= 24 cons: SEQUENCE
1026:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1065:d=9 hl=2 l= 3 prim: OBJECT :serialNumber
1031:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1070:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2-00-02
1042:d=7 hl=2 l= 36 cons: SET 1089:d=6 hl=2 l= 89 cons: SEQUENCE
1044:d=8 hl=2 l= 34 cons: SEQUENCE 1091:d=7 hl=2 l= 19 cons: SEQUENCE
1046:d=9 hl=2 l= 3 prim: OBJECT :commonName 1093:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
1051:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 1102:d=8 hl=2 l= 8 prim: OBJECT :prime256v1
1080:d=6 hl=2 l= 32 cons: SEQUENCE 1112:d=7 hl=2 l= 66 prim: BIT STRING
1082:d=7 hl=2 l= 13 prim: UTCTIME :200203064720Z 1180:d=6 hl=2 l= 89 cons: cont [ 3 ]
1097:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z 1182:d=7 hl=2 l= 87 cons: SEQUENCE
1114:d=6 hl=2 l= 28 cons: SEQUENCE 1184:d=8 hl=2 l= 29 cons: SEQUENCE
1116:d=7 hl=2 l= 26 cons: SET 1186:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident
1118:d=8 hl=2 l= 24 cons: SEQUENCE 1191:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04144588CC9696
1120:d=9 hl=2 l= 3 prim: OBJECT :serialNumber 1215:d=8 hl=2 l= 9 cons: SEQUENCE
1125:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2-00-02 1217:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
1144:d=6 hl=2 l= 89 cons: SEQUENCE 1222:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
1146:d=7 hl=2 l= 19 cons: SEQUENCE 1226:d=8 hl=2 l= 43 cons: SEQUENCE
1148:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 1228:d=9 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.1.32
1157:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 1238:d=9 hl=2 l= 31 prim: OCTET STRING [HEX DUMP]:161D6869676877
1167:d=7 hl=2 l= 66 prim: BIT STRING 1271:d=5 hl=2 l= 10 cons: SEQUENCE
1235:d=6 hl=2 l= 89 cons: cont [ 3 ] 1273:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1237:d=7 hl=2 l= 87 cons: SEQUENCE 1283:d=5 hl=2 l= 103 prim: BIT STRING
1239:d=8 hl=2 l= 29 cons: SEQUENCE 1388:d=3 hl=4 l= 260 cons: SET
1241:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 1392:d=4 hl=4 l= 256 cons: SEQUENCE
1246:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04144588CC9696 1396:d=5 hl=2 l= 1 prim: INTEGER :01
1270:d=8 hl=2 l= 9 cons: SEQUENCE 1399:d=5 hl=2 l= 46 cons: SEQUENCE
1272:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1401:d=6 hl=2 l= 38 cons: SEQUENCE
1277:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 1403:d=7 hl=2 l= 36 cons: SET
1281:d=8 hl=2 l= 43 cons: SEQUENCE 1405:d=8 hl=2 l= 34 cons: SEQUENCE
1283:d=9 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.1.32 1407:d=9 hl=2 l= 3 prim: OBJECT :commonName
1293:d=9 hl=2 l= 31 prim: OCTET STRING [HEX DUMP]:0C1D6869676877 1412:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com
1326:d=5 hl=2 l= 10 cons: SEQUENCE 1441:d=6 hl=2 l= 4 prim: INTEGER :0D83AFD9
1328:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1447:d=5 hl=2 l= 11 cons: SEQUENCE
1338:d=5 hl=2 l= 104 prim: BIT STRING 1449:d=6 hl=2 l= 9 prim: OBJECT :sha256
1444:d=3 hl=4 l= 315 cons: SET 1460:d=5 hl=2 l= 105 cons: cont [ 0 ]
1448:d=4 hl=4 l= 311 cons: SEQUENCE 1462:d=6 hl=2 l= 24 cons: SEQUENCE
1452:d=5 hl=2 l= 1 prim: INTEGER :01 1464:d=7 hl=2 l= 9 prim: OBJECT :contentType
1455:d=5 hl=2 l= 101 cons: SEQUENCE 1475:d=7 hl=2 l= 11 cons: SET
1457:d=6 hl=2 l= 93 cons: SEQUENCE 1477:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1459:d=7 hl=2 l= 15 cons: SET 1488:d=6 hl=2 l= 28 cons: SEQUENCE
1461:d=8 hl=2 l= 13 cons: SEQUENCE 1490:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1463:d=9 hl=2 l= 3 prim: OBJECT :countryName 1501:d=7 hl=2 l= 15 cons: SET
1468:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1503:d=8 hl=2 l= 13 prim: UTCTIME :210413214323Z
1476:d=7 hl=2 l= 16 cons: SET 1518:d=6 hl=2 l= 47 cons: SEQUENCE
1478:d=8 hl=2 l= 14 cons: SEQUENCE 1520:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1480:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1531:d=7 hl=2 l= 34 cons: SET
1485:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1533:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:49C21C9889B223
1494:d=7 hl=2 l= 18 cons: SET 1567:d=5 hl=2 l= 10 cons: SEQUENCE
1496:d=8 hl=2 l= 16 cons: SEQUENCE 1569:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1498:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1579:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022100A662
1503:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman
1514:d=7 hl=2 l= 36 cons: SET
1516:d=8 hl=2 l= 34 cons: SEQUENCE
1518:d=9 hl=2 l= 3 prim: OBJECT :commonName
1523:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com
1552:d=6 hl=2 l= 4 prim: INTEGER :0D85DC2D
1558:d=5 hl=2 l= 11 cons: SEQUENCE
1560:d=6 hl=2 l= 9 prim: OBJECT :sha256
1571:d=5 hl=2 l= 105 cons: cont [ 0 ]
1573:d=6 hl=2 l= 24 cons: SEQUENCE
1575:d=7 hl=2 l= 9 prim: OBJECT :contentType
1586:d=7 hl=2 l= 11 cons: SET
1588:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1599:d=6 hl=2 l= 28 cons: SEQUENCE
1601:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1612:d=7 hl=2 l= 15 cons: SET
1614:d=8 hl=2 l= 13 prim: UTCTIME :200225230448Z
1629:d=6 hl=2 l= 47 cons: SEQUENCE
1631:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1642:d=7 hl=2 l= 34 cons: SET
1644:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:B1E88AF0B2D1C5
1678:d=5 hl=2 l= 10 cons: SEQUENCE
1680:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1690:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:304502201C7003
]]></artwork> ]]></artwork>
<t> <t>
The JSON contained in the voucher request: The JSON contained in the voucher-request:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{"ietf-voucher-request:voucher":{"assertion":"proximity","cr {"ietf-voucher-request:voucher":{"assertion":"proximity","cr
eated-on":"2020-02-25T18:04:48.652-05:00","serial-number":"0 eated-on":"2021-04-13T17:43:23.747-04:00","serial-number":"0
0-D0-E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","proximit 0-D0-E5-F2-00-02","nonce":"-_XE9zK9q8Ll1qylMtLKeg","proximit
y-registrar-cert":"MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDA y-registrar-cert":"MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDA
jBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZ jBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZ
WxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zd WxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zd
HJ1bmcgRm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNTRaFw0yMjAyM HJ1bmcgRm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNTRaFw0yMjAyM
jQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkA jQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkA
RkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRhaW4tdGVzdC5leGFtcGxlL RkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRhaW4tdGVzdC5leGFtcGxlL
mNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb mNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb
+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p +lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p
0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1UdDwEB/wQEA 0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1UdDwEB/wQEA
wIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaHmyPAv wIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaHmyPAv
Lvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAdI Lvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAdI
8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}}]]></artwork> 8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}}
</sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registrar to MASA</name> <name>Registrar to MASA</name>
<t> <t>
As described in <xref target="RequestVoucherFromMASA" format="defaul As described in <xref target="RequestVoucherFromMASA" format="defaul
t"/> t"/>,
the registrar will sign a registrar voucher-request, and will the registrar will sign a registrar voucher-request and will
include pledge's voucher request in the prior-signed-voucher-request include the pledge's voucher-request in the prior-signed-voucher-req
. uest.
</t> </t>
<sourcecode name="parboiled_vr_00-D0-E5-F2-00-02.b64" type="" markers= "true"><![CDATA[ <sourcecode name="parboiled_vr_00-D0-E5-F2-00-02.b64" type="" markers= "true"><![CDATA[
MIIP9wYJKoZIhvcNAQcCoIIP6DCCD+QCAQExDTALBglghkgBZQMEAgEwggoMBgkqhkiG9w0BBwGg MIIPYwYJKoZIhvcNAQcCoIIPVDCCD1ACAQExDTALBglghkgBZQMEAgEwggl4BgkqhkiG
ggn9BIIJ+XsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 9w0BBwGggglpBIIJZXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3Nl
aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQyMzowNDo0OS4wNTRaIiwic2VyaWFsLW51 cnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QyMTo0Mzoy
bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdR My43ODdaIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2Ui
IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6Ik1JSUczd1lKS29aSWh2Y05BUWNDb0lJ OiItX1hFOXpLOXE4TGwxcXlsTXRMS2VnIiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVx
RzBEQ0NCc3dDQVFFeERUQUxCZ2xnaGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042 dWVzdCI6Ik1JSUdjQVlKS29aSWh2Y05BUWNDb0lJR1lUQ0NCbDBDQVFFeERUQUxCZ2xn
QklJRGRuc2lhV1YwWmkxMmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxj aGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042QklJRGRuc2lhV1YwWmkx
blJwYjI0aU9pSndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNQzB3TWkweU5W MmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxjblJwYjI0aU9p
UXhPRG93TkRvME9DNDJOVEl0TURVNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0UkRB SndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNUzB3TkMweE0xUXhO
dFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJbUZOYW1kMVpVdFZWQzB5TW5kV2FXMXFObm95 em8wTXpveU15NDNORGN0TURRNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0
TjFFaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9pSk5TVWxDTDBSRFEwRlpT UkRBdFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJaTFmV0VVNWVrczVjVGhNYkRG
MmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFVVkZFUVdwQ2RFMVNTWGRGUVZsTFEx eGVXeE5kRXhMWldjaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9p
cEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZUW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhw Sk5TVWxDTDBSRFEwRlpTMmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFV
WlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1kT1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5S VkZFUVdwQ2RFMVNTWGRGUVZsTFExcEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZ
ZFZwWWFHaGlXRUp6V2xNMWFtSXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZi UW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhwWlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1k
VGwyWkVOQ1JGRlVRV1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVV T1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5SZFZwWWFHaGlXRUp6V2xNMWFt
MVVUWGhPVkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O SXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZiVGwyWkVOQ1JGRlVR
SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFURlZSVUYz V1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVVMVVUWGhP
ZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9kbUpVUWxwTlFrMUhR VkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O
bmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpLV214VlNFa3dkWEF2YkRObFdt SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFU
WTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdwQlNUQkRSREZtU21aS1VpOW9TWGw1Ukcx RlZSVUYzZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9k
SVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10NloxZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JL bUpVUWxwTlFrMUhRbmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpL
VVVWQ0wzZFJUVTFCYjBkRFEzTkhRVkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpT V214VlNFa3dkWEF2YkRObFdtWTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdw
R2RFUVV0Q1oyZHhhR3RxVDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVp QlNUQkRSREZtU21aS1VpOW9TWGw1UkcxSVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10Nlox
czFlVUpMVGxKVVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cx ZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JLVVVWQ0wzZFJUVTFCYjBkRFEzTkhR
U2Eyb3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRPRmhC VkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpTR2RFUVV0Q1oyZHhhR3Rx
VWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJnZ2dIcU1JSUI1 VDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVpczFlVUpMVGxK
akNDQVd5Z0F3SUJBZ0lFRFlYY0xUQUtCZ2dxaGtqT1BRUURBakJkTVE4d0RRWURWUVFHRXdaRFlX VVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cxU2Ey
NWhaR0V4RURBT0JnTlZCQWdNQjA5dWRHRnlhVzh4RWpBUUJnTlZCQXNNQ1ZOaGJtUmxiRzFoYmpF b3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRP
a01DSUdBMVVFQXd3YmFHbG5hSGRoZVMxMFpYTjBMbVY0WVcxd2JHVXVZMjl0SUVOQk1DQVhEVEl3 RmhCVWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJn
TURJd016QTJORGN5TUZvWUR6STVPVGt4TWpNeE1EQXdNREF3V2pBY01Sb3dHQVlEVlFRRkRCRXdN Z2dHeU1JSUJyakNDQVRXZ0F3SUJBZ0lFRFlPdjJUQUtCZ2dxaGtqT1BRUURBakFtTVNR
QzFFTUMxRk5TMUdNaTB3TUMwd01qQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJB d0lnWURWUVFEREJ0b2FXZG9kMkY1TFhSbGMzUXVaWGhoYlhCc1pTNWpiMjBnUTBFd0lC
T2pkVU9IczN6QUNwcUhuSzMyOURnVEhOUU1oQi9nUUU1QmVmQmJFMHNnY2JORW0wbGk4Ull3enJz Y05NakV3TkRFek1qQXpOek01V2hnUE1qazVPVEV5TXpFd01EQXdNREJhTUJ3eEdqQVlC
QWZZQ3hwOWs3RTFDYnBpZWxUOE9XZjB6K0lTZWpXVEJYTUIwR0ExVWREZ1FXQkJSRmlNeVdsZ0Jr Z05WQkFVTUVUQXdMVVF3TFVVMUxVWXlMVEF3TFRBeU1Ga3dFd1lIS29aSXpqMENBUVlJ
TjdDNkkyVmtaRlFJQm14V3JUQUpCZ05WSFJNRUFqQUFNQ3NHQ0NzR0FRVUZCd0VnQkI4TUhXaHBa S29aSXpqMERBUWNEUWdBRUE2TjFRNGV6Zk1BS21vZWNyZmIwT0JNYzFBeUVIK0JBVGtG
MmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlRvNU5EUXpNQW9HQ0NxR1NNNDlCQU1DQTJnQU1H NThGc1RTeUJ4czBTYlNXTHhGakRPdXdCOWdMR24yVHNUVUp1bUo2VlB3NVovVFA0aEo2
VUNNQ1BocVM3dkloSTBXcVhDRmRZb3ZlMDlsdGJPQkpYdnA4amNHS2d4eDdnRU5QSzNUWG1LWnlJ TlpNRmN3SFFZRFZSME9CQllFRkVXSXpKYVdBR1Ezc0xvalpXUmtWQWdHYkZhdE1Ba0dB
a0EwL0Z6ZFlHdWdJeEFMT05YQXJRL2dTRGtOTlBiWEtYc3o0QzZ2SElXakp5V0xkRkFsQjR2QVFk MVVkRXdRQ01BQXdLd1lJS3dZQkJRVUhBU0FFSHhZZGFHbG5hSGRoZVMxMFpYTjBMbVY0
STE0aWI4Ti9qSHpYbTNBZ2tiVGhmekdDQVRzd2dnRTNBZ0VCTUdVd1hURVBNQTBHQTFVRUJoTUdR WVcxd2JHVXVZMjl0T2prME5ETXdDZ1lJS29aSXpqMEVBd0lEWndBd1pBSXdUbWxHOHNY
MkZ1WVdSaE1SQXdEZ1lEVlFRSURBZFBiblJoY21sdk1SSXdFQVlEVlFRTERBbFRZVzVrWld4dFlX a0tHTmJ3YktRY1lNYXBGYm1TYm5ISFVSRlVvRnVScXZiZ1lYN0ZsWHBCY3pmd0Yya2xs
NHhKREFpQmdOVkJBTU1HMmhwWjJoM1lYa3RkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJTQkRRUUlFRFlY TnV1amlnQWpBb3cxa2M0cjU1RW1pSCtPTUVYakJObFdsQlNaQzVRdUpqRWYwSnNteHNz
Y0xUQUxCZ2xnaGtnQlpRTUVBZ0dnYVRBWUJna3Foa2lHOXcwQkNRTXhDd1lKS29aSWh2Y05BUWNC YytwdWNqT0o0U2hxbmV4TUV5N2JqQXhnZ0VFTUlJQkFBSUJBVEF1TUNZeEpEQWlCZ05W
TUJ3R0NTcUdTSWIzRFFFSkJURVBGdzB5TURBeU1qVXlNekEwTkRoYU1DOEdDU3FHU0liM0RRRUpC QkFNTUcyaHBaMmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlNCRFFRSUVEWU92MlRB
REVpQkNDeDZJcndzdEhGNjA5WTBFcURLNjJRS2J5NGR1eXlJV3VkdnMxNU0xNkJCVEFLQmdncWhr TEJnbGdoa2dCWlFNRUFnR2dhVEFZQmdrcWhraUc5dzBCQ1FNeEN3WUpLb1pJaHZjTkFR
ak9QUVFEQWdSSE1FVUNJQnh3QTFVbGtJa3VRRGYvajdrWi9NVmVmZ3IxNDEraEtCRmdybk5uZ2p3 Y0JNQndHQ1NxR1NJYjNEUUVKQlRFUEZ3MHlNVEEwTVRNeU1UUXpNak5hTUM4R0NTcUdT
cEFpRUF5OGFYdDBHU0I5bTFibWlFVXBlZkNFaHhTdjJ4TFl1ckdsdWd2MGRmci9FPSJ9faCCBG8w SWIzRFFFSkJERWlCQ0JKd2h5WWliSWplcWVSM2JPYUxVUnpNbEdyYzNGMlgra3ZKMWVy
ggH8MIIBgqADAgECAgQ/mJtSMAoGCCqGSM49BAMCMG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcG cnRvQ3RUQUtCZ2dxaGtqT1BRUURBZ1JITUVVQ0lRQ21ZdUNFNjFIRlFYSC9FMTZHRE9D
CgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNv c1ZxdUR0Z3IrUS82L0R1LzlRa3pBN2dJZ2Y3TUZoQUlQVzJQTndSYTJ2WkZRQUtYVWJp
bSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTIwMDIyNTIxMzE1NFoXDTIyMDIyNDIxMzE1 bWtpSEt6WEJBOG1kMFZIYlU9In19oIIEbzCCAfwwggGCoAMCAQICBD+Ym1IwCgYIKoZI
NFowUzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYD zj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVs
VQQDDBlmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE bWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tIFVuc3RydW5nIEZv
lmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0VtEIf1/Jqt+TO dW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTU0WhcNMjIwMjI0MjEzMTU0WjBTMRIw
BfinTNOLOqMqMCgwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAxwwDgYDVR0PAQH/BAQDAgeAMAoGCCqG EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xIjAgBgNV
SM49BAMCA2gAMGUCMGZPYExVSB6WB/jdH7nIEo1FNoebI8C8u/HLPSYVVm9fH7/VHA5qCa8bdpeZ BAMMGWZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMB
GSP9fgIxALysw0Gwug2vUvmcbnp/AB0jyGIBYbxLxcBHmTUKDHdhRAFKB1JwVwB1/74HDpjL5TCC BwNCAASWZVByNLqf5d3mX/bwgW/pSJ6BDBIHO0aPl2QrYwCNAg9XyXyUf4SMsg5h1smI
AmswggHyoAMCAQICBClrBlkwCgYIKoZIzj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK jRW0Qh/X8mq35M4F+KdM04s6oyowKDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDHDAOBgNV
CZImiZPyLGQBGRYJc2FuZGVsbWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29t HQ8BAf8EBAMCB4AwCgYIKoZIzj0EAwIDaAAwZQIwZk9gTFVIHpYH+N0fucgSjUU2h5sj
IFVuc3RydW5nIEZvdW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTQ1WhcNMjIwMjI0MjEzMTQ1 wLy78cs9JhVWb18fv9UcDmoJrxt2l5kZI/1+AjEAvKzDQbC6Da9S+Zxuen8AHSPIYgFh
WjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNV vEvFwEeZNQoMd2FEAUoHUnBXAHX/vgcOmMvlMIICazCCAfKgAwIBAgIEKWsGWTAKBggq
BAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTB2 hkjOPQQDAjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5k
MBAGByqGSM49AgEGBSuBBAAiA2IABBt/WboXwxq8Zo2MbODD+jFxD2X2IpG9t1aAB9vfuHqlRU15 ZWxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcg
ikaXGVmWMbGPaX0yvjzIPltjtUb2qNVvm/nA89O5FD9yR1Gkdt3S8L/1yo8wAX/4wl/T9SADRIuL Rm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0x
8gdstKNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLml9ssR EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoG
4QekSSynCMZ8ELyHs3QmMB8GA1UdIwQYMBaAFLml9ssR4QekSSynCMZ8ELyHs3QmMAoGCCqGSM49 A1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBS
BAMCA2cAMGQCMCCDBs6NmKRUemZMSjpwwlI2WlKNWX0gmyppFFiHONhVed39KTiVHpGTdrT1ZilE b290IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYi
tAIwbzj5rxLtMNWFKXyxFli9Z5FDxA0w+dgcrC8G3bzVBkIshKIE6gKkXxdRJvvZL9JcMYIBSzCC kb23VoAH29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR2
AUcCAQEwdTBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4x 3dLwv/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud
PDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9v DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0jBBgw
dCBDQQIEP5ibUjALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG FoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMGzo2YpFR6
SIb3DQEJBTEPFw0yMDAyMjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCA9gYxR1sS0giII3PwvOK/N ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBvOPmvEu0w1YUp
5RUBwjSL/cDcrH/Bd+E1ajAKBggqhkjOPQQDAgRHMEUCIFieXZaO7P9eZMpCVn2laB4czw7I0s0P fLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lwxggFLMIIBRwIBATB1
s9+frcJtEBTTAiEAhCcB//qmgqcEA+90mquvVNENmFH9dxCH8Ihhz6SCVDI= MG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8
MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFp
biBSb290IENBAgQ/mJtSMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQxMzIxNDMyM1owLwYJKoZIhvcNAQkEMSIE
IEnOrdWjlG70K74IhCJ7UXi+wPS+r2C8DFEqjabGP+G8MAoGCCqGSM49BAMCBEcwRQIh
AMhO3M+tSWb2wKTBOXPArN+XvjSzAhaQA/uLj3qhPwi/AiBDDthf6mjMuirqXE0yjMif
C2UY9oNUFF9Nl0wEQpBBAA==
]]></sourcecode> ]]></sourcecode>
<t> <t>
The ASN1 decoding of the artifact: The ASN1 decoding of the artifact:
</t> </t>
<t keepWithPrevious="true">file: examples/parboiled_vr_00_D0-E5-02-00- 2D.b64</t> <t keepWithPrevious="true">file: examples/parboiled_vr_00_D0-E5-02-00- 2D.b64</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0:d=0 hl=4 l=4087 cons: SEQUENCE 0:d=0 hl=4 l=3939 cons: SEQUENCE
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=4072 cons: cont [ 0 ] 15:d=1 hl=4 l=3924 cons: cont [ 0 ]
19:d=2 hl=4 l=4068 cons: SEQUENCE 19:d=2 hl=4 l=3920 cons: SEQUENCE
23:d=3 hl=2 l= 1 prim: INTEGER :01 23:d=3 hl=2 l= 1 prim: INTEGER :01
26:d=3 hl=2 l= 13 cons: SET 26:d=3 hl=2 l= 13 cons: SET
28:d=4 hl=2 l= 11 cons: SEQUENCE 28:d=4 hl=2 l= 11 cons: SEQUENCE
30:d=5 hl=2 l= 9 prim: OBJECT :sha256 30:d=5 hl=2 l= 9 prim: OBJECT :sha256
41:d=3 hl=4 l=2572 cons: SEQUENCE 41:d=3 hl=4 l=2424 cons: SEQUENCE
45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
56:d=4 hl=4 l=2557 cons: cont [ 0 ] 56:d=4 hl=4 l=2409 cons: cont [ 0 ]
60:d=5 hl=4 l=2553 prim: OCTET STRING :{"ietf-voucher-request:v 60:d=5 hl=4 l=2405 prim: OCTET STRING :{"ietf-voucher-request:v
2617:d=3 hl=4 l=1135 cons: cont [ 0 ] 2469:d=3 hl=4 l=1135 cons: cont [ 0 ]
2621:d=4 hl=4 l= 508 cons: SEQUENCE 2473:d=4 hl=4 l= 508 cons: SEQUENCE
2625:d=5 hl=4 l= 386 cons: SEQUENCE 2477:d=5 hl=4 l= 386 cons: SEQUENCE
2629:d=6 hl=2 l= 3 cons: cont [ 0 ] 2481:d=6 hl=2 l= 3 cons: cont [ 0 ]
2631:d=7 hl=2 l= 1 prim: INTEGER :02 2483:d=7 hl=2 l= 1 prim: INTEGER :02
2634:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 2486:d=6 hl=2 l= 4 prim: INTEGER :3F989B52
2640:d=6 hl=2 l= 10 cons: SEQUENCE 2492:d=6 hl=2 l= 10 cons: SEQUENCE
2642:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 2494:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
2652:d=6 hl=2 l= 109 cons: SEQUENCE 2504:d=6 hl=2 l= 109 cons: SEQUENCE
2654:d=7 hl=2 l= 18 cons: SET 2506:d=7 hl=2 l= 18 cons: SET
2656:d=8 hl=2 l= 16 cons: SEQUENCE 2508:d=8 hl=2 l= 16 cons: SEQUENCE
2658:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2510:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2670:d=9 hl=2 l= 2 prim: IA5STRING :ca 2522:d=9 hl=2 l= 2 prim: IA5STRING :ca
2674:d=7 hl=2 l= 25 cons: SET 2526:d=7 hl=2 l= 25 cons: SET
2676:d=8 hl=2 l= 23 cons: SEQUENCE 2528:d=8 hl=2 l= 23 cons: SEQUENCE
2678:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2530:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2690:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 2542:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
2701:d=7 hl=2 l= 60 cons: SET 2553:d=7 hl=2 l= 60 cons: SET
2703:d=8 hl=2 l= 58 cons: SEQUENCE 2555:d=8 hl=2 l= 58 cons: SEQUENCE
2705:d=9 hl=2 l= 3 prim: OBJECT :commonName 2557:d=9 hl=2 l= 3 prim: OBJECT :commonName
2710:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 2562:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co
2763:d=6 hl=2 l= 30 cons: SEQUENCE 2615:d=6 hl=2 l= 30 cons: SEQUENCE
2765:d=7 hl=2 l= 13 prim: UTCTIME :200225213154Z 2617:d=7 hl=2 l= 13 prim: UTCTIME :200225213154Z
2780:d=7 hl=2 l= 13 prim: UTCTIME :220224213154Z 2632:d=7 hl=2 l= 13 prim: UTCTIME :220224213154Z
2795:d=6 hl=2 l= 83 cons: SEQUENCE 2647:d=6 hl=2 l= 83 cons: SEQUENCE
2797:d=7 hl=2 l= 18 cons: SET 2649:d=7 hl=2 l= 18 cons: SET
2799:d=8 hl=2 l= 16 cons: SEQUENCE 2651:d=8 hl=2 l= 16 cons: SEQUENCE
2801:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2653:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2813:d=9 hl=2 l= 2 prim: IA5STRING :ca 2665:d=9 hl=2 l= 2 prim: IA5STRING :ca
2817:d=7 hl=2 l= 25 cons: SET 2669:d=7 hl=2 l= 25 cons: SET
2819:d=8 hl=2 l= 23 cons: SEQUENCE 2671:d=8 hl=2 l= 23 cons: SEQUENCE
2821:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2673:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
2833:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 2685:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
2844:d=7 hl=2 l= 34 cons: SET 2696:d=7 hl=2 l= 34 cons: SET
2846:d=8 hl=2 l= 32 cons: SEQUENCE 2698:d=8 hl=2 l= 32 cons: SEQUENCE
2848:d=9 hl=2 l= 3 prim: OBJECT :commonName 2700:d=9 hl=2 l= 3 prim: OBJECT :commonName
2853:d=9 hl=2 l= 25 prim: UTF8STRING :fountain-test.example.co 2705:d=9 hl=2 l= 25 prim: UTF8STRING :fountain-test.example.co
2880:d=6 hl=2 l= 89 cons: SEQUENCE 2732:d=6 hl=2 l= 89 cons: SEQUENCE
2882:d=7 hl=2 l= 19 cons: SEQUENCE 2734:d=7 hl=2 l= 19 cons: SEQUENCE
2884:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 2736:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
2893:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 2745:d=8 hl=2 l= 8 prim: OBJECT :prime256v1
2903:d=7 hl=2 l= 66 prim: BIT STRING 2755:d=7 hl=2 l= 66 prim: BIT STRING
2971:d=6 hl=2 l= 42 cons: cont [ 3 ] 2823:d=6 hl=2 l= 42 cons: cont [ 3 ]
2973:d=7 hl=2 l= 40 cons: SEQUENCE 2825:d=7 hl=2 l= 40 cons: SEQUENCE
2975:d=8 hl=2 l= 22 cons: SEQUENCE 2827:d=8 hl=2 l= 22 cons: SEQUENCE
2977:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usag 2829:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usag
2982:d=9 hl=2 l= 1 prim: BOOLEAN :255 2834:d=9 hl=2 l= 1 prim: BOOLEAN :255
2985:d=9 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B0601 2837:d=9 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B0601
2999:d=8 hl=2 l= 14 cons: SEQUENCE 2851:d=8 hl=2 l= 14 cons: SEQUENCE
3001:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 2853:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
3006:d=9 hl=2 l= 1 prim: BOOLEAN :255 2858:d=9 hl=2 l= 1 prim: BOOLEAN :255
3009:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020780 2861:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020780
3015:d=5 hl=2 l= 10 cons: SEQUENCE 2867:d=5 hl=2 l= 10 cons: SEQUENCE
3017:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 2869:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
3027:d=5 hl=2 l= 104 prim: BIT STRING 2879:d=5 hl=2 l= 104 prim: BIT STRING
3133:d=4 hl=4 l= 619 cons: SEQUENCE 2985:d=4 hl=4 l= 619 cons: SEQUENCE
3137:d=5 hl=4 l= 498 cons: SEQUENCE 2989:d=5 hl=4 l= 498 cons: SEQUENCE
3141:d=6 hl=2 l= 3 cons: cont [ 0 ] 2993:d=6 hl=2 l= 3 cons: cont [ 0 ]
3143:d=7 hl=2 l= 1 prim: INTEGER :02 2995:d=7 hl=2 l= 1 prim: INTEGER :02
3146:d=6 hl=2 l= 4 prim: INTEGER :296B0659 2998:d=6 hl=2 l= 4 prim: INTEGER :296B0659
3152:d=6 hl=2 l= 10 cons: SEQUENCE 3004:d=6 hl=2 l= 10 cons: SEQUENCE
3154:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3006:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
3164:d=6 hl=2 l= 109 cons: SEQUENCE 3016:d=6 hl=2 l= 109 cons: SEQUENCE
3166:d=7 hl=2 l= 18 cons: SET 3018:d=7 hl=2 l= 18 cons: SET
3168:d=8 hl=2 l= 16 cons: SEQUENCE 3020:d=8 hl=2 l= 16 cons: SEQUENCE
3170:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3022:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3182:d=9 hl=2 l= 2 prim: IA5STRING :ca 3034:d=9 hl=2 l= 2 prim: IA5STRING :ca
3186:d=7 hl=2 l= 25 cons: SET 3038:d=7 hl=2 l= 25 cons: SET
3188:d=8 hl=2 l= 23 cons: SEQUENCE 3040:d=8 hl=2 l= 23 cons: SEQUENCE
3190:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3042:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3202:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3054:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
3213:d=7 hl=2 l= 60 cons: SET 3065:d=7 hl=2 l= 60 cons: SET
3215:d=8 hl=2 l= 58 cons: SEQUENCE 3067:d=8 hl=2 l= 58 cons: SEQUENCE
3217:d=9 hl=2 l= 3 prim: OBJECT :commonName 3069:d=9 hl=2 l= 3 prim: OBJECT :commonName
3222:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3074:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co
3275:d=6 hl=2 l= 30 cons: SEQUENCE 3127:d=6 hl=2 l= 30 cons: SEQUENCE
3277:d=7 hl=2 l= 13 prim: UTCTIME :200225213145Z 3129:d=7 hl=2 l= 13 prim: UTCTIME :200225213145Z
3292:d=7 hl=2 l= 13 prim: UTCTIME :220224213145Z 3144:d=7 hl=2 l= 13 prim: UTCTIME :220224213145Z
3307:d=6 hl=2 l= 109 cons: SEQUENCE 3159:d=6 hl=2 l= 109 cons: SEQUENCE
3309:d=7 hl=2 l= 18 cons: SET 3161:d=7 hl=2 l= 18 cons: SET
3311:d=8 hl=2 l= 16 cons: SEQUENCE 3163:d=8 hl=2 l= 16 cons: SEQUENCE
3313:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3165:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3325:d=9 hl=2 l= 2 prim: IA5STRING :ca 3177:d=9 hl=2 l= 2 prim: IA5STRING :ca
3329:d=7 hl=2 l= 25 cons: SET 3181:d=7 hl=2 l= 25 cons: SET
3331:d=8 hl=2 l= 23 cons: SEQUENCE 3183:d=8 hl=2 l= 23 cons: SEQUENCE
3333:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3185:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3345:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3197:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
3356:d=7 hl=2 l= 60 cons: SET 3208:d=7 hl=2 l= 60 cons: SET
3358:d=8 hl=2 l= 58 cons: SEQUENCE 3210:d=8 hl=2 l= 58 cons: SEQUENCE
3360:d=9 hl=2 l= 3 prim: OBJECT :commonName 3212:d=9 hl=2 l= 3 prim: OBJECT :commonName
3365:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3217:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co
3418:d=6 hl=2 l= 118 cons: SEQUENCE 3270:d=6 hl=2 l= 118 cons: SEQUENCE
3420:d=7 hl=2 l= 16 cons: SEQUENCE 3272:d=7 hl=2 l= 16 cons: SEQUENCE
3422:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 3274:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
3431:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 3283:d=8 hl=2 l= 5 prim: OBJECT :secp384r1
3438:d=7 hl=2 l= 98 prim: BIT STRING 3290:d=7 hl=2 l= 98 prim: BIT STRING
3538:d=6 hl=2 l= 99 cons: cont [ 3 ] 3390:d=6 hl=2 l= 99 cons: cont [ 3 ]
3540:d=7 hl=2 l= 97 cons: SEQUENCE 3392:d=7 hl=2 l= 97 cons: SEQUENCE
3542:d=8 hl=2 l= 15 cons: SEQUENCE 3394:d=8 hl=2 l= 15 cons: SEQUENCE
3544:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 3396:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
3549:d=9 hl=2 l= 1 prim: BOOLEAN :255 3401:d=9 hl=2 l= 1 prim: BOOLEAN :255
3552:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF 3404:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF
3559:d=8 hl=2 l= 14 cons: SEQUENCE 3411:d=8 hl=2 l= 14 cons: SEQUENCE
3561:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 3413:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
3566:d=9 hl=2 l= 1 prim: BOOLEAN :255 3418:d=9 hl=2 l= 1 prim: BOOLEAN :255
3569:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106 3421:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106
3575:d=8 hl=2 l= 29 cons: SEQUENCE 3427:d=8 hl=2 l= 29 cons: SEQUENCE
3577:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 3429:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident
3582:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11 3434:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11
3606:d=8 hl=2 l= 31 cons: SEQUENCE 3458:d=8 hl=2 l= 31 cons: SEQUENCE
3608:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide 3460:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide
3613:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6 3465:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6
3639:d=5 hl=2 l= 10 cons: SEQUENCE 3491:d=5 hl=2 l= 10 cons: SEQUENCE
3641:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3493:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
3651:d=5 hl=2 l= 103 prim: BIT STRING 3503:d=5 hl=2 l= 103 prim: BIT STRING
3756:d=3 hl=4 l= 331 cons: SET 3608:d=3 hl=4 l= 331 cons: SET
3760:d=4 hl=4 l= 327 cons: SEQUENCE 3612:d=4 hl=4 l= 327 cons: SEQUENCE
3764:d=5 hl=2 l= 1 prim: INTEGER :01 3616:d=5 hl=2 l= 1 prim: INTEGER :01
3767:d=5 hl=2 l= 117 cons: SEQUENCE 3619:d=5 hl=2 l= 117 cons: SEQUENCE
3769:d=6 hl=2 l= 109 cons: SEQUENCE 3621:d=6 hl=2 l= 109 cons: SEQUENCE
3771:d=7 hl=2 l= 18 cons: SET 3623:d=7 hl=2 l= 18 cons: SET
3773:d=8 hl=2 l= 16 cons: SEQUENCE 3625:d=8 hl=2 l= 16 cons: SEQUENCE
3775:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3627:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3787:d=9 hl=2 l= 2 prim: IA5STRING :ca 3639:d=9 hl=2 l= 2 prim: IA5STRING :ca
3791:d=7 hl=2 l= 25 cons: SET 3643:d=7 hl=2 l= 25 cons: SET
3793:d=8 hl=2 l= 23 cons: SEQUENCE 3645:d=8 hl=2 l= 23 cons: SEQUENCE
3795:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3647:d=9 hl=2 l= 10 prim: OBJECT :domainComponent
3807:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3659:d=9 hl=2 l= 9 prim: IA5STRING :sandelman
3818:d=7 hl=2 l= 60 cons: SET 3670:d=7 hl=2 l= 60 cons: SET
3820:d=8 hl=2 l= 58 cons: SEQUENCE 3672:d=8 hl=2 l= 58 cons: SEQUENCE
3822:d=9 hl=2 l= 3 prim: OBJECT :commonName 3674:d=9 hl=2 l= 3 prim: OBJECT :commonName
3827:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3679:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co
3880:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 3732:d=6 hl=2 l= 4 prim: INTEGER :3F989B52
3886:d=5 hl=2 l= 11 cons: SEQUENCE 3738:d=5 hl=2 l= 11 cons: SEQUENCE
3888:d=6 hl=2 l= 9 prim: OBJECT :sha256 3740:d=6 hl=2 l= 9 prim: OBJECT :sha256
3899:d=5 hl=2 l= 105 cons: cont [ 0 ] 3751:d=5 hl=2 l= 105 cons: cont [ 0 ]
3901:d=6 hl=2 l= 24 cons: SEQUENCE 3753:d=6 hl=2 l= 24 cons: SEQUENCE
3903:d=7 hl=2 l= 9 prim: OBJECT :contentType 3755:d=7 hl=2 l= 9 prim: OBJECT :contentType
3914:d=7 hl=2 l= 11 cons: SET 3766:d=7 hl=2 l= 11 cons: SET
3916:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 3768:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
3927:d=6 hl=2 l= 28 cons: SEQUENCE 3779:d=6 hl=2 l= 28 cons: SEQUENCE
3929:d=7 hl=2 l= 9 prim: OBJECT :signingTime 3781:d=7 hl=2 l= 9 prim: OBJECT :signingTime
3940:d=7 hl=2 l= 15 cons: SET 3792:d=7 hl=2 l= 15 cons: SET
3942:d=8 hl=2 l= 13 prim: UTCTIME :200225230449Z 3794:d=8 hl=2 l= 13 prim: UTCTIME :210413214323Z
3957:d=6 hl=2 l= 47 cons: SEQUENCE 3809:d=6 hl=2 l= 47 cons: SEQUENCE
3959:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 3811:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
3970:d=7 hl=2 l= 34 cons: SET 3822:d=7 hl=2 l= 34 cons: SET
3972:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:3D818C51D6C4B4 3824:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:49CEADD5A3946E
4006:d=5 hl=2 l= 10 cons: SEQUENCE 3858:d=5 hl=2 l= 10 cons: SEQUENCE
4008:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3860:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
4018:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220589E5D 3870:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:3045022100C84E
]]></artwork> ]]></artwork>
<t> <t>
The JSON contained in the voucher request. Note that the previous The JSON contained in the voucher-request. Note that the previous
voucher request is in the prior-signed-voucher-request attribute. voucher-request is in the prior-signed-voucher-request attribute.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json">
{"ietf-voucher-request:voucher":{"assertion":"proximity","cr {"ietf-voucher-request:voucher":{"assertion":"proximity","cr
eated-on":"2020-02-25T23:04:49.054Z","serial-number":"00-D0- eated-on":"2021-04-13T21:43:23.787Z","serial-number":"00-D0-
E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","prior-signed- E5-F2-00-02","nonce":"-_XE9zK9q8Ll1qylMtLKeg","prior-signed-
voucher-request":"MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBg voucher-request":"MIIGcAYJKoZIhvcNAQcCoIIGYTCCBl0CAQExDTALBg
lghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaG lghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaG
VyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLC VyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLC
JjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLC JjcmVhdGVkLW9uIjoiMjAyMS0wNC0xM1QxNzo0MzoyMy43NDctMDQ6MDAiLC
JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Im JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Ii
FNamd1ZUtVVC0yMndWaW1qNnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLW 1fWEU5eks5cThMbDFxeWxNdExLZWciLCJwcm94aW1pdHktcmVnaXN0cmFyLW
NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV
FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU
prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF
lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm
5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak 5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak
F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV
pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU
F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn
lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk
NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU
5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU 5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU
1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG 1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG
tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV
BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk
JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2 JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2
NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIEDYXcLTAKBg NGY0FkZisrQnc2WXkrVT0ifX2gggGyMIIBrjCCATWgAwIBAgIEDYOv2TAKBg
gqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW gqhkjOPQQDAjAmMSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb2
8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0Lm 0gQ0EwIBcNMjEwNDEzMjAzNzM5WhgPMjk5OTEyMzEwMDAwMDBaMBwxGjAYBg
V4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMD NVBAUMETAwLUQwLUU1LUYyLTAwLTAyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQ
AwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49Ag cDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLxFj
EGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5BefBbE0 DOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJ6NZMFcwHQYDVR0OBBYEFEWIzJaWAG
sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDg Q3sLojZWRkVAgGbFatMAkGA1UdEwQCMAAwKwYIKwYBBQUHASAEHxYdaGlnaH
QWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBw dheS10ZXN0LmV4YW1wbGUuY29tOjk0NDMwCgYIKoZIzj0EAwIDZwAwZAIwTm
EgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BA lG8sXkKGNbwbKQcYMapFbmSbnHHURFUoFuRqvbgYX7FlXpBczfwF2kllNuuj
MCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TX igAjAow1kc4r55EmiH+OMEXjBNlWlBSZC5QuJjEf0Jsmxssc+pucjOJ4Shqn
mKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vA exMEy7bjAxggEEMIIBAAIBATAuMCYxJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC
QdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2 5leGFtcGxlLmNvbSBDQQIEDYOv2TALBglghkgBZQMEAgGgaTAYBgkqhkiG9w
FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJD 0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA0MTMyMTQzMj
AiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEDYXcLTALBg NaMC8GCSqGSIb3DQEJBDEiBCBJwhyYibIjeqeR3bOaLURzMlGrc3F2X+kvJ1
lghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSI errtoCtTAKBggqhkjOPQQDAgRHMEUCIQCmYuCE61HFQXH/E16GDOCsVquDtg
b3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6Irwst r+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2vZFQAKXUbimkiHKzXBA8md0VHb
HF609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIB U="}}
xwA1UlkIkuQDf/j7kZ/MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bm </sourcecode>
iEUpefCEhxSv2xLYurGlugv0dfr/E="}}]]></artwork>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>MASA to Registrar</name> <name>MASA to Registrar</name>
<t> <t>
The MASA will return a voucher to the registrar, to be relayed to The MASA will return a voucher to the registrar, which is to be rela yed to
the pledge. the pledge.
</t> </t>
<sourcecode name="voucher_00-D0-E5-F2-00-02.b64" type="" markers="true "><![CDATA[ <sourcecode name="voucher_00-D0-E5-F2-00-02.b64" type="" markers="true "><![CDATA[
MIIGxwYJKoZIhvcNAQcCoIIGuDCCBrQCAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG9w0BBwGg MIIGIgYJKoZIhvcNAQcCoIIGEzCCBg8CAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG
ggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoibG9nZ2VkIiwiY3Jl 9w0BBwGgggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoi
YXRlZC1vbiI6IjIwMjAtMDItMjVUMTg6MDQ6NDkuMzAzLTA1OjAwIiwic2VyaWFsLW51bWJlciI6 bG9nZ2VkIiwiY3JlYXRlZC1vbiI6IjIwMjEtMDQtMTNUMTc6NDM6MjQuNTg5LTA0OjAw
IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdRIiwicGlu Iiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiItX1hF
bmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NBWUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFR OXpLOXE4TGwxcXlsTXRMS2VnIiwicGlubmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NB
REFqQnRNUkl3RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6 WUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFRREFqQnRNUkl3RUFZS0NaSW1pWlB5
WVc1a1pXeHRZVzR4UERBNkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpi TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6WVc1a1pXeHRZVzR4UERB
MjBnVlc1emRISjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5U NkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpiMjBnVlc1emRI
UmFGdzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJj SjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5UUmFG
R0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05MWJuUmhhVzR0 dzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVa
ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFC TUJjR0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05
SlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt MWJuUmhhVzR0ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0ND
SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqS2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0Nz cUdTTTQ5QXdFSEEwSUFCSlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1ha
R0FRVUZCd01jTUE0R0ExVWREd0VCL3dRRUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJt Q3RqQUkwQ0QxZkpmSlIvaEl5eURtSFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFq
VDJCTVZVZ2VsZ2Y0M1IrNXlCS05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVht S2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0NzR0FRVUZCd01jTUE0R0ExVWREd0VCL3dR
UmtqL1g0Q01RQzhyTU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNn RUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJtVDJCTVZVZ2VsZ2Y0M1IrNXlC
ZFNjRmNBZGYrK0J3Nll5K1U9In19oIIB4zCCAd8wggFkoAMCAQICBBuZX1QwCgYIKoZIzj0EAwIw S05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVhtUmtqL1g0Q01RQzhy
XTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4x TU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNnZFNjRmNB
JDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0xOTAyMTIyMjIyNDFaFw0y ZGYrK0J3Nll5K1U9In19oIIBdDCCAXAwgfagAwIBAgIEC4cKMTAKBggqhkjOPQQDAjAm
MTAyMTEyMjIyNDFaMF8xDzANBgNVBAYTBkNhbmFkYTEQMA4GA1UECAwHT250YXJpbzESMBAGA1UE MSQwIgYDVQQDDBtoaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gQ0EwHhcNMjEwNDEzMjE0
CwwJU2FuZGVsbWFuMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gTUFTQTBZMBMG MDE2WhcNMjMwNDEzMjE0MDE2WjAoMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBs
ByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5GwcbpnRznB66bKmzqTCpojJZ96AdRwFt ZS5jb20gTUFTQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5Gwcb
uTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6WjEDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0E pnRznB66bKmzqTCpojJZ96AdRwFtuTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6Wj
AwIDaQAwZgIxAL1V5ZsO+/xelSnjgbMVNaqTGKIEvkRyslF9TW3r0dXBEDqyOXtXP8XMsKMO55lG EDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDaQAwZgIxAK7LYS3UXI1uhqoLBh3G
ugIxAPZ/RH23FPrRZ2rUEcNLrub7mphW+oUhLlxITPA/8ps/roggp675cv9b+Xhozw9IyTGCATsw 02C6MnM2JdMjhUmHHM6UI3kankFVJB0VIqFIuwrAqzwTcwIxAIY8Z7OVouLl+a35HZzB
ggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlT NDJ49c/q1UcDnwC/0FnLUcKYBIEkilETULF1si+dqLT0uTGCAQUwggEBAgEBMC4wJjEk
YW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEG5lfVDALBglg MCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBAgQLhwoxMAsGCWCGSAFl
hkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAy AwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIx
MjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCCJQso4Z9msdaPk3bsDltTkVckX50DvOPuOR9Svi5M9 MDQxMzIxNDMyNFowLwYJKoZIhvcNAQkEMSIEIFUUjg4WYVO+MpX122Qfk/7zm/G6/B59
RDAKBggqhkjOPQQDAgRHMEUCIQCKESXfM3iV8hpkqcxAKA1veArA6GFpN0jzyns4El8uDgIgSRQi HD/xrVR0lGIjMAoGCCqGSM49BAMCBEgwRgIhAOhUfxbH2dwpB2BrTDcsYSjRkCCk/WE6
9/MntuJhAM/tJCZBkfHBoAGX4PFAwwbs5LFZtAw= Mdt+y4z5KD9IAiEAphwdIUb40A0noNIUpH7N2lTyAFZgyn1lNHTteY9DmYI=
]]></sourcecode> ]]></sourcecode>
<t> <t>
The ASN1 decoding of the artifact: The ASN1 decoding of the artifact:
</t> </t>
<t keepWithPrevious="true">file: examples/voucher_00-D0-E5-F2-00-02.b6 4</t> <t keepWithPrevious="true">file: examples/voucher_00-D0-E5-F2-00-02.b6 4</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0:d=0 hl=4 l=1735 cons: SEQUENCE 0:d=0 hl=4 l=1570 cons: SEQUENCE
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=1720 cons: cont [ 0 ] 15:d=1 hl=4 l=1555 cons: cont [ 0 ]
19:d=2 hl=4 l=1716 cons: SEQUENCE 19:d=2 hl=4 l=1551 cons: SEQUENCE
23:d=3 hl=2 l= 1 prim: INTEGER :01 23:d=3 hl=2 l= 1 prim: INTEGER :01
26:d=3 hl=2 l= 13 cons: SET 26:d=3 hl=2 l= 13 cons: SET
28:d=4 hl=2 l= 11 cons: SEQUENCE 28:d=4 hl=2 l= 11 cons: SEQUENCE
30:d=5 hl=2 l= 9 prim: OBJECT :sha256 30:d=5 hl=2 l= 9 prim: OBJECT :sha256
41:d=3 hl=4 l= 888 cons: SEQUENCE 41:d=3 hl=4 l= 888 cons: SEQUENCE
45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
56:d=4 hl=4 l= 873 cons: cont [ 0 ] 56:d=4 hl=4 l= 873 cons: cont [ 0 ]
60:d=5 hl=4 l= 869 prim: OCTET STRING :{"ietf-voucher:voucher": 60:d=5 hl=4 l= 869 prim: OCTET STRING :{"ietf-voucher:voucher":
933:d=3 hl=4 l= 483 cons: cont [ 0 ] 933:d=3 hl=4 l= 372 cons: cont [ 0 ]
937:d=4 hl=4 l= 479 cons: SEQUENCE 937:d=4 hl=4 l= 368 cons: SEQUENCE
941:d=5 hl=4 l= 356 cons: SEQUENCE 941:d=5 hl=3 l= 246 cons: SEQUENCE
945:d=6 hl=2 l= 3 cons: cont [ 0 ] 944:d=6 hl=2 l= 3 cons: cont [ 0 ]
947:d=7 hl=2 l= 1 prim: INTEGER :02 946:d=7 hl=2 l= 1 prim: INTEGER :02
950:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 949:d=6 hl=2 l= 4 prim: INTEGER :0B870A31
956:d=6 hl=2 l= 10 cons: SEQUENCE 955:d=6 hl=2 l= 10 cons: SEQUENCE
958:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 957:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
968:d=6 hl=2 l= 93 cons: SEQUENCE 967:d=6 hl=2 l= 38 cons: SEQUENCE
970:d=7 hl=2 l= 15 cons: SET 969:d=7 hl=2 l= 36 cons: SET
972:d=8 hl=2 l= 13 cons: SEQUENCE 971:d=8 hl=2 l= 34 cons: SEQUENCE
974:d=9 hl=2 l= 3 prim: OBJECT :countryName 973:d=9 hl=2 l= 3 prim: OBJECT :commonName
979:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 978:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com
987:d=7 hl=2 l= 16 cons: SET 1007:d=6 hl=2 l= 30 cons: SEQUENCE
989:d=8 hl=2 l= 14 cons: SEQUENCE 1009:d=7 hl=2 l= 13 prim: UTCTIME :210413214016Z
991:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1024:d=7 hl=2 l= 13 prim: UTCTIME :230413214016Z
996:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1039:d=6 hl=2 l= 40 cons: SEQUENCE
1005:d=7 hl=2 l= 18 cons: SET 1041:d=7 hl=2 l= 38 cons: SET
1007:d=8 hl=2 l= 16 cons: SEQUENCE 1043:d=8 hl=2 l= 36 cons: SEQUENCE
1009:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1045:d=9 hl=2 l= 3 prim: OBJECT :commonName
1014:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1050:d=9 hl=2 l= 29 prim: UTF8STRING :highway-test.example.com
1025:d=7 hl=2 l= 36 cons: SET 1081:d=6 hl=2 l= 89 cons: SEQUENCE
1027:d=8 hl=2 l= 34 cons: SEQUENCE 1083:d=7 hl=2 l= 19 cons: SEQUENCE
1029:d=9 hl=2 l= 3 prim: OBJECT :commonName 1085:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
1034:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 1094:d=8 hl=2 l= 8 prim: OBJECT :prime256v1
1063:d=6 hl=2 l= 30 cons: SEQUENCE 1104:d=7 hl=2 l= 66 prim: BIT STRING
1065:d=7 hl=2 l= 13 prim: UTCTIME :190212222241Z 1172:d=6 hl=2 l= 16 cons: cont [ 3 ]
1080:d=7 hl=2 l= 13 prim: UTCTIME :210211222241Z 1174:d=7 hl=2 l= 14 cons: SEQUENCE
1095:d=6 hl=2 l= 95 cons: SEQUENCE 1176:d=8 hl=2 l= 12 cons: SEQUENCE
1097:d=7 hl=2 l= 15 cons: SET 1178:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
1099:d=8 hl=2 l= 13 cons: SEQUENCE 1183:d=9 hl=2 l= 1 prim: BOOLEAN :255
1101:d=9 hl=2 l= 3 prim: OBJECT :countryName 1186:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
1106:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1190:d=5 hl=2 l= 10 cons: SEQUENCE
1114:d=7 hl=2 l= 16 cons: SET 1192:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1116:d=8 hl=2 l= 14 cons: SEQUENCE 1202:d=5 hl=2 l= 105 prim: BIT STRING
1118:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1309:d=3 hl=4 l= 261 cons: SET
1123:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1313:d=4 hl=4 l= 257 cons: SEQUENCE
1132:d=7 hl=2 l= 18 cons: SET 1317:d=5 hl=2 l= 1 prim: INTEGER :01
1134:d=8 hl=2 l= 16 cons: SEQUENCE 1320:d=5 hl=2 l= 46 cons: SEQUENCE
1136:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1322:d=6 hl=2 l= 38 cons: SEQUENCE
1141:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1324:d=7 hl=2 l= 36 cons: SET
1152:d=7 hl=2 l= 38 cons: SET 1326:d=8 hl=2 l= 34 cons: SEQUENCE
1154:d=8 hl=2 l= 36 cons: SEQUENCE 1328:d=9 hl=2 l= 3 prim: OBJECT :commonName
1156:d=9 hl=2 l= 3 prim: OBJECT :commonName 1333:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com
1161:d=9 hl=2 l= 29 prim: UTF8STRING :highway-test.example.com 1362:d=6 hl=2 l= 4 prim: INTEGER :0B870A31
1192:d=6 hl=2 l= 89 cons: SEQUENCE 1368:d=5 hl=2 l= 11 cons: SEQUENCE
1194:d=7 hl=2 l= 19 cons: SEQUENCE 1370:d=6 hl=2 l= 9 prim: OBJECT :sha256
1196:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 1381:d=5 hl=2 l= 105 cons: cont [ 0 ]
1205:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 1383:d=6 hl=2 l= 24 cons: SEQUENCE
1215:d=7 hl=2 l= 66 prim: BIT STRING 1385:d=7 hl=2 l= 9 prim: OBJECT :contentType
1283:d=6 hl=2 l= 16 cons: cont [ 3 ] 1396:d=7 hl=2 l= 11 cons: SET
1285:d=7 hl=2 l= 14 cons: SEQUENCE 1398:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1287:d=8 hl=2 l= 12 cons: SEQUENCE 1409:d=6 hl=2 l= 28 cons: SEQUENCE
1289:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1411:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1294:d=9 hl=2 l= 1 prim: BOOLEAN :255 1422:d=7 hl=2 l= 15 cons: SET
1297:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 1424:d=8 hl=2 l= 13 prim: UTCTIME :210413214324Z
1301:d=5 hl=2 l= 10 cons: SEQUENCE 1439:d=6 hl=2 l= 47 cons: SEQUENCE
1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1441:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1313:d=5 hl=2 l= 105 prim: BIT STRING 1452:d=7 hl=2 l= 34 cons: SET
1420:d=3 hl=4 l= 315 cons: SET 1454:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:55148E0E166153
1424:d=4 hl=4 l= 311 cons: SEQUENCE 1488:d=5 hl=2 l= 10 cons: SEQUENCE
1428:d=5 hl=2 l= 1 prim: INTEGER :01 1490:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1431:d=5 hl=2 l= 101 cons: SEQUENCE 1500:d=5 hl=2 l= 72 prim: OCTET STRING [HEX DUMP]:3046022100E854
1433:d=6 hl=2 l= 93 cons: SEQUENCE
1435:d=7 hl=2 l= 15 cons: SET ]]></artwork>
1437:d=8 hl=2 l= 13 cons: SEQUENCE </section>
1439:d=9 hl=2 l= 3 prim: OBJECT :countryName <section numbered="false" toc="default">
1444:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada <name>Acknowledgements</name>
1452:d=7 hl=2 l= 16 cons: SET <t>We would like to thank the various reviewers for their input, in
1454:d=8 hl=2 l= 14 cons: SEQUENCE particular
1456:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName <contact fullname="William Atwood"/>,
1461:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario <contact fullname="Brian Carpenter"/>,
1470:d=7 hl=2 l= 18 cons: SET <contact fullname="Fuyu Eleven"/>,
1472:d=8 hl=2 l= 16 cons: SEQUENCE <contact fullname="Eliot Lear"/>,
1474:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName <contact fullname="Sergey Kasatkin"/>,
1479:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman <contact fullname="Anoop Kumar"/>,
1490:d=7 hl=2 l= 36 cons: SET <contact fullname="Tom Petch"/>,
1492:d=8 hl=2 l= 34 cons: SEQUENCE <contact fullname="Markus Stenberg"/>,
1494:d=9 hl=2 l= 3 prim: OBJECT :commonName <contact fullname="Peter van der Stok"/>,
1499:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com and
1528:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 <contact fullname="Thomas Werner"/>.
1534:d=5 hl=2 l= 11 cons: SEQUENCE </t>
1536:d=6 hl=2 l= 9 prim: OBJECT :sha256
1547:d=5 hl=2 l= 105 cons: cont [ 0 ]
1549:d=6 hl=2 l= 24 cons: SEQUENCE
1551:d=7 hl=2 l= 9 prim: OBJECT :contentType
1562:d=7 hl=2 l= 11 cons: SET
1564:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1575:d=6 hl=2 l= 28 cons: SEQUENCE
1577:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1588:d=7 hl=2 l= 15 cons: SET
1590:d=8 hl=2 l= 13 prim: UTCTIME :200225230449Z
1605:d=6 hl=2 l= 47 cons: SEQUENCE
1607:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1618:d=7 hl=2 l= 34 cons: SET
1620:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:8942CA3867D9AC
1654:d=5 hl=2 l= 10 cons: SEQUENCE
1656:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
1666:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450221008A11
]]></artwork>
</section>
</section>
</section>
<section numbered="true" toc="default">
<name>Additional References</name>
<t> <t>
RFC EDITOR Please remove this section before publication. Significant reviews were done by <contact fullname="Jari Arkko"/>,
It exists just to include <contact fullname="Christian Huitema"/>, and <contact fullname="Russ Housley"/>.
references to the things in the YANG descriptions which are not
otherwise referenced in the text so that xml2rfc will not complain.
</t> </t>
<t> <t>
<xref target="ITU.X690.1994" format="default"/> <contact fullname="Henk Birkholz"/> contributed the CDDL for the audit-l
og response.
</t>
<t>
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> </t>
</section> </section>
</back> </section>
</rfc> </section>
<!--
Local Variables: </back> </rfc>
mode: xml
End:
 End of changes. 1059 change blocks. 
3974 lines changed or deleted 3163 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/