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"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie nsus="true" docName="draft-ietf-anima-bootstrapping-keyinfra-45" indexInclude="t
tf-anima-bootstrapping-keyinfra-43" ipr="trust200902" obsoletes="" updates="" su rue" ipr="trust200902" number="8995" prepTime="2021-05-21T13:01:44" scripts="Com
bmissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="tru mon,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" toc
e" version="3"> Include="true" xml:lang="en">
<!-- xml2rfc v2v3 conversion 2.46.0 --> <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-ke
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> yinfra-45" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8995" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front> <front>
<title abbrev="BRSKI">Bootstrapping Remote Secure Key Infrastructures <title abbrev="BRSKI">Bootstrapping Remote Secure Key Infrastructure (BRSKI)
(BRSKI)</title> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-bootstrapping-keyi <seriesInfo name="RFC" value="8995" stream="IETF"/>
nfra-43"/>
<author fullname="Max Pritikin" initials="M." surname="Pritikin"> <author fullname="Max Pritikin" initials="M." surname="Pritikin">
<organization>Cisco</organization> <organization showOnFrontPage="true">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" showOnFrontPage="true">San delman 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" showOnFrontPage="true">Futurewei Tech
Futurewei Technologies Inc. USA</organization> nologies 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 showOnFrontPage="true">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 month="05" year="2021"/>
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>ANIMA WG</workgroup> <workgroup>ANIMA</workgroup>
<abstract> <abstract pn="section-abstract">
<t> <t indent="0" pn="section-abstract-1">
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>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8995" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-introduction">Introduction</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pr
ior-bootstrapping-approac">Prior Bootstrapping Approaches</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te
rminology">Terminology</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3">
<t indent="0" pn="section-toc.1-1.1.2.3.1"><xref derivedContent=
"1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-scope-of-solution">Sco
pe of Solution</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.1.2.3.2">
<li pn="section-toc.1-1.1.2.3.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.
2.1.1"><xref derivedContent="1.3.1" format="counter" sectionFormat="of" target="
section-1.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" tar
get="name-support-environment">Support Environment</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3.2.2">
<t indent="0" pn="section-toc.1-1.1.2.3.2.2.1"><xref derived
Content="1.3.2" format="counter" sectionFormat="of" target="section-1.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-constraine
d-environments">Constrained Environments</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3.2.3">
<t indent="0" pn="section-toc.1-1.1.2.3.2.3.1"><xref derived
Content="1.3.3" format="counter" sectionFormat="of" target="section-1.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-network-ac
cess-controls">Network Access Controls</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3.2.4">
<t indent="0" pn="section-toc.1-1.1.2.3.2.4.1"><xref derived
Content="1.3.4" format="counter" sectionFormat="of" target="section-1.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-bootstrapp
ing-is-not-bootin">Bootstrapping is Not Booting</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.1.2.4">
<t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent=
"1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-leveraging-the-new-key
-infr">Leveraging the New Key Infrastructure / Next Steps</xref></t>
</li>
<li pn="section-toc.1-1.1.2.5">
<t indent="0" pn="section-toc.1-1.1.2.5.1"><xref derivedContent=
"1.5" format="counter" sectionFormat="of" target="section-1.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-requirements-for-auton
omic-">Requirements for Autonomic Networking Infrastructure (ANI) Devices</xref>
</t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-architectural-overview">Architectu
ral Overview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent=
"2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-behavior-of-a-pledge">
Behavior of a Pledge</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent=
"2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-secure-imprinting-usin
g-vou">Secure Imprinting Using Vouchers</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-initial-device-identif
ier">Initial Device Identifier</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.3.2">
<li pn="section-toc.1-1.2.2.3.2.1">
<t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derived
Content="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-identifica
tion-of-the-pledg">Identification of the Pledge</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3.2.2">
<t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derived
Content="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-uri-e
xtension">MASA URI Extension</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.4">
<t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent=
"2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-protocol-flow">Protoco
l Flow</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5">
<t indent="0" pn="section-toc.1-1.2.2.5.1"><xref derivedContent=
"2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-architectural-componen
ts">Architectural Components</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.5.2">
<li pn="section-toc.1-1.2.2.5.2.1">
<t indent="0" pn="section-toc.1-1.2.2.5.2.1.1"><xref derived
Content="2.5.1" format="counter" sectionFormat="of" target="section-2.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-pledge">Pl
edge</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5.2.2">
<t indent="0" pn="section-toc.1-1.2.2.5.2.2.1"><xref derived
Content="2.5.2" format="counter" sectionFormat="of" target="section-2.5.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-join-proxy
">Join Proxy</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5.2.3">
<t indent="0" pn="section-toc.1-1.2.2.5.2.3.1"><xref derived
Content="2.5.3" format="counter" sectionFormat="of" target="section-2.5.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-domain-reg
istrar">Domain Registrar</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5.2.4">
<t indent="0" pn="section-toc.1-1.2.2.5.2.4.1"><xref derived
Content="2.5.4" format="counter" sectionFormat="of" target="section-2.5.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-manufactur
er-service">Manufacturer Service</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5.2.5">
<t indent="0" pn="section-toc.1-1.2.2.5.2.5.1"><xref derived
Content="2.5.5" format="counter" sectionFormat="of" target="section-2.5.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-public-key
-infrastructure-p">Public Key Infrastructure (PKI)</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.6">
<t indent="0" pn="section-toc.1-1.2.2.6.1"><xref derivedContent=
"2.6" format="counter" sectionFormat="of" target="section-2.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-certificate-time-valid
ation">Certificate Time Validation</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.6.2">
<li pn="section-toc.1-1.2.2.6.2.1">
<t indent="0" pn="section-toc.1-1.2.2.6.2.1.1"><xref derived
Content="2.6.1" format="counter" sectionFormat="of" target="section-2.6.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-lack-of-re
al-time-clock">Lack of Real-Time Clock</xref></t>
</li>
<li pn="section-toc.1-1.2.2.6.2.2">
<t indent="0" pn="section-toc.1-1.2.2.6.2.2.1"><xref derived
Content="2.6.2" format="counter" sectionFormat="of" target="section-2.6.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-infinite-l
ifetime-of-idevid">Infinite Lifetime of IDevID</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.7">
<t indent="0" pn="section-toc.1-1.2.2.7.1"><xref derivedContent=
"2.7" format="counter" sectionFormat="of" target="section-2.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cloud-registrar">Cloud
Registrar</xref></t>
</li>
<li pn="section-toc.1-1.2.2.8">
<t indent="0" pn="section-toc.1-1.2.2.8.1"><xref derivedContent=
"2.8" format="counter" sectionFormat="of" target="section-2.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-determining-the-masa-t
o-con">Determining the MASA to Contact</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-voucher-request-artifact">Voucher-
Request Artifact</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-nonceless-voucher-requ
ests">Nonceless Voucher-Requests</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tree-diagram">Tree Dia
gram</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-examples">Examples</xr
ef></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-yang-module">YANG Modu
le</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-proxying-details-pledge-pro">Proxy
ing Details (Pledge -- Proxy -- Registrar)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pledge-discovery-of-pr
oxy">Pledge Discovery of Proxy</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.1.2">
<li pn="section-toc.1-1.4.2.1.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derived
Content="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-proxy-gras
p-announcements">Proxy GRASP Announcements</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-coap-connection-to-reg
istra">CoAP Connection to Registrar</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-proxy-discovery-and-co
mmuni">Proxy Discovery and Communication of Registrar</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-details-pledge-reg">Proto
col Details (Pledge -- Registrar -- MASA)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-brski-est-tls-establis
hment">BRSKI-EST TLS Establishment Details</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pledge-requests-vouche
r-fro">Pledge Requests Voucher from the Registrar</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-registrar-authorizatio
n-of-">Registrar Authorization of Pledge</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-brski-masa-tls-establi
shmen">BRSKI-MASA TLS Establishment Details</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.4.2">
<li pn="section-toc.1-1.5.2.4.2.1">
<t indent="0" pn="section-toc.1-1.5.2.4.2.1.1"><xref derived
Content="5.4.1" format="counter" sectionFormat="of" target="section-5.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-authe
ntication-of-cust">MASA Authentication of Customer Registrar</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.5">
<t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent=
"5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-registrar-requests-vou
cher-">Registrar Requests Voucher from MASA</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.5.2">
<li pn="section-toc.1-1.5.2.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.5.2.1.1"><xref derived
Content="5.5.1" format="counter" sectionFormat="of" target="section-5.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-renew
al-of-expired-vou">MASA Renewal of Expired Vouchers</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.5.2.2.1"><xref derived
Content="5.5.2" format="counter" sectionFormat="of" target="section-5.5.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-pinni
ng-of-registrar">MASA Pinning of Registrar</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.5.2.3.1"><xref derived
Content="5.5.3" format="counter" sectionFormat="of" target="section-5.5.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-check
-of-the-voucher-r">MASA Check of the Voucher-Request Signature</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.5.2.4.1"><xref derived
Content="5.5.4" format="counter" sectionFormat="of" target="section-5.5.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-verif
ication-of-the-do">MASA Verification of the Domain Registrar</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5.2.5">
<t indent="0" pn="section-toc.1-1.5.2.5.2.5.1"><xref derived
Content="5.5.5" format="counter" sectionFormat="of" target="section-5.5.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-verif
ication-of-the-pl">MASA Verification of the Pledge 'prior-signed-voucher-request
'</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5.2.6">
<t indent="0" pn="section-toc.1-1.5.2.5.2.6.1"><xref derived
Content="5.5.6" format="counter" sectionFormat="of" target="section-5.5.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-nonce
-handling">MASA Nonce Handling</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.6">
<t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent=
"5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-masa-and-registrar-vou
cher-">MASA and Registrar Voucher Response</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.6.2">
<li pn="section-toc.1-1.5.2.6.2.1">
<t indent="0" pn="section-toc.1-1.5.2.6.2.1.1"><xref derived
Content="5.6.1" format="counter" sectionFormat="of" target="section-5.6.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-vou
cher-verification">Pledge Voucher Verification</xref></t>
</li>
<li pn="section-toc.1-1.5.2.6.2.2">
<t indent="0" pn="section-toc.1-1.5.2.6.2.2.1"><xref derived
Content="5.6.2" format="counter" sectionFormat="of" target="section-5.6.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-aut
hentication-of-pr">Pledge Authentication of Provisional TLS Connection</xref></t
>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.7">
<t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent=
"5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pledge-brski-status-te
lemet">Pledge BRSKI Status Telemetry</xref></t>
</li>
<li pn="section-toc.1-1.5.2.8">
<t indent="0" pn="section-toc.1-1.5.2.8.1"><xref derivedContent=
"5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-registrar-audit-log-re
quest">Registrar Audit-Log Request</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.8.2">
<li pn="section-toc.1-1.5.2.8.2.1">
<t indent="0" pn="section-toc.1-1.5.2.8.2.1.1"><xref derived
Content="5.8.1" format="counter" sectionFormat="of" target="section-5.8.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-audit
-log-response">MASA Audit-Log Response</xref></t>
</li>
<li pn="section-toc.1-1.5.2.8.2.2">
<t indent="0" pn="section-toc.1-1.5.2.8.2.2.1"><xref derived
Content="5.8.2" format="counter" sectionFormat="of" target="section-5.8.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-calculatio
n-of-domainid">Calculation of domainID</xref></t>
</li>
<li pn="section-toc.1-1.5.2.8.2.3">
<t indent="0" pn="section-toc.1-1.5.2.8.2.3.1"><xref derived
Content="5.8.3" format="counter" sectionFormat="of" target="section-5.8.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-registrar-
audit-log-verific">Registrar Audit-Log Verification</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.9">
<t indent="0" pn="section-toc.1-1.5.2.9.1"><xref derivedContent=
"5.9" format="counter" sectionFormat="of" target="section-5.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-est-integration-for-pk
i-boo">EST Integration for PKI Bootstrapping</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.9.2">
<li pn="section-toc.1-1.5.2.9.2.1">
<t indent="0" pn="section-toc.1-1.5.2.9.2.1.1"><xref derived
Content="5.9.1" format="counter" sectionFormat="of" target="section-5.9.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-est-distri
bution-of-ca-cert">EST Distribution of CA Certificates</xref></t>
</li>
<li pn="section-toc.1-1.5.2.9.2.2">
<t indent="0" pn="section-toc.1-1.5.2.9.2.2.1"><xref derived
Content="5.9.2" format="counter" sectionFormat="of" target="section-5.9.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-est-csr-at
tributes">EST CSR Attributes</xref></t>
</li>
<li pn="section-toc.1-1.5.2.9.2.3">
<t indent="0" pn="section-toc.1-1.5.2.9.2.3.1"><xref derived
Content="5.9.3" format="counter" sectionFormat="of" target="section-5.9.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-est-client
-certificate-requ">EST Client Certificate Request</xref></t>
</li>
<li pn="section-toc.1-1.5.2.9.2.4">
<t indent="0" pn="section-toc.1-1.5.2.9.2.4.1"><xref derived
Content="5.9.4" format="counter" sectionFormat="of" target="section-5.9.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-enrollment
-status-telemetry">Enrollment Status Telemetry</xref></t>
</li>
<li pn="section-toc.1-1.5.2.9.2.5">
<t indent="0" pn="section-toc.1-1.5.2.9.2.5.1"><xref derived
Content="5.9.5" format="counter" sectionFormat="of" target="section-5.9.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-c
ertificates">Multiple Certificates</xref></t>
</li>
<li pn="section-toc.1-1.5.2.9.2.6">
<t indent="0" pn="section-toc.1-1.5.2.9.2.6.1"><xref derived
Content="5.9.6" format="counter" sectionFormat="of" target="section-5.9.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-est-over-c
oap">EST over CoAP</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-clarification-of-transfer-e">Clari
fication of Transfer-Encoding</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-reduced-security-operationa">Reduc
ed Security Operational Modes</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-trust-model">Trust Mod
el</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pledge-security-reduct
ions">Pledge Security Reductions</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-registrar-security-red
uctio">Registrar Security Reductions</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-masa-security-reductio
ns">MASA Security Reductions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.4.2">
<li pn="section-toc.1-1.7.2.4.2.1">
<t indent="0" pn="section-toc.1-1.7.2.4.2.1.1"><xref derived
Content="7.4.1" format="counter" sectionFormat="of" target="section-7.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-issuing-no
nceless-vouchers">Issuing Nonceless Vouchers</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4.2.2">
<t indent="0" pn="section-toc.1-1.7.2.4.2.2.1"><xref derived
Content="7.4.2" format="counter" sectionFormat="of" target="section-7.4.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-trusting-o
wners-on-first-us">Trusting Owners on First Use</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4.2.3">
<t indent="0" pn="section-toc.1-1.7.2.4.2.3.1"><xref derived
Content="7.4.3" format="counter" sectionFormat="of" target="section-7.4.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-updating-o
r-extending-vouch">Updating or Extending Voucher Trust Anchors</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-ietf-xml-registry"
>The IETF XML Registry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-yang-module-names-regi
stry">YANG Module Names Registry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-brski-well-known-consi
derat">BRSKI Well-Known Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.3.2">
<li pn="section-toc.1-1.8.2.3.2.1">
<t indent="0" pn="section-toc.1-1.8.2.3.2.1.1"><xref derived
Content="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-brski-well
-known-registrati">BRSKI .well-known Registration</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3.2.2">
<t indent="0" pn="section-toc.1-1.8.2.3.2.2.1"><xref derived
Content="8.3.2" format="counter" sectionFormat="of" target="section-8.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-brski-well
-known-registry">BRSKI .well-known Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.4">
<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
"8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pkix-registry">PKIX Re
gistry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.5">
<t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent=
"8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pledge-brski-status-te
lemetr">Pledge BRSKI Status Telemetry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.6">
<t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent=
"8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dns-service-names">DNS
Service Names</xref></t>
</li>
<li pn="section-toc.1-1.8.2.7">
<t indent="0" pn="section-toc.1-1.8.2.7.1"><xref derivedContent=
"8.7" format="counter" sectionFormat="of" target="section-8.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-grasp-objective-names"
>GRASP Objective Names</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-applicability-to-the-autono">Appli
cability to the Autonomic Control Plane (ACP)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-operational-requiremen
ts">Operational Requirements</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.9.2.1.2">
<li pn="section-toc.1-1.9.2.1.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.2.1.1"><xref derived
Content="9.1.1" format="counter" sectionFormat="of" target="section-9.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-masa-opera
tional-requiremen">MASA Operational Requirements</xref></t>
</li>
<li pn="section-toc.1-1.9.2.1.2.2">
<t indent="0" pn="section-toc.1-1.9.2.1.2.2.1"><xref derived
Content="9.1.2" format="counter" sectionFormat="of" target="section-9.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-domain-own
er-operational-re">Domain Owner Operational Requirements</xref></t>
</li>
<li pn="section-toc.1-1.9.2.1.2.3">
<t indent="0" pn="section-toc.1-1.9.2.1.2.3.1"><xref derived
Content="9.1.3" format="counter" sectionFormat="of" target="section-9.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-device-ope
rational-requirem">Device Operational Requirements</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-privacy-considerations">Privacy
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-masa-audit-log">MAS
A Audit-Log</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-what-brski-est-reve
als">What BRSKI-EST Reveals</xref></t>
</li>
<li pn="section-toc.1-1.10.2.3">
<t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent
="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-what-brski-masa-rev
eals-to-">What BRSKI-MASA Reveals to the Manufacturer</xref></t>
</li>
<li pn="section-toc.1-1.10.2.4">
<t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent
="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-manufacturers-and-u
sed-or-s">Manufacturers and Used or Stolen Equipment</xref></t>
</li>
<li pn="section-toc.1-1.10.2.5">
<t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent
="10.5" format="counter" sectionFormat="of" target="section-10.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-manufacturers-and-g
rey-mark">Manufacturers and Grey Market Equipment</xref></t>
</li>
<li pn="section-toc.1-1.10.2.6">
<t indent="0" pn="section-toc.1-1.10.2.6.1"><xref derivedContent
="10.6" format="counter" sectionFormat="of" target="section-10.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-some-mitigations-fo
r-meddli">Some Mitigations for Meddling by Manufacturers</xref></t>
</li>
<li pn="section-toc.1-1.10.2.7">
<t indent="0" pn="section-toc.1-1.10.2.7.1"><xref derivedContent
="10.7" format="counter" sectionFormat="of" target="section-10.7"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-death-of-a-manufact
urer">Death of a Manufacturer</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-denial-of-service-d
os-again">Denial of Service (DoS) against MASA</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-domainid-must-be-re
sistant-">DomainID Must Be Resistant to Second-Preimage Attacks</xref></t>
</li>
<li pn="section-toc.1-1.11.2.3">
<t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent
="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-availability-of-goo
d-random">Availability of Good Random Numbers</xref></t>
</li>
<li pn="section-toc.1-1.11.2.4">
<t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent
="11.4" format="counter" sectionFormat="of" target="section-11.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-freshness-in-vouche
r-reques">Freshness in Voucher-Requests</xref></t>
</li>
<li pn="section-toc.1-1.11.2.5">
<t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent
="11.5" format="counter" sectionFormat="of" target="section-11.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-trusting-manufactur
ers">Trusting Manufacturers</xref></t>
</li>
<li pn="section-toc.1-1.11.2.6">
<t indent="0" pn="section-toc.1-1.11.2.6.1"><xref derivedContent
="11.6" format="counter" sectionFormat="of" target="section-11.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-manufacturer-mainte
nance-of">Manufacturer Maintenance of Trust Anchors</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.11.2.6.2">
<li pn="section-toc.1-1.11.2.6.2.1">
<t indent="0" pn="section-toc.1-1.11.2.6.2.1.1"><xref derive
dContent="11.6.1" format="counter" sectionFormat="of" target="section-11.6.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-comprom
ise-of-manufacturer-">Compromise of Manufacturer IDevID Signing Keys</xref></t>
</li>
<li pn="section-toc.1-1.11.2.6.2.2">
<t indent="0" pn="section-toc.1-1.11.2.6.2.2.1"><xref derive
dContent="11.6.2" format="counter" sectionFormat="of" target="section-11.6.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-comprom
ise-of-masa-signing-">Compromise of MASA Signing Keys</xref></t>
</li>
<li pn="section-toc.1-1.11.2.6.2.3">
<t indent="0" pn="section-toc.1-1.11.2.6.2.3.1"><xref derive
dContent="11.6.3" format="counter" sectionFormat="of" target="section-11.6.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-comprom
ise-of-masa-web-serv">Compromise of MASA Web Service</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11.2.7">
<t indent="0" pn="section-toc.1-1.11.2.7.1"><xref derivedContent
="11.7" format="counter" sectionFormat="of" target="section-11.7"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-yang-module-securit
y-consid">YANG Module Security Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-ipv4-and-non-an
i-operations">IPv4 and Non-ANI Operations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-ipv4-link-local-addre
sses">IPv4 Link-Local Addresses</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-use-of-dhcpv4">Use of
DHCPv4</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-mdns-dns-sd-pro
xy-discovery">mDNS / DNS-SD Proxy Discovery Options</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="Append
ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-example-voucher
s">Example Vouchers</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.15.2">
<li pn="section-toc.1-1.15.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
="C.1" format="counter" sectionFormat="of" target="section-c.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-keys-involved">Keys I
nvolved</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.15.2.1.2">
<li pn="section-toc.1-1.15.2.1.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.2.1.1"><xref derive
dContent="C.1.1" format="counter" sectionFormat="of" target="section-c.1.1"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-manufactu
rer-certification-">Manufacturer Certification Authority for IDevID Signatures</
xref></t>
</li>
<li pn="section-toc.1-1.15.2.1.2.2">
<t indent="0" pn="section-toc.1-1.15.2.1.2.2.1"><xref derive
dContent="C.1.2" format="counter" sectionFormat="of" target="section-c.1.2"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-masa-key-
pair-for-voucher-s">MASA Key Pair for Voucher Signatures</xref></t>
</li>
<li pn="section-toc.1-1.15.2.1.2.3">
<t indent="0" pn="section-toc.1-1.15.2.1.2.3.1"><xref derive
dContent="C.1.3" format="counter" sectionFormat="of" target="section-c.1.3"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-registrar
-certification-aut">Registrar Certification Authority</xref></t>
</li>
<li pn="section-toc.1-1.15.2.1.2.4">
<t indent="0" pn="section-toc.1-1.15.2.1.2.4.1"><xref derive
dContent="C.1.4" format="counter" sectionFormat="of" target="section-c.1.4"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-registrar
-key-pair">Registrar Key Pair</xref></t>
</li>
<li pn="section-toc.1-1.15.2.1.2.5">
<t indent="0" pn="section-toc.1-1.15.2.1.2.5.1"><xref derive
dContent="C.1.5" format="counter" sectionFormat="of" target="section-c.1.5"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-ke
y-pair">Pledge Key Pair</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
="C.2" format="counter" sectionFormat="of" target="section-c.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-example-process">Exam
ple Process</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.15.2.2.2">
<li pn="section-toc.1-1.15.2.2.2.1">
<t indent="0" pn="section-toc.1-1.15.2.2.2.1.1"><xref derive
dContent="C.2.1" format="counter" sectionFormat="of" target="section-c.2.1"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-to
-registrar">Pledge to Registrar</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.2.2.1"><xref derive
dContent="C.2.2" format="counter" sectionFormat="of" target="section-c.2.2"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-registrar
-to-masa">Registrar to MASA</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2.2.3">
<t indent="0" pn="section-toc.1-1.15.2.2.2.3.1"><xref derive
dContent="C.2.3" format="counter" sectionFormat="of" target="section-c.2.3"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-masa-to-r
egistrar">MASA to Registrar</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2.2.4">
<t indent="0" pn="section-toc.1-1.15.2.2.2.4.1"><xref derive
dContent="" format="none" sectionFormat="of" target="section-c.2.4"/><xref deriv
edContent="" format="title" sectionFormat="of" target="name-acknowledgements">Ac
knowledgements</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name>Introduction</name> <name slugifiedName="name-introduction">Introduction</name>
<t> <t indent="0" pn="section-1-1">
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 indent="0" pn="section-1-2">
"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" sectionFormat="of" derivedContent="brewski"/>.
</t> </t>
<t> <t indent="0" pn="section-1-3">
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" se
Control Plane (ACP)</xref>. This bootstrap process satisfies ctionFormat="of" derivedContent="RFC8994"/>.
the <xref target="RFC7575" format="default"/> requirements of section 3.
3 of making all operations This bootstrap process satisfies
secure by default. Other users of the BRSKI protocol the requirement of making all operations
secure by default per <xref target="RFC7575" sectionFormat="of" section=
"3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7575#section-3
.3" derivedContent="RFC7575"/>.
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 deployment. <xref target="acpapplicability" format="default" sectionFor
the detailed mat="of" derivedContent="Section 9"/> explains the detailed
applicability for this the ACP usage. applicability for this ACP usage.
</t> </t>
<t> <t indent="0" pn="section-1-4">
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 indent="0" pn="section-1-5">
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" indent="adaptive" start="1" pn="section-1-6"
<li>Registrar authenticating the pledge: "Who is this device? What is >
<li pn="section-1-6.1" derivedCounter="1.">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 pn="section-1-6.2" derivedCounter="2.">Registrar authorizing the ple dge: "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 pn="section-1-6.3" derivedCounter="3.">Pledge authenticating the reg istrar: "What is this
registrar's identity?"</li> registrar's identity?"</li>
<li>Pledge authorizing the registrar: "Should I join this network?"</li> <li pn="section-1-6.4" derivedCounter="4.">Pledge authorizing the regist rar: "Should I join this network?"</li>
</ol> </ol>
<t> <t indent="0" pn="section-1-7">
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" sectionFormat="o
to answer f" derivedContent="IDevID"/>) of the pledge 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 indent="0" pn="section-1-8">
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 indent="0" pn="section-1-9">The syntactic details of vouchers are descr ibed in detail in <xref target="RFC8366" format="default" sectionFormat="of" der ivedContent="RFC8366"/>. 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 sectionFormat="of" derivedContent="Section 3"/>) as defined
by <xref target="RFC8366" format="default"/>.</t> by <xref target="RFC8366" format="default" sectionFormat="of" derivedConte
<t>BRSKI results in the pledge storing an X.509 root nt="RFC8366"/>.</t>
<t indent="0" pn="section-1-10">BRSKI results in the pledge storing an X.5
09 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" fo
out-of-band" information. With BRSKI the pledge now can automate rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-4.1.1" de
rivedContent="RFC7030"/>, 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 indent="0" pn="section-1-11">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="include" removeInRFC="false" pn="section-1.1
<name>Prior Bootstrapping Approaches</name> ">
<t>To literally "pull yourself up by the bootstraps" is an impossible <name slugifiedName="name-prior-bootstrapping-approac">Prior Bootstrappi
action. Similarly the secure establishment of a key infrastructure ng Approaches</name>
without external help is also an impossibility. Today it is commonly <t indent="0" pn="section-1.1-1">To literally "pull yourself up by the b
ootstraps" is an impossible
action. Similarly, the secure establishment of a key infrastructure
without external help is also an impossibility. Today, it is commonly
accepted that the initial connections between nodes are insecure, until 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" sectionFormat=
ng'.</t> "of" derivedContent="RFC7435"/>, "resurrecting duckling"
<t>Another prior approach has been to try and <xref target="Stajano99theresurrecting" format="default" sectionFormat="
of" derivedContent="Stajano99theresurrecting"/>, or "pre-staging".</t>
<t indent="0" pn="section-1.1-2">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" sectio
reduce user actions during bootstrap nFormat="of" derivedContent="RFC7030"/> does reduce user actions during bootstra
pping
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" bare="false" empty="false" indent="3" pn="section-1
<li>using the Implicit Trust Anchor <xref target="RFC7030" format="def .1-3">
ault"/> database to authenticate <li pn="section-1.1-3.1">using the Implicit Trust Anchor (TA) <xref ta
an owner specific service (not an autonomic solution because rget="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> da
tabase to authenticate
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 pn="section-1.1-3.2">engaging a human user to authorize the CA cer tificate 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 pn="section-1.1-3.3">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 pn="section-1.1-3.4">using a certificate-less TLS mutual authentic
ation 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 indent="0" pn="section-1.1-4">
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 indent="0" pn="section-1.1-5">There are "call home" technologies wher
establishes a connection to a well known manufacturer service usin e the pledge first
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" bare="false" empty="false" indent="3" pn="section-1
<li>the pledge requires realtime connectivity to the manufacturer .1-6">
<li pn="section-1.1-6.1">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 <li pn="section-1.1-6.2">the domain identity is exposed to the manufac
s a turer service (this is a
privacy concern),</li> privacy concern), and</li>
<li>the manufacturer is responsible for making the authorization <li pn="section-1.1-6.3">the manufacturer is responsible for making th
decisions (this is a liability concern),</li> e authorization
decisions (this is a liability concern).</li>
</ul> </ul>
<t>BRSKI addresses these issues by defining extensions to the EST protoc ol <t indent="0" pn="section-1.1-7">BRSKI addresses these issues by definin g extensions to the EST protocol
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="include" removeInRFC="false" pn="section-1.2
<name>Terminology</name> ">
<t> <name slugifiedName="name-terminology">Terminology</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t indent="0" pn="section-1.2-1">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
described in BCP 14 <xref target="RFC2119" format="default"/> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
<xref target="RFC8174" format="default"/> when, and only when, they OT RECOMMENDED</bcp14>",
appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="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 indent="0" pn="section-1.2-2">The following terms are defined for cla
<dl newline="false" spacing="normal"> rity:</t>
<dt>ANI:</dt> <dl newline="false" spacing="normal" indent="3" pn="section-1.2-3">
<dd>The Autonomic Network Infrastructure as <dt pn="section-1.2-3.1">ANI:</dt>
defined by <xref target="I-D.ietf-anima-reference-model" format="def <dd pn="section-1.2-3.2">The Autonomic Networking Infrastructure as
ault"/>. defined by <xref target="RFC8993" format="default" sectionFormat="of
<xref target="acpapplicability" format="default"/> details specific " derivedContent="RFC8993"/>.
requirements for pledges, <xref target="acpapplicability" format="default" sectionFormat="of"
proxies and registrars when they are part of an ANI.</dd> derivedContent="Section 9"/> details specific requirements for pledges,
<dt>Circuit Proxy:</dt> proxies, and registrars when they are part of an ANI.</dd>
<dd>A stateful implementation <dt pn="section-1.2-3.3">Circuit Proxy:</dt>
of the join proxy. This is the assumed type of proxy.</dd> <dd pn="section-1.2-3.4">A stateful implementation
<dt>drop-ship:</dt> of the Join Proxy. This is the assumed type of proxy.</dd>
<dd>The physical distribution of equipment <dt pn="section-1.2-3.5">drop-ship:</dt>
<dd pn="section-1.2-3.6">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 pn="section-1.2-3.7">Domain:</dt>
<dd>The set of entities that share a common local <dd pn="section-1.2-3.8">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 pn="section-1.2-3.9">Domain CA:</dt>
<dd>The domain IDentity is a unique value <dd pn="section-1.2-3.10">The domain Certification Authority (CA)
based upon the Registrar CA's certificate. provides certification functionalities to the domain. At a minimum,
<xref target="domainID" format="default"/> specifies how it is calcu
lated.
</dd>
<dt>Domain CA:</dt>
<dd>The domain Certification Authority (CA)
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>enrollment:</dt> <dt pn="section-1.2-3.11">domainID:</dt>
<dd>The process where a device presents key <dd pn="section-1.2-3.12">The domain IDentity is a unique value
based upon the registrar's CA certificate.
<xref target="domainID" format="default" sectionFormat="of" derivedC
ontent="Section 5.8.2"/> specifies how it is calculated.
</dd>
<dt pn="section-1.2-3.13">enrollment:</dt>
<dd pn="section-1.2-3.14">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>imprint:</dt> <dt pn="section-1.2-3.15">IDevID:</dt>
<dd>The process where a device obtains the <dd pn="section-1.2-3.16">An Initial Device Identifier X.509 certifica
te
installed by the vendor on new equipment. This is a term from
802.1AR <xref target="IDevID" format="default" sectionFormat="of" de
rivedContent="IDevID"/>.</dd>
<dt pn="section-1.2-3.17">imprint:</dt>
<dd pn="section-1.2-3.18">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 document <xref target="imprinting" format="default" sectionFormat="o
o f" derivedContent="imprinting"/>. The analogy to
Lorenz's work was first noted in <xref target="Stajano99theresurrect Lorenz's work was first noted in <xref target="Stajano99theresurrect
ing" format="default"/>.</dd> ing" format="default" sectionFormat="of" derivedContent="Stajano99theresurrectin
<dt>IDevID:</dt> g"/>.</dd>
<dd>An Initial Device Identity X.509 certificate <dt pn="section-1.2-3.19">IPIP Proxy:</dt>
installed by the vendor on new equipment. This is a term from <dd pn="section-1.2-3.20">A stateless proxy alternative.</dd>
802.1AR <xref target="IDevID" format="default"/></dd> <dt pn="section-1.2-3.21">Join Proxy:</dt>
<dt>IPIP Proxy:</dt> <dd pn="section-1.2-3.22">A domain entity that helps the pledge join
<dd>A stateless proxy alternative.</dd> the domain. A Join Proxy facilitates communication for devices that
<dt>Join Proxy:</dt>
<dd>A domain entity that helps the pledge join
the domain. A join proxy facilitates communication for devices that
find themselves in an environment where they are not provided 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 pn="section-1.2-3.23">Join Registrar (and Coordinator):</dt>
<dd>A representative of the domain that is <dd pn="section-1.2-3.24">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" sectionFormat="of" derivedContent="RFC8993"/>, 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 pn="section-1.2-3.25">LDevID:</dt>
<dd>A Local Device Identity X.509 certificate <dd pn="section-1.2-3.26">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" sectionFormat="of" de
<dt>manufacturer:</dt> rivedContent="IDevID"/>.</dd>
<dd>the term manufacturer is used <dt pn="section-1.2-3.27">manufacturer:</dt>
throughout this document to be the entity that created the <dd pn="section-1.2-3.28">The term manufacturer is used
device. This is typically the "original equipment manufacturer" throughout this document as the entity that created the
or OEM, but in more complex situations it could be a "value added device. This is typically the original equipment manufacturer
retailer" (VAR), or possibly even a systems integrator. In (OEM), but in more complex situations, it could be a value added
general, it a goal of BRSKI to eliminate small distinctions retailer (VAR), or possibly even a systems integrator. In
general, a goal of BRSKI is to eliminate small distinctions
between different sales channels. The reason for this is 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 pn="section-1.2-3.29">MASA Audit-Log:</dt>
<dd>An anonymized list of previous owners <dd pn="section-1.2-3.30">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"
sectionFormat="of" derivedContent="Section 5.8.1"/>.
</dd> </dd>
<dt>MASA Service:</dt> <dt pn="section-1.2-3.31">MASA Service:</dt>
<dd>A third-party Manufacturer Authorized <dd pn="section-1.2-3.32">A third-party MASA service on the global Int
Signing Authority (MASA) service on the global Internet. The MASA ernet. 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 pn="section-1.2-3.33">nonced:</dt>
<dd>a voucher (or request) that contains a nonce (the normal <dd pn="section-1.2-3.34">A voucher (or request) that contains a nonce
case).</dd> (the normal
<dt>nonceless:</dt> case).</dd>
<dd>a voucher (or request) that does not <dt pn="section-1.2-3.35">nonceless:</dt>
contain a nonce, relying upon accurate clocks for expiration, or <dd pn="section-1.2-3.36">A voucher (or request) that does not
which does not expire.</dd> contain a nonce and either relies upon accurate clocks for expiratio
<dt>offline:</dt> n or
<dd>When an architectural component cannot does not expire.</dd>
perform realtime communications with a peer, either due to <dt pn="section-1.2-3.37">offline:</dt>
network connectivity or because the peer is turned off, the <dd pn="section-1.2-3.38">When an architectural component cannot
perform real-time communications with a peer, due to
either network connectivity or the peer being turned off, the
operation is said to be occurring offline.</dd> operation is said to be occurring offline.</dd>
<dt>Ownership Tracker:</dt> <dt pn="section-1.2-3.39">Ownership Tracker:</dt>
<dd>An Ownership Tracker service on <dd pn="section-1.2-3.40">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" se
<dt>Pledge:</dt> ctionFormat="of" derivedContent="RFC8366"/>.</dd>
<dd>The prospective (unconfigured) device, which has an <dt pn="section-1.2-3.41">Pledge:</dt>
<dd pn="section-1.2-3.42">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 pn="section-1.2-3.43">(Public) Key Infrastructure:</dt>
<dd> The collection of systems and <dd pn="section-1.2-3.44"> 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" sectionFormat="of" derivedCo
format="default"/> (see ntent="RFC5280"/> and <xref target="RFC5272" sectionFormat="of" section="7" form
section 7) "Registration Authority".</dd> at="default" derivedLink="https://rfc-editor.org/rfc/rfc5272#section-7" derivedC
<dt>TOFU:</dt> ontent="RFC5272"/>.</dd>
<dd>Trust on First Use. Used similarly to <xref target="RFC7435" forma <dt pn="section-1.2-3.45">TOFU:</dt>
t="default"/>. This is where a pledge <dd pn="section-1.2-3.46">Trust on First Use. Used similarly to how it
is described in <xref target="RFC7435" format="default" sectionFormat="of" deri
vedContent="RFC7435"/>. 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 pn="section-1.2-3.47">Voucher:</dt>
<dd>A signed artifact from the MASA <dd pn="section-1.2-3.48">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" sectionFormat="of " derivedContent="RFC8366"/>.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1.3
<name>Scope of solution</name> ">
<section numbered="true" toc="default"> <name slugifiedName="name-scope-of-solution">Scope of Solution</name>
<name>Support environment</name> <section numbered="true" toc="include" removeInRFC="false" pn="section-1
<t> .3.1">
<name slugifiedName="name-support-environment">Support Environment</na
me>
<t indent="0" pn="section-1.3.1-1">
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 indent="0" pn="section-1.3.1-2">
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 indent="0" pn="section-1.3.1-3">
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="include" removeInRFC="false" pn="section-1
<name>Constrained environments</name> .3.2">
<t>Questions have been posed as to whether this solution is suitable <name slugifiedName="name-constrained-environments">Constrained Enviro
nments</name>
<t indent="0" pn="section-1.3.2-1">Questions have been posed as to whe
ther 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 capabilities of the devices in question. The terminology of <xref target
="RFC7228" format="default"/> is best used to describe the boundaries.</t> ="RFC7228" format="default" sectionFormat="of" derivedContent="RFC7228"/> is bes
<t>The solution described in this document is aimed in general at t used to describe the boundaries.</t>
non-constrained (i.e., class 2+ <xref target="RFC7228" format="default"/ <t indent="0" pn="section-1.3.2-2">The solution described in this docu
>) devices operating on a non-Challenged ment is aimed in general at
non-constrained (i.e., Class 2+ <xref target="RFC7228" format="default"
sectionFormat="of" derivedContent="RFC7228"/>) devices operating on a non-challe
nged
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 indent="0" pn="section-1.3.2-3">Specifically, there are protocol as
result in congestion collapse or energy-exhaustion of intermediate pects described here that might
battery powered routers in an LLN. Those types of networks should not result in congestion collapse or energy exhaustion of intermediate
battery-powered routers in an LLN. Those types of networks should not
use this solution. These limitations are predominately related to the 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 indent="0" pn="section-1.3.2-4">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="include" removeInRFC="false" pn="section-1
<name>Network Access Controls</name> .3.3">
<t>This document presumes that network access control has either <name slugifiedName="name-network-access-controls">Network Access Cont
rols</name>
<t indent="0" pn="section-1.3.3-1">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" sectionFormat="of" d
rmat="default"/>, and allows for alignment with 802.1X erivedContent="IDevID"/>, and allows for alignment 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" sectionFormat="of" derivedC ontent="RFC3748"/>), is out of scope for this document.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1
<name>Bootstrapping is not Booting</name> .3.4">
<t>This document describes "bootstrapping" as the protocol <name slugifiedName="name-bootstrapping-is-not-bootin">Bootstrapping i
s Not Booting</name>
<t indent="0" pn="section-1.3.4-1">This document describes "bootstrapp
ing" 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="include" removeInRFC
<name>Leveraging the new key infrastructure / next steps</name> ="false" pn="section-1.4">
<t> <name slugifiedName="name-leveraging-the-new-key-infr">Leveraging the Ne
As a result of the protocol described herein, the bootstrapped devices w Key Infrastructure / Next Steps</name>
have the Domain CA trust anchor in common. An end entity certificate h <t indent="0" pn="section-1.4-1">
as As a result of the protocol described herein, bootstrapped devices
optionally been issued from the Domain CA. This makes it possible have the domain CA trust anchor in common. An end-entity (EE) certific
to securely deploy functionalities across the domain, e.g:</t> ate has
<ul spacing="normal"> optionally been issued from the domain CA. This makes it possible
<li>Device management.</li> to securely deploy functionalities across the domain; for example:</t>
<li>Routing authentication.</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>Service discovery.</li> .4-2">
<li pn="section-1.4-2.1">Device management</li>
<li pn="section-1.4-2.2">Routing authentication</li>
<li pn="section-1.4-2.3">Service discovery</li>
</ul> </ul>
<t> <t indent="0" pn="section-1.4-3">
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"/>). sectionFormat="of" derivedContent="RFC8994"/>.
</t> </t>
</section> </section>
<section anchor="ANIrequirements" numbered="true" toc="default"> <section anchor="ANIrequirements" numbered="true" toc="include" removeInRF
<name>Requirements for Autonomic Network Infrastructure (ANI) devices</n C="false" pn="section-1.5">
ame> <name slugifiedName="name-requirements-for-autonomic-">Requirements for
<t> Autonomic Networking Infrastructure (ANI) Devices</name>
<t indent="0" pn="section-1.5-1">
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 indent="0" pn="section-1.5-2">
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" sectionFormat="of" derivedCont
(<xref target="I-D.ietf-anima-reference-model" format="default"/>) tha ent="RFC8993"/> that includes an
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" sectionFormat="of" derivedCont
"/>), the ent="RFC8994"/>, the
BRSKI protocol MUST be implemented. BRSKI protocol <bcp14>MUST</bcp14> be implemented.
</t> </t>
<t> <t indent="0" pn="section-1.5-3">
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" sectionFormat="of" derivedCo
gnaling ntent="Section 4.1"/> using the Discovery Unsolicited
Protocol (GRASP)'s DULL <xref target="I-D.ietf-anima-grasp" format="de Link-Local (DULL) <xref target="RFC8990" format="default" sectionFormat="of"
fault"/> derivedContent="RFC8990"/> M_FLOOD announcements of the GeneRic Autonomic Signal
M_FLOOD announcements. ing Protocol (GRASP).
</t> </t>
<t> <t indent="0" pn="section-1.5-4">
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" sectionFormat="of" derivedContent="Section 5.7"/>.
</t> </t>
<t> <t indent="0" pn="section-1.5-5">
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"
/>. sectionFormat="of" derivedContent="Section 5.9"/>.
They supplement the <xref target="RFC7030" format="default"/> EST to b They supplement the EST <xref target="RFC7030" format="default" sectio
etter nFormat="of" derivedContent="RFC7030"/> to better
support automated devices that do not have an end user. support automated devices that do not have an end user.
</t> </t>
<t> <t indent="0" pn="section-1.5-6">
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 indent="0" pn="section-1.5-7">
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" sectionFormat="of" derivedContent="Section 4.3"/>
).
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name>Architectural Overview</name> <name slugifiedName="name-architectural-overview">Architectural Overview</
<t>The logical elements of the bootstrapping framework are described in name>
this section. <xref target="architecturefigure" format="default"/> provide <t indent="0" pn="section-2-1">The logical elements of the bootstrapping f
s a simplified overview of the components. ramework are described in
this section. <xref target="architecturefigure" format="default" sectionFo
rmat="of" derivedContent="Figure 1"/> provides a simplified overview of the comp
onents.
</t> </t>
<figure anchor="architecturefigure"> <figure anchor="architecturefigure" align="left" suppress-title="false" pn
<name>Architecture Overview</name> ="figure-1">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-architecture-overview">Architecture Overview</
name>
<artwork name="" type="" align="left" alt="" pn="section-2-2.1">
+------------------------+ +------------------------+
+--------------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 &lt;-------+ .
| | . | Proxy | | Registrar | . | | . | Proxy | | Registrar | .
| <-------->............<-------&gt; (PKI RA) | . | <--------&gt;............&lt;-------&gt; (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 indent="0" pn="section-2-3">We assume a multivendor network. In such an
be a Manufacturer Service for each manufacturer that supports devices foll environment, there could
owing this be a manufacturer service for each manufacturer that supports devices foll
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 indent="0" pn="section-2-4">The domain is the managed network infrastru cture with a key infrastructure 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="include" removeInRFC="false" pn="section-2.1
<name>Behavior of a Pledge</name> ">
<t>The pledge goes through a series of steps, which are outlined here <name slugifiedName="name-behavior-of-a-pledge">Behavior of a Pledge</na
me>
<t indent="0" pn="section-2.1-1">The pledge goes through a series of ste
ps, which are outlined here
at a high level.</t> at a high level.</t>
<figure anchor="pledgestatusfigure"> <figure anchor="pledgestatusfigure" align="left" suppress-title="false"
<name>Pledge State Diagram</name> pn="figure-2">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-pledge-state-diagram">Pledge State Diagram</
name>
<artwork name="" type="" align="left" alt="" pn="section-2.1-2.1">
------------ ------------
/ Factory \ / Factory \
\ default / \ default /
-----+------ -----+------
| |
+------v-------+ +------v-------+
| (1) Discover | | (1) Discover |
+------------> | +------------&gt; |
| +------+-------+ | +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (2) Identify | | | (2) Identify |
^------------+ | ^------------+ |
| rejected +------+-------+ | rejected +------+-------+
| | | |
| +------v-------+ | +------v-------+
| | (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 |&lt;---+ (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 indent="0" pn="section-2.1-3">State descriptions for the pledge are a
<ol spacing="normal" type="1"> s follows:</t>
<li>Discover a communication channel to a registrar.</li> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.
<li>Identify itself. This is done by presenting an X.509 IDevID 1-4">
<li pn="section-2.1-4.1" derivedCounter="1.">Discover a communication
channel to a registrar.</li>
<li pn="section-2.1-4.2" derivedCounter="2.">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 pn="section-2.1-4.3" derivedCounter="3.">Request to join the disco
included ensuring that any responses can be associated with this vered registrar. A unique nonce is
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 pn="section-2.1-4.4" derivedCounter="4.">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 pn="section-2.1-4.5" derivedCounter="5.">Enroll. After imprint, an
ts authenticated TLS (HTTPS) connection exists
between pledge and registrar. between the pledge and registrar.
Enrollment over Secure Transport (EST) <xref target="RFC7030" format EST <xref target="RFC7030" format="default" sectionFormat="of" deriv
="default"/> can then be used to obtain a domain edContent="RFC7030"/> can then be used to obtain a domain
certificate from a registrar.</li> certificate from a registrar.</li>
</ol> </ol>
<t> <t indent="0" pn="section-2.1-5">
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 indent="0" pn="section-2.1-6">
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" sectionFormat="of" derivedContent="REST"/>)
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="include" removeInRFC="false" pn="section-2.2
<name>Secure Imprinting using Vouchers</name> ">
<t>A voucher is a cryptographically protected artifact (using a digital <name slugifiedName="name-secure-imprinting-using-vou">Secure Imprinting
signature) to the pledge Using Vouchers</name>
<t indent="0" pn="section-2.2-1">A voucher is a cryptographically protec
ted 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 indent="0" pn="section-2.2-2">The format and cryptographic mechanism
detail in <xref target="RFC8366" format="default"/>.</t> of vouchers is described in
<t>Vouchers provide a flexible mechanism to secure imprinting: the detail in <xref target="RFC8366" format="default" sectionFormat="of" der
ivedContent="RFC8366"/>.</t>
<t indent="0" pn="section-2.2-3">Vouchers provide a flexible mechanism t
o 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 indent="0" pn="section-2.2-4">
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="include" removeInRF
<name>Initial Device Identifier</name> C="false" pn="section-2.3">
<t> <name slugifiedName="name-initial-device-identifier">Initial Device Iden
tifier</name>
<t indent="0" pn="section-2.3-1">
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 bare="false" empty="false" indent="3" spacing="normal" pn="section-2
<li> .3-2">
<li pn="section-2.3-2.1">
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" sectionFormat="of" derivedContent="Section 10.3"/> discuss es privacy implications of the identifier.
</li> </li>
<li> <li pn="section-2.3-2.2">
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"
/>). sectionFormat="of" derivedContent="Section 5.3"/>).
</li> </li>
<li> <li pn="section-2.3-2.3">
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" sectionFormat="
of" derivedContent="Section 2.8"/>).
</li> </li>
<li> <li pn="section-2.3-2.4">
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" sectionFormat
="of" derivedContent="Section 3"/>).
</li> </li>
<li> <li pn="section-2.3-2.5">
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" sectionFor
mat="of" derivedContent="Section 5.5.5"/>).
</li> </li>
</ol> </ul>
<t> <t indent="0" pn="section-2.3-3">
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" sectionFormat="of" derivedConte
nt="IDevID"/> 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" sectionFormat="of" derivedConte nt="IDevID"/> acknowledges that adding restrictions
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 ion 4.2.1.3, This is consistent with <xref target="RFC5280" sectionFormat="comma" s ection="4.2.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc528 0#section-4.2.1.3" derivedContent="RFC5280"/>,
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="include" rem
<name>Identification of the Pledge</name> oveInRFC="false" pn="section-2.3.1">
<t> <name slugifiedName="name-identification-of-the-pledg">Identification
of the Pledge</name>
<t indent="0" pn="section-2.3.1-1">
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" sectionFormat="of" derivedContent="Section 3"/>)
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" sectionFormat="
of" derivedContent="Section 5"/>).
</t> </t>
<t> <t indent="0" pn="section-2.3.1-2">
The serialNumber field is defined in <xref target="RFC5280" format=" There is a (certificate) serialNumber field defined in <xref target="RFC5280"
default"/>. sectionFormat="comma" section="4.1.2.2" format="default" derivedLink="https://r
That specification allows for the field to be omitted if there is fc-editor.org/rfc/rfc5280#section-4.1.2.2" derivedContent="RFC5280"/>. In ASN.1
a good technical reason. IDevID certificates for use , this is referred to as the
with this protocol are REQUIRED to include the "serialNumber" attrib CertificateSerialNumber. This field is NOT relevant to this
ute with the device's specification. Do not confuse this field with the serial-number
unique serial number defined by this document, or by <xref target="IDevID" format="default" sectio
(from <xref target="IDevID" format="default"/> section 7.2.8, and nFormat="of" derivedContent="IDevID"/> and <xref target="RFC4519" sectionFormat=
<xref target="RFC5280" format="default"/> section 4.1.2.2's list of "comma" section="2.31" format="default" derivedLink="https://rfc-editor.org/rfc/
standard rfc4519#section-2.31" derivedContent="RFC4519"/>.
attributes).
</t> </t>
<t> <t indent="0" pn="section-2.3.1-3">
The serialNumber field is used as follows by the pledge to build the The device serial number is defined in <xref target="RFC5280" section="A.1" sect
"serial-number" that is placed in the voucher-request. ionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#
In order to build it, the fields need to be converted into a appendix-A.1" derivedContent="RFC5280"/> as the X520SerialNumber, with the OID t
serial-number of "type string". ag id-at-serialNumber.
</t> </t>
<t> <t indent="0" pn="section-2.3.1-4">
An example of a printable form of the "serialNumber" field The device <em>serialNumber</em> field (X520SerialNumber) is used as follows
is provided in <xref target="RFC4519" format="default"/> section 2.3 by the pledge to build the <strong>serial-number</strong> that is placed in t
1 ("WI-3005"). he
voucher-request. In order to build it, the fields need to be
converted into a serial-number of "type string".
</t>
<t indent="0" pn="section-2.3.1-5">
An example of a printable form of the serialNumber field
is provided in <xref target="RFC4519" sectionFormat="comma" section=
"2.31" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4519#section-
2.31" derivedContent="RFC4519"/> ("WI-3005").
That section further provides equality and syntax attributes. That section further provides equality and syntax attributes.
</t> </t>
<t> <t indent="0" pn="section-2.3.1-6">
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 indent="0" pn="section-2.3.1-7">
As explained in <xref target="RequestVoucherFromMASA" format="defaul As explained in <xref target="RequestVoucherFromMASA" format="defaul
t"/> the Registrar MUST extract the t" sectionFormat="of" derivedContent="Section 5.5"/>, the registrar <bcp14>MUST<
serial-number again itself from the pledge's TLS certificate. It /bcp14> again extract the
can consult the serial-number in the pledge-request if there are serialNumber itself from the pledge's TLS certificate. It
can consult the serial-number in the pledge request if there is
any possible confusion about the source of the serial-number. 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="include" removeInRFC="fal
<name>MASA URI extension</name> se" pn="section-2.3.2">
<t> <name slugifiedName="name-masa-uri-extension">MASA URI Extension</name
>
<t indent="0" pn="section-2.3.2-1">
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=" RFC5280" format="default"/>. The URI is represented as described in <xref target="RFC5280" sectio nFormat="of" section="7.4" format="default" derivedLink="https://rfc-editor.org/ rfc/rfc5280#section-7.4" derivedContent="RFC5280"/>.
</t> </t>
<t> <t indent="0" pn="section-2.3.2-2">
The URI provides the authority information. The URI provides the authority information.
The BRSKI "/.well-known" tree (<xref target="RFC5785" format="defaul The BRSKI "/.well-known" tree <xref target="RFC8615" format="default
t"/>) is " sectionFormat="of" derivedContent="RFC8615"/> is
described in <xref target="ProtocolDetails" format="default"/>. described in <xref target="ProtocolDetails" format="default" section
Format="of" derivedContent="Section 5"/>.
</t> </t>
<t> <t indent="0" pn="section-2.3.2-3">
A complete URI MAY be in this extension, including the 'scheme', 'au A complete URI <bcp14>MAY</bcp14> be in this extension, including th
thority', and 'path', 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" fo
and 'path' of "/.well-known/est" is to be rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc7230#section-2.7.3" de
rivedContent="RFC7230"/>)
and a "path" of "/.well-known/brski" is to be
assumed. assumed.
</t> </t>
<t> <t indent="0" pn="section-2.3.2-4">
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 indent="0" pn="section-2.3.2-5">
Section 7.4 of <xref target="RFC5280" format="default"/> calls out v <xref target="RFC5280" sectionFormat="of" section="7.4" format="defa
arious ult" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-7.4" derivedContent
schemes that MUST be supported, including LDAP, HTTP and FTP. ="RFC5280"/> calls out various
However, the registrar MUST use HTTPS for the BRSKI-MASA connection. schemes that <bcp14>MUST</bcp14> be supported, including the Lightwe
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 indent="0" pn="section-2.3.2-6">The new extension is identified as
<figure anchor="masaurlmodule"> follows:</t>
<name>MASAURL ASN.1 Module</name> <figure anchor="masaurlmodule" align="left" suppress-title="false" pn=
<sourcecode name="" type="" markers="true"><![CDATA[ "figure-3">
<name slugifiedName="name-masaurl-asn1-module">MASAURL ASN.1 Module<
/name>
<sourcecode name="" type="asn.1" markers="true" pn="section-2.3.2-7.
1">
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 1321
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 <t indent="0" pn="section-2.3.2-8">The choice of id-pe is based on gui
[RFC5280], "These extensions may be used to direct applications to on- dance found in <xref target="RFC5280" sectionFormat="of" section="4.2.2" format=
line "default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.2" derived
Content="RFC5280"/>: "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="include" removeInRFC="false" p
<name>Protocol Flow</name> n="section-2.4">
<t>A representative flow is shown in <name slugifiedName="name-protocol-flow">Protocol Flow</name>
<xref target="protocoltimesequencefigure" format="default"/></t> <t indent="0" pn="section-2.4-1">A representative flow is shown in
<figure anchor="protocoltimesequencefigure"> <xref target="protocoltimesequencefigure" format="default" sectionFormat
<name>Protocol Time Sequence Diagram</name> ="of" derivedContent="Figure 4"/>.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <figure anchor="protocoltimesequencefigure" align="left" suppress-title=
"false" pn="figure-4">
<name slugifiedName="name-protocol-time-sequence-diag">Protocol Time S
equence Diagram</name>
<artwork name="" type="" align="left" alt="" pn="section-2.4-2.1">
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| 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 | | | |&lt;-RFC 4862 IPv6 addr | | |
|<-RFC3927 IPv4 addr | Appendix A | Legend | |&lt;-RFC 3927 IPv4 addr | Appendix A | Legend |
|-++++++++++++++++++->| | C - circuit | |-++++++++++++++++++-&gt;| | 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 | |&lt;-++++++++++++++++++-| | Connection |
| GRASP M_FLOOD | | | | GRASP M_FLOOD | | |
| periodic broadcast| | | | periodic broadcast| | |
[identity] | | | [identity] | | |
|<------------------->C<-----------------&gt;| | |<-------------------&gt;C&lt;-----------------&gt;| |
| TLS via the Join Proxy | | | TLS via the Join Proxy | |
|<--Registrar TLS server authentication---| | |&lt;--Registrar TLS server authentication---| |
[PROVISIONAL accept of server cert] | | [PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| | P---X.509 client authentication----------&gt;| |
[request join] | | [request join] | |
P---Voucher Request(w/nonce for voucher)-&gt;| | P---Voucher-Request(w/nonce for voucher)-&gt;| |
P /------------------- | | P /------------------- | |
P | [accept device?] | P | [accept device?] |
P | [contact Vendor] | P | [contact vendor] |
P | |--Pledge ID-------->| P | |--Pledge ID--------&gt;|
P | |--Domain ID-------->| P | |--Domain ID--------&gt;|
P | |--optional:nonce--->| P | |--optional:nonce---&gt;|
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 | |&lt;- voucher ---------|
P \------------------- | w/nonce if provided| P \------------------- | w/nonce if provided|
P<------voucher---------------------------| | P&lt;------voucher---------------------------| |
[imprint] | | [imprint] | |
|-------voucher status telemetry--------->| | |-------voucher status telemetry---------&gt;| |
| |<-device audit log--| | |&lt;-device audit-log--|
| [verify audit log and voucher] | | [verify audit-log and voucher] |
|<--------------------------------------->| | |&lt;---------------------------------------&gt;| |
[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 indent="0" pn="section-2.4-3">
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 indent="0" pn="section-2.4-4">
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 indent="0" pn="section-2.4-5">
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 indent="0" pn="section-2.4-6">
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 indent="0" pn="section-2.4-7">
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 indent="0" pn="section-2.4-8">
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 indent="0" pn="section-2.4-9">
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 indent="0" pn="section-2.4-10">
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="include" removeInRFC="false" pn="section-2.5
<name>Architectural Components</name> ">
<section anchor="pledge-overview" numbered="true" toc="default"> <name slugifiedName="name-architectural-components">Architectural Compon
<name>Pledge</name> ents</name>
<t> <section anchor="pledge-overview" numbered="true" toc="include" removeIn
The pledge is the device that is attempting to join. RFC="false" pn="section-2.5.1">
The pledge is assumed to talk to the Join Proxy using link-local net <name slugifiedName="name-pledge">Pledge</name>
work <t indent="0" pn="section-2.5.1-1">
The pledge is the device that is attempting to join. It is assumed t
hat
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="include" removeInR
<name>Join Proxy</name> FC="false" pn="section-2.5.2">
<t> <name slugifiedName="name-join-proxy">Join Proxy</name>
The join proxy provides HTTPS connectivity between the <t indent="0" pn="section-2.5.2-1">
pledge and the registrar. A circuit proxy mechanism is The Join Proxy provides HTTPS connectivity between the
described in <xref target="proxydetails" format="default"/>. Additio pledge and the registrar. A Circuit Proxy mechanism is
nal described in <xref target="proxydetails" format="default" sectionFor
mechanisms, including a CoAP mechanism and a stateless mat="of" derivedContent="Section 4"/>. Additional
IPIP mechanism are the subject of future work. mechanisms, including a Constrained Application Protocol (CoAP) mech
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="include" remov
<name>Domain Registrar</name> eInRFC="false" pn="section-2.5.3">
<t> <name slugifiedName="name-domain-registrar">Domain Registrar</name>
<t indent="0" pn="section-2.5.3-1">
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" sectionFormat="of" derivedContent="Section 5.4"/>). The registra r
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 vouchers (see <xref target="brskiesttls" format="default" sectionFor
gistrar operates as the BRSKI-EST server mat="of" derivedContent="Section 5.1"/>). The registrar operates as the BRSKI-ES
"Registration Authority" if the pledge requests an end entity certif T server
icate "Registration Authority" if the pledge requests an end-entity certif
over the BRSKI-EST connection (see <xref target="ESTintegration" forma icate
t="default"/>). over the BRSKI-EST connection (see <xref target="ESTintegration" forma
t="default" sectionFormat="of" derivedContent="Section 5.9"/>).
</t> </t>
<t> <t indent="0" pn="section-2.5.3-2">
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 indent="0" pn="section-2.5.3-3">
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="include" removeInRF
<name>Manufacturer Service</name> C="false" pn="section-2.5.4">
<t> <name slugifiedName="name-manufacturer-service">Manufacturer Service</
The Manufacturer Service provides two logically separate functions: name>
the Manufacturer Authorized Signing Authority (MASA) described in <t indent="0" pn="section-2.5.4-1">
<xref target="RequestVoucherFromMASA" format="default"/> and The manufacturer service provides two logically separate functions:
<xref target="VoucherResponse" format="default"/>, the MASA as described in Sections
and an ownership tracking/auditing function described <xref target="RequestVoucherFromMASA" format="counter" sectionFormat
in <xref target="pledgestatus" format="default"/> ="of" derivedContent="5.5"/> and
and <xref target="authzLogRequest" format="default"/>. <xref target="VoucherResponse" format="counter" sectionFormat="of" d
erivedContent="5.6"/>
and an ownership tracking/auditing function as described
in Sections <xref target="pledgestatus" format="counter" sectionForm
at="of" derivedContent="5.7"/>
and <xref target="authzLogRequest" format="counter" sectionFormat="o
f" derivedContent="5.8"/>.
</t> </t>
</section> </section>
<section anchor="pki-overview" numbered="true" toc="default"> <section anchor="pki-overview" numbered="true" toc="include" removeInRFC
<name>Public Key Infrastructure (PKI)</name> ="false" pn="section-2.5.5">
<t> <name slugifiedName="name-public-key-infrastructure-p">Public Key Infr
astructure (PKI)</name>
<t indent="0" pn="section-2.5.5-1">
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 indent="0" pn="section-2.5.5-2">
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 indent="0" pn="section-2.5.5-3">
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" secti
Registration Authority, requesting certificates for pledges from onFormat="of" derivedContent="RFC5272"/>, requesting certificates for pledges fr
the Key Infrastructure. om
the PKI.
</t> </t>
<t> <t indent="0" pn="section-2.5.5-4">
The expectations of the PKI are unchanged from EST <xref target="RFC The expectations of the PKI are unchanged from EST <xref target="RFC
7030" format="default"/>. This document does 7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>. This docu
not place any additional architectural requirements on the Public Ke ment does
y not place any additional architectural requirements on the PKI.
Infrastructure.
</t> </t>
</section> </section>
</section> </section>
<section anchor="certificatevalidaty" numbered="true" toc="default"> <section anchor="certificatevalidaty" numbered="true" toc="include" remove
<name>Certificate Time Validation</name> InRFC="false" pn="section-2.6">
<section anchor="timeunknown" numbered="true" toc="default"> <name slugifiedName="name-certificate-time-validation">Certificate Time
<name>Lack of realtime clock</name> Validation</name>
<t> <section anchor="timeunknown" numbered="true" toc="include" removeInRFC=
Many devices when bootstrapping do not have knowledge of the "false" pn="section-2.6.1">
<name slugifiedName="name-lack-of-real-time-clock">Lack of Real-Time C
lock</name>
<t indent="0" pn="section-2.6.1-1">
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 indent="0" pn="section-2.6.1-2">
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 indent="0" pn="section-2.6.1-3">
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 indent="0" pn="section-2.6.1-4">
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" sect ionFormat="of" derivedContent="Section 5.2"/>.
</t> </t>
</section> </section>
<section anchor="infinitelifetime" numbered="true" toc="default"> <section anchor="infinitelifetime" numbered="true" toc="include" removeI
<name>Infinite Lifetime of IDevID</name> nRFC="false" pn="section-2.6.2">
<t> <name slugifiedName="name-infinite-lifetime-of-idevid">Infinite Lifeti
<xref target="RFC5280" format="default"/> explains that me of IDevID</name>
long lived pledge certificates "SHOULD be assigned the <t indent="0" pn="section-2.6.2-1">
GeneralizedTime value of 99991231235959Z" for the notAfter field. Long-lived pledge certificates "<bcp14>SHOULD</bcp14> be assigned th
e
GeneralizedTime value of 99991231235959Z" for the notAfter field as
explained in <xref target="RFC5280" format="default" sectionFormat="of" derivedC
ontent="RFC5280"/>.
</t> </t>
<t> <t indent="0" pn="section-2.6.2-2">
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" format="default" sectionFormat="of" derived
Content="RFC5280"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="cloudregistrar" numbered="true" toc="default"> <section anchor="cloudregistrar" numbered="true" toc="include" removeInRFC
<name>Cloud Registrar</name> ="false" pn="section-2.7">
<t> <name slugifiedName="name-cloud-registrar">Cloud Registrar</name>
<t indent="0" pn="section-2.7-1">
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 indent="0" pn="section-2.7-2">
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 indent="0" pn="section-2.7-3">
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 <t indent="0" pn="section-2.7-4">If the pledge uses a well-known URI for
a manufacturer-assigned Implicit Trust Anchor database (see <xref contacting a cloud registrar,
target="RFC7030" format="default"/>) MUST a manufacturer-assigned Implicit Trust Anchor database (see <xref
be used to authenticate that service as described in <xref target= target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>)
"RFC6125" format="default"/>. The use of a DNS-ID for validation is <bcp14>MUST</bcp14>
be used to authenticate that service as described in <xref target=
"RFC6125" format="default" sectionFormat="of" derivedContent="RFC6125"/>. The u
se 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" sectionFormat="of" derived
C6125.</t> Content="RFC7030"/>, which also depends on
<xref target="RFC6125" format="default" sectionFormat="of" derivedContent="RFC61
25"/>.</t>
</section> </section>
<section anchor="obtainmasaurl" numbered="true" toc="default"> <section anchor="obtainmasaurl" numbered="true" toc="include" removeInRFC=
<name>Determining the MASA to contact</name> "false" pn="section-2.8">
<t>The registrar needs to be able to contact a MASA that is trusted by t <name slugifiedName="name-determining-the-masa-to-con">Determining the M
he pledge in order to obtain vouchers. There are three mechanisms described:</t> ASA to Contact</name>
<t>The device's Initial Device Identifier (IDevID) will normally contain <t indent="0" pn="section-2.8-1">
the MASA URL as detailed in <xref target="IDevIDextension" format="default"/>. The registrar needs to be able to contact a MASA that is trusted by the pledge i
This is the RECOMMENDED n order to obtain vouchers.</t>
mechanism.</t> <t indent="0" pn="section-2.8-2">The device's IDevID will normally conta
<t>It can be operationally difficult to ensure the necessary X.509 exten in the MASA URL as detailed in <xref target="IDevIDextension" format="default" s
sions are in the pledge's IDevID due to the difficulty of aligning current pledg ectionFormat="of" derivedContent="Section 2.3"/>. This is the <bcp14>RECOMMENDED
e manufacturing with software releases and development. As a final fallback the </bcp14>
registrar MAY be manually configured or distributed with a MASA URL for each man mechanism.</t>
ufacturer. Note that the registrar can only select the configured MASA URL based <t indent="0" pn="section-2.8-3">In some cases, it can be operationally
on the trust anchor -- so manufacturers can only leverage this approach if they difficult to ensure the necessary X.509 extensions are in the pledge's IDevID du
ensure a single MASA URL works for all pledges associated with each trust ancho e to the difficulty of aligning current pledge manufacturing with software relea
r.</t> ses and development; thus, as a final fallback, the registrar <bcp14>MAY</bcp14>
be manually configured or distributed with a MASA URL for each manufacturer. No
te that the registrar can only select the configured MASA URL based on the trust
anchor -- so manufacturers can only leverage this approach if they ensure a sin
gle MASA URL works for all pledges 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="include" removeInRFC=
<name>Voucher-Request artifact</name> "false" pn="section-3">
<t> <name slugifiedName="name-voucher-request-artifact">Voucher-Request Artifa
ct</name>
<t indent="0" pn="section-3-1">
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 indent="0" pn="section-3-2">
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 indent="0" pn="section-3-3">
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 indent="0" pn="section-3-4">
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 indent="0" pn="section-3-5">
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" sectionFormat="of" derived Content="Section 4"/>) 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 indent="0" pn="section-3-6">
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 indent="0" pn="section-3-7">
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 indent="0" pn="section-3-8">
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" sectionFormat="of" derivedConten
t="RFC8366"/>.
</t> </t>
<section anchor="noncelessVoucherRequest" numbered="true" toc="default"> <section anchor="noncelessVoucherRequest" numbered="true" toc="include" re
<name>Nonceless Voucher Requests</name> moveInRFC="false" pn="section-3.1">
<t> <name slugifiedName="name-nonceless-voucher-requests">Nonceless Voucher-
A registrar MAY also retrieve nonceless vouchers by sending Requests</name>
<t indent="0" pn="section-3.1-1">
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 <section anchor="voucher-request-tree-diagram" numbered="true" toc="includ
t"> e" removeInRFC="false" pn="section-3.2">
<name>Tree Diagram</name> <name slugifiedName="name-tree-diagram">Tree Diagram</name>
<t>The following tree diagram illustrates a high-level view of a <t indent="0" pn="section-3.2-1">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= the voucher artifact described in <xref target="RFC8366" format=
"default"/>. "default" sectionFormat="of" derivedContent="RFC8366"/>.
The tree diagram is described in <xref target="RFC8340" format=" The tree diagram is described in <xref target="RFC8340" format="
default"/>. default" sectionFormat="of" derivedContent="RFC8340"/>.
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" sectionFormat="of" derivedContent="Section 3.4 "/>.
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" align="left" suppress-title="false"
<name>YANG Tree diagram for Voucher-Request</name> pn="figure-5">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-yang-tree-diagram-for-a-vou">YANG Tree Diagr
am for a Voucher-Request</name>
<artwork name="" type="yangtree" align="left" alt="" pn="section-3.2-2
.1">
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="include" r
emoveInRFC="false" pn="section-3.3">
<section anchor="voucher-request-examples" numbered="true" toc="default" <name slugifiedName="name-examples">Examples</name>
> <t indent="0" pn="section-3.3-1">This section provides voucher-request e
<name>Examples</name> xamples 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 t"/> section 4). content be base64 encoded (<xref target="RFC4648" sectionFormat= "comma" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc 4648#section-4" derivedContent="RFC4648"/>).
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 to save space. For detailed examples, see <xref target="examplep
rocess" format="default"/>. These examples conform to the encoding rules rocess" format="default" sectionFormat="of" derivedContent="Appendix C.2"/>. The
defined in <xref target="RFC7951" format="default"/>.</t> se examples conform to the encoding rules
<ol group="examples" spacing="normal" type="Example (%d)"> defined in <xref target="RFC7951" format="default" sectionFormat
<li>The following example illustrates a pledge voucher-request. The ="of" derivedContent="RFC7951"/>.</t>
assertion leaf is indicated as 'proximity' and the registrar's TLS s <ol group="examples" spacing="normal" type="Example (%d):" start="1" ind
erver ent="adaptive" pn="section-3.3-2">
certificate is included in the 'proximity-registrar-cert' leaf. See <li pn="section-3.3-2.1" derivedCounter="Example (1):">The following e
<xref target="RequestVoucherFromRegistrar" format="default"/>.</li> xample illustrates a pledge voucher-request. The
assertion leaf is indicated as "proximity", and the registrar's TLS
server
certificate is included in the proximity-registrar-cert leaf. See
<xref target="RequestVoucherFromRegistrar" format="default" sectionF
ormat="of" derivedContent="Section 5.2"/>.</li>
</ol> </ol>
<figure anchor="voucherrequest_example1"> <figure anchor="voucherrequest_example1" align="left" suppress-title="fa
<name>JSON representation of example Voucher-Request</name> lse" pn="figure-6">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-json-representation-of-an-e">JSON Representa
tion of an Example Voucher-Request</name>
<sourcecode type="json" markers="false" pn="section-3.3-3.1">
{ {
"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):" start="2" ind
<li>The following example illustrates a registrar voucher-request. ent="adaptive" pn="section-3.3-4">
The 'prior-signed-voucher-request' leaf is populated with the pl <li pn="section-3.3-4.1" derivedCounter="Example (2):">The following e
edge's xample illustrates a registrar voucher-request.
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" sectionFo rmat="of" derivedContent="Section 5.5"/>.</li>
</ol> </ol>
<figure anchor="voucherrequest_prior_example1"> <figure anchor="voucherrequest_prior_example1" align="left" suppress-tit
<name>JSON representation of example Prior-Signed Voucher-Request</nam le="false" pn="figure-7">
e> <name slugifiedName="name-json-representation-of-an-ex">JSON Represent
<artwork name="" type="" align="left" alt=""><![CDATA[ ation of an Example Prior-Signed Voucher-Request</name>
<sourcecode type="json" markers="false" pn="section-3.3-5.1">
{ {
"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):" start="3" ind
<li>The following example illustrates a registrar voucher-request. ent="adaptive" pn="section-3.3-6">
The 'prior-signed-voucher-request' leaf is not populated with th <li pn="section-3.3-6.1" derivedCounter="Example (3):">The following e
e pledge's xample illustrates a registrar voucher-request.
The prior-signed-voucher-request leaf is not populated with the
pledge's
voucher-request nor is the nonce leaf. This form might be used 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" sectionFo rmat="of" derivedContent="Section 5.5"/>.</li>
</ol> </ol>
<figure anchor="voucherrequest_offline_example1"> <figure anchor="voucherrequest_offline_example1" align="left" suppress-t
<name>JSON representation of Offline Voucher-Request</name> itle="false" pn="figure-8">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-json-representation-of-an-o">JSON Representa
tion of an Offline Voucher-Request</name>
<sourcecode type="json" markers="false" pn="section-3.3-7.1">
{ {
"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="include
" removeInRFC="false" pn="section-3.4">
<section anchor="voucher-request-yang-module" numbered="true" toc="defau <name slugifiedName="name-yang-module">YANG Module</name>
lt"> <t indent="0" pn="section-3.4-1">Following is a YANG module <xref target
<name>YANG Module</name> ="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> that f
<t>Following is a YANG <xref target="RFC7950" format="default"/> module ormally
formally extends a voucher <xref target="RFC8366" format="default" sectionForma
extending the <xref target="RFC8366" format="default"/> voucher into t="of" derivedContent="RFC8366"/> into
a voucher-request.</t> a voucher-request. This YANG module references <xref target="ITU.X690"
<figure anchor="voucherrequest_yang"> format="default" sectionFormat="of" derivedContent="ITU.X690"/>. </t>
<name>YANG module for Voucher-Request</name> <figure anchor="voucherrequest_yang" align="left" suppress-title="false"
<sourcecode name="ietf-voucher-request@2018-02-14.yang" type="" marker pn="figure-9">
s="true"><![CDATA[ <name slugifiedName="name-yang-module-for-voucher-req">YANG Module for
Voucher-Request</name>
<sourcecode name="ietf-voucher-request@2021-05-20.yang" type="yang" ma
rkers="true" pn="section-3.4-2.1">
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: &lt;https://datatracker.ietf.org/wg/anima/&gt;
WG List: <mailto:anima@ietf.org> WG List: &lt;mailto:anima@ietf.org&gt;
Author: Kent Watsen Author: Kent Watsen
<mailto:kent+ietf@watsen.net> &lt;mailto:kent+ietf@watsen.net&gt;
Author: Michael H. Behringer Author: Michael H. Behringer
<mailto:Michael.H.Behringer@gmail.com> &lt;mailto:Michael.H.Behringer@gmail.com&gt;
Author: Toerless Eckert Author: Toerless Eckert
<mailto:tte+ietf@cs.fau.de> &lt;mailto:tte+ietf@cs.fau.de&gt;
Author: Max Pritikin Author: Max Pritikin
<mailto:pritikin@cisco.com> &lt;mailto:pritikin@cisco.com&gt;
Author: Michael Richardson Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>"; &lt;mailto:mcr+ietf@sandelman.ca&gt;";
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-05-20 {
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="include" removeInRFC="fa
<section anchor="proxydetails" numbered="true" toc="default"> lse" pn="section-4">
<name>Proxying details (Pledge - Proxy - <name slugifiedName="name-proxying-details-pledge-pro">Proxying Details (P
Registrar)</name> ledge -- Proxy -- Registrar)</name>
<t> <t indent="0" pn="section-4-1">
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 indent="0" pn="section-4-2">
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 indent="0" pn="section-4-3">
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" format=" default" derivedLink="https://rfc-editor.org/rfc/rfc2663#section-2.9" derivedCon tent="RFC2663"/>).
</t> </t>
<t> <t indent="0" pn="section-4-4">
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" format="defau
lt" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-9.3" derivedContent=
"RFC8446"/> for
details on TLS invariants.
</t> </t>
<t> <t indent="0" pn="section-4-5">
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 indent="0" pn="section-4-6">
As a result of the proxy Discovery process in <xref target="brskigrasp" As a result of the proxy discovery process in <xref target="brskigrasp"
format="default"/>, format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>,
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 indent="0" pn="section-4-7">
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 indent="0" pn="section-4-8">
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 indent="0" pn="section-4-9">
The document <xref target="I-D.richardson-anima-state-for-joinrouter" fo The document <xref target="I-D.richardson-anima-state-for-joinrouter" fo
rmat="default"/> provides a rmat="default" sectionFormat="of" derivedContent="ANIMA-STATE"/> 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="include" removeInRFC="fal
<name>Pledge discovery of Proxy</name> se" pn="section-4.1">
<t> <name slugifiedName="name-pledge-discovery-of-proxy">Pledge Discovery of
Proxy</name>
<t indent="0" pn="section-4.1-1">
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 indent="0" pn="section-4.1-2">To discover the proxy, the pledge perfo rms the following
actions:</t> actions:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
<li>MUST: Obtains a local address using IPv6 1-3">
methods as described in <xref target="RFC4862" format="defau <li pn="section-4.1-3.1" derivedCounter="1.">
lt"/> IPv6 <bcp14>MUST</bcp14>: Obtain a local address using IPv6
Stateless Address AutoConfiguration. methods as described in "IPv6
Use of <xref target="RFC4941" format="default"/> temporary a Stateless Address Autoconfiguration" <xref target="RFC4862"
ddresses is format="default" sectionFormat="of" derivedContent="RFC4862"/>.
encouraged. To limit pervasive monitoring ( Use of temporary addresses <xref target="RFC8981" format="de
<xref target="RFC7258" format="default"/>), a new temporary fault" sectionFormat="of" derivedContent="RFC8981"/> is
address MAY encouraged. To limit pervasive monitoring
<xref target="RFC7258" format="default" sectionFormat="of" d
erivedContent="RFC7258"/>, a new temporary address <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" sectionFormat="of" derivedContent="Appendix A"/>.</li>
<li>MUST: Listen for GRASP M_FLOOD <li pn="section-4.1-3.2" derivedCounter="2.">
(<xref target="I-D.ietf-anima-grasp" format="default"/>) <bcp14>MUST</bcp14>: Listen for GRASP M_FLOOD
<xref target="RFC8990" format="default" sectionFormat="of" d
erivedContent="RFC8990"/>
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" sectionFormat
the details of ="of" derivedContent="Section 4.1.1"/> for the details 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" sectionFormat="of" derivedContent="Appendix B"/>.
</li> </li>
</ol> </ol>
<t> <t indent="0" pn="section-4.1-4">
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 proxy using the bootstrapping protocol defined in <xref target="Prot
ocolDetails" format="default"/>. ocolDetails" format="default" sectionFormat="of" derivedContent="Section 5"/>.
</t> </t>
<t> <t indent="0" pn="section-4.1-5">
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" sectionFormat="of" der
The pledge SHOULD run those methods in parallel with listening ivedContent="Appendix B"/> are active.
to for the M_FLOOD. The active methods SHOULD The pledge <bcp14>SHOULD</bcp14> run those methods in parallel wit
back-off by doubling to a maximum of one hour to avoid overloading h listening
the for the M_FLOOD. The active methods <bcp14>SHOULD</bcp14>
network with discovery attempts. Detection of change of back off by doubling to a maximum of one hour to avoid overloading
physical link status (Ethernet carrier for instance) SHOULD the
reset the back off timers. network with discovery attempts. Detection of
physical link status change (Ethernet carrier, for instance) <bcp1
4>SHOULD</bcp14>
reset the back-off timers.
</t> </t>
<t> <t indent="0" pn="section-4.1-6">
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 indent="0" pn="section-4.1-7">
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 indent="0" pn="section-4.1-8">
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 indent="0" pn="section-4.1-9">
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 indent="0" pn="section-4.1-10">
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 indent="0" pn="section-4.1-11">
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" sectionFormat="of" derivedContent
="Section 5.2"/>.
</t> </t>
<t> <t indent="0" pn="section-4.1-12">
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="include" removeInRFC="
<name>Proxy GRASP announcements</name> false" pn="section-4.1.1">
<t> <name slugifiedName="name-proxy-grasp-announcements">Proxy GRASP Annou
ncements</name>
<t indent="0" pn="section-4.1.1-1">
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" sectionFormat="of" derive dContent="RFC8994"/>.
</t> </t>
<t> <t indent="0" pn="section-4.1.1-2">
The formal Concise Data Definition Language (CDDL) <xref target=" The formal Concise Data Definition Language (CDDL) <xref target="
RFC8610" format="default"/> definition is: RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> definiti
on is:
</t> </t>
<figure anchor="proxy_discovery_cddl"> <figure anchor="proxy_discovery_cddl" align="left" suppress-title="fal
<name>CDDL definition of Proxy Discovery message</name> se" pn="figure-10">
<sourcecode name="proxygrasp.cddl" type="" markers="true"><![CDATA[ <name slugifiedName="name-cddl-definition-of-proxy-di">CDDL Definiti
on of Proxy Discovery Message</name>
<sourcecode name="proxygrasp.cddl" type="CDDL" markers="true" pn="se
ction-4.1.1-3.1">
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 indent="0" pn="section-4.1.1-4">
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" align="left" suppress-title="f
<name>Example of Proxy Discovery message</name> alse" pn="figure-11">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-example-of-proxy-discovery-">Example of Pr
oxy Discovery Message</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1.1-5.1">
[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 indent="0" pn="section-4.1.1-6">
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 indent="0" pn="section-4.1.1-7">
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="include" removeInRFC
<name>CoAP connection to Registrar</name> ="false" pn="section-4.2">
<t> <name slugifiedName="name-coap-connection-to-registra">CoAP Connection t
o Registrar</name>
<t indent="0" pn="section-4.2-1">
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 work. See <xref target="I-D.ietf-anima-constrained-voucher" format="de
fault"/>. fault" sectionFormat="of" derivedContent="ANIMA-CONSTRAINED-VOUCHER"/>.
</t> </t>
</section> </section>
<section anchor="JRCgrasp" numbered="true" toc="default"> <section anchor="JRCgrasp" numbered="true" toc="include" removeInRFC="fals
<name>Proxy discovery and communication of Registrar</name> e" pn="section-4.3">
<t> The registrar SHOULD announce itself so that proxies can find it <name slugifiedName="name-proxy-discovery-and-communi">Proxy Discovery a
nd Communication of Registrar</name>
<t indent="0" pn="section-4.3-1"> The registrar <bcp14>SHOULD</bcp14> an
nounce 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 indent="0" pn="section-4.3-2">
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.
ANI proxies <bcp14>MUST</bcp14> support GRASP discovery of registrars.
</t> </t>
<t> <t indent="0" pn="section-4.3-3">
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" align="left" suppress-titl
<name>An example of a Registrar announcement message</name> e="false" pn="figure-12">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-an-example-of-a-registrar-a">An Example of a
Registrar Announcement Message</name>
<artwork name="" type="" align="left" alt="" pn="section-4.3-4.1">
[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 indent="0" pn="section-4.3-5">
The formal CDDL definition is: The formal CDDL definition is:
</t> </t>
<figure anchor="registrar_discovery_cddl"> <figure anchor="registrar_discovery_cddl" align="left" suppress-title="f
<name>CDDL definition for Registrar announcement message</name> alse" pn="figure-13">
<sourcecode name="jrcgrasp.cddl" type="" markers="true"><![CDATA[ <name slugifiedName="name-cddl-definition-for-registr">CDDL Definition
for Registrar Announcement Message</name>
<sourcecode name="jrcgrasp.cddl" type="CDDL" markers="true" pn="sectio
n-4.3-6.1">
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 indent="0" pn="section-4.3-7">
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 s
ending <bcp14>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 indent="0" pn="section-4.3-8">
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="" pn="section-4.3-9">
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 indent="0" pn="section-4.3-10">
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 indent="0" pn="section-4.3-11">
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 indent="0" pn="section-4.3-12">
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 indent="0" pn="section-4.3-13">
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 indent="0" pn="section-4.3-14">
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" sectionFormat="of"
ST be used for derivedContent="RFC8990"/> <bcp14>MUST</bcp14> 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="include" removeInRFC=
<name>Protocol Details (Pledge - Registrar - MASA)</name> "false" pn="section-5">
<t>The pledge MUST initiate BRSKI after boot if it is unconfigured. <name slugifiedName="name-protocol-details-pledge-reg">Protocol Details (P
The pledge MUST NOT automatically initiate BRSKI if it has been ledge -- Registrar -- MASA)</name>
<t indent="0" pn="section-5-1">The pledge <bcp14>MUST</bcp14> initiate BRS
KI after boot if it is unconfigured.
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 indent="0" pn="section-5-2">
BRSKI is described as extensions to EST <xref target="RFC7030" format= BRSKI is described as extensions to EST <xref target="RFC7030" format=
"default"/>. "default" sectionFormat="of" derivedContent="RFC7030"/>.
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" forma t="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.2.2" deriv edContent="RFC7030"/>. The 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" sectionFormat= "of" derivedContent="Figure 1"/>).
</t> </t>
<t>The communication channel between the registrar and MASA is similarly d <t indent="0" pn="section-5-3">
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" secti
<t> onFormat="of" derivedContent="Figure 1"/>).
</t>
<t indent="0" pn="section-5-4">The MASA URI is "https://" authority "/.wel
l-known/brski".</t>
<t indent="0" pn="section-5-5">
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" sectionFormat="of" derivedCont
ed here, and ent="RFC8259"/> for all new operations defined 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" sectionForma
<xref target="RFC7951" format="default"/> section 6.6. t="comma" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/r
fc4648#section-4" derivedContent="RFC4648"/>) is to be used, as per
<xref target="RFC7951" sectionFormat="comma" section="6.6" format="def
ault" derivedLink="https://rfc-editor.org/rfc/rfc7951#section-6.6" derivedConten
t="RFC7951"/>.
</t> </t>
<t> <t indent="0" pn="section-5-6">
While EST section 3.2 does not insist upon use of HTTP While EST (<xref target="RFC7030" sectionFormat="comma" section="3.2"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.2" de
rivedContent="RFC7030"/>) 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" format="de
BRSKI-EST connections SHOULD use persistent fault" derivedLink="https://rfc-editor.org/rfc/rfc7230#section-6.3" derivedConte
nt="RFC7230"/>),
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 indent="0" pn="section-5-7">
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 indent="0" pn="section-5-8">Summarized automation extensions for the BR
<ul spacing="normal"> SKI-EST flow are:</t>
<li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-9
">
<li pn="section-5-9.1">
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 in series, as explained at the end of <xref target="brskiesttls" f
ormat="default"/>. ormat="default" sectionFormat="of" derivedContent="Section 5.1"/>.
</li> </li>
<li> <li pn="section-5-9.2">
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" sectionFormat="of" derivedContent="Section 5.1"/>.
</li> </li>
<li> <li pn="section-5-9.3">
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>
<li> <li pn="section-5-9.4">
The pledge completes authentication of the server certificate as The pledge completes authentication of the server certificate as
detailed in <xref target="CompletingAuthenticationBootstrapping" f ormat="default"/>. This detailed in <xref target="CompletingAuthenticationBootstrapping" f ormat="default" sectionFormat="of" derivedContent="Section 5.6.1"/>. This
moves the BRSKI-EST TLS connection out of the provisional moves the BRSKI-EST TLS connection out of the provisional
state. state.
</li> </li>
<li> <li pn="section-5-9.5">
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" sectio nFormat="of" derivedContent="Section 5.7"/>).
</li> </li>
</ul> </ul>
<t> <t indent="0" pn="section-5-10">
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 indent="0" pn="section-5-11">The extensions for a registrar (equivalent
<ul spacing="normal"> to an EST server) are:</t>
<li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-1
Client authentication is automated using Initial Device Identity 2">
(IDevID) as per the EST certificate based client authentication. <li pn="section-5-12.1">
The subject field's DN encoding MUST include the "serialNumber" Client authentication is automated using IDevID as per the EST certi
ficate-based client authentication.
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" sectionFormat="of" derivedContent="Section 2.3.1"/>.
</li> </li>
<li>The registrar requests and validates the voucher from the MASA.</li> <li pn="section-5-12.2">The registrar requests and validates the voucher
<li>The registrar forwards the voucher to the pledge when from the MASA.</li>
<li pn="section-5-12.3">The registrar forwards the voucher to the pledge
when
requested.</li> requested.</li>
<li> <li pn="section-5-12.4">
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" sectionFormat=" of" derivedContent="Section 5.8.3"/>) 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="include" removeInRFC="f
<name>BRSKI-EST TLS establishment details</name> alse" pn="section-5.1">
<t>The pledge establishes the TLS connection with the registrar through <name slugifiedName="name-brski-est-tls-establishment">BRSKI-EST TLS Est
the circuit proxy (see <xref target="proxydetails" format="defau ablishment Details</name>
lt"/>) <t indent="0" pn="section-5.1-1">The pledge establishes the TLS connecti
on with the registrar through
the Circuit Proxy (see <xref target="proxydetails" format="defau
lt" sectionFormat="of" derivedContent="Section 4"/>),
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 indent="0" pn="section-5.1-2">
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 indent="0" pn="section-5.1-3">
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" format="default" der
Distribution of CA Certificates" <xref target="RFC7030" format="de ivedLink="https://rfc-editor.org/rfc/rfc7030#section-4.1.1" derivedContent="RFC7
fault"/> wherein 030"/>) of <xref target="RFC7030" format="default" sectionFormat="of" derivedCon
tent="RFC7030"/>, 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 indent="0" pn="section-5.1-4">
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 indent="0" pn="section-5.1-5">
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 indent="0" pn="section-5.1-6">The pledge performs input validation of
until a voucher is verified as specified in <xref target="Complet all data received
ingAuthenticationBootstrapping" format="default"/> and until a voucher is verified as specified in <xref target="Complet
ingAuthenticationBootstrapping" format="default" sectionFormat="of" derivedConte
nt="Section 5.6.1"/> 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 indent="0" pn="section-5.1-7">
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 indent="0" pn="section-5.1-8">
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" sectionForma t="of" derivedContent="slowloris"/>).
</t> </t>
<t> <t indent="0" pn="section-5.1-9">
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="include
"> " removeInRFC="false" pn="section-5.2">
<name>Pledge Requests Voucher from the Registrar</name> <name slugifiedName="name-pledge-requests-voucher-fro">Pledge Requests V
<t>When the pledge bootstraps it makes a request for a voucher from a oucher from the Registrar</name>
<t indent="0" pn="section-5.2-1">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 indent="0" pn="section-5.2-2">This is done with an HTTPS POST using t
"/.well-known/est/requestvoucher".</t> he operation path value of
<t>The pledge voucher-request Content-Type is:</t> "/.well-known/brski/requestvoucher".</t>
<dl newline="false" spacing="normal"> <t indent="0" pn="section-5.2-3">The pledge voucher-request Content-Type
<dt>application/voucher-cms+json</dt> is as follows.</t>
<dd> <dl newline="false" spacing="normal" indent="3" pn="section-5.2-4">
<xref target="RFC8366" format="default"/> defines a <dt pn="section-5.2-4.1">application/voucher-cms+json:</dt>
"YANG-defined JSON document that has been signed using a CMS <dd pn="section-5.2-4.2">
<xref target="RFC8366" format="default" sectionFormat="of" derivedCo
ntent="RFC8366"/> defines a "YANG-defined JSON document that has been signed usi
ng a Cryptographic Message Syntax (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 <xref target="voucher-request" format="default" sectionFormat="of" de
ame way. rivedContent="Section 3"/> is created in the same way.
The media type is the same as defined in <xref target="RFC8366" forma The media type is the same as defined in <xref target="RFC8366" forma
t="default"/>. t="default" sectionFormat="of" derivedContent="RFC8366"/>.
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" sectio
nFormat="of" derivedContent="Section 2.3"/>.
</dd> </dd>
</dl> </dl>
<t>Registrar <t indent="0" pn="section-5.2-5">Registrar
implementations SHOULD anticipate future media types but of course will implementations <bcp14>SHOULD</bcp14> anticipate future media types but,
simply fail the request if those of course, will simply fail the request if those
types are not yet known.</t> types are not yet known.</t>
<t> <t indent="0" pn="section-5.2-6">
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc72
cher 31#section-5.3.2" derivedContent="RFC7231"/>) indicating the acceptable media ty
pe for the voucher
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" sectionFormat="of" derivedC ontent="RFC8366"/>, 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 indent="0" pn="section-5.2-7">The pledge populates the voucher-reques
<dl newline="false" spacing="normal"> t fields as follows:</t>
<dt>created-on:</dt> <dl newline="false" spacing="normal" indent="3" pn="section-5.2-8">
<dd>Pledges that have a realtime clock are <dt pn="section-5.2-8.1">created-on:</dt>
RECOMMENDED to populate this field with the current date and <dd pn="section-5.2-8.2">Pledges that have a real-time clock are
<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 pn="section-5.2-8.3">nonce:</dt>
<dd>The pledge voucher-request MUST contain a <dd pn="section-5.2-8.4">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 " format="default" derivedLink="https://rfc-editor.org/rfc/rfc4086#section-6.2"
there is a concern that the same nonce might generated across derivedContent="RFC4086"/>).
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
clock as explained in <xref target="timeunknown" format="default"/>. e
clock as explained in <xref target="timeunknown" format="default" se
ctionFormat="of" derivedContent="Section 2.6.1"/>.
</dd> </dd>
<dt>assertion:</dt> <dt pn="section-5.2-8.5">assertion:</dt>
<dd> <dd pn="section-5.2-8.6">
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 pn="section-5.2-8.7">proximity-registrar-cert:</dt>
<dd>In a pledge <dd pn="section-5.2-8.8">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" format="default" derivedLink="https://rfc-editor.org/r
fc/rfc8446#section-4.4.2" derivedContent="RFC8446"/>) 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 pn="section-5.2-8.9">serial-number:</dt>
<dd>The serial number of the pledge <dd pn="section-5.2-8.10">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" sectionFormat="of" derivedContent="Section 5.5"/>.
</dd> </dd>
</dl> </dl>
<t>All other fields MAY be omitted in the pledge voucher-request.</t> <t indent="0" pn="section-5.2-9">All other fields <bcp14>MAY</bcp14> be
<t>An example JSON payload of a pledge voucher-request is in omitted in the pledge voucher-request.</t>
<xref target="voucher-request-examples" format="default"/> Example 1 <t indent="0" pn="section-5.2-10">See an example JSON payload of a pledg
.</t> e voucher-request in
<t> <xref target="voucher-request-examples" format="default" sectionForm
at="of" derivedContent="Section 3.3"/>, Example 1.</t>
<t indent="0" pn="section-5.2-11">
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="include" remove
<name>Registrar Authorization of InRFC="false" pn="section-5.3">
Pledge</name> <name slugifiedName="name-registrar-authorization-of-">Registrar Authori
<t> zation of Pledge</name>
In a fully automated network all devices must be securely identified <t indent="0" pn="section-5.3-1">
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 indent="0" pn="section-5.3-2">
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" bare="false" empty="false" indent="3" pn="section-5
<li>allow any device of a specific type (as determined by the X.509 .3-3">
<li pn="section-5.3-3.1">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 pn="section-5.3-3.2">any device from a specific vendor (as determi ned 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 pn="section-5.3-3.3">a specific device from a vendor (as determine
IDevID) against a domain white list. (The mechanism for checking d by the X.509
a shared white list potentially used by multiple Registrars is out IDevID) against a domain acceptlist. (The mechanism for checking
of scope).</li> a shared acceptlist potentially used by multiple registrars is out
of scope.)</li>
</ul> </ul>
<t> <t indent="0" pn="section-5.3-4">
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 indent="0" pn="section-5.3-5">If authorization is successful, the reg
he MASA service (see istrar obtains a voucher from the MASA service (see
<xref target="RequestVoucherFromMASA" format="default"/>) and return <xref target="RequestVoucherFromMASA" format="default" sectionFormat
s that MASA signed voucher to the pledge ="of" derivedContent="Section 5.5"/>) and returns that MASA-signed voucher to th
as described in <xref target="VoucherResponse" format="default"/>.</t> e pledge
as described in <xref target="VoucherResponse" format="default" sectionF
ormat="of" derivedContent="Section 5.6"/>.</t>
</section> </section>
<section anchor="brskimasatls" numbered="true" toc="default"> <section anchor="brskimasatls" numbered="true" toc="include" removeInRFC="
<name>BRSKI-MASA TLS establishment details</name> false" pn="section-5.4">
<t> <name slugifiedName="name-brski-masa-tls-establishmen">BRSKI-MASA TLS Es
The BRSKI-MASA TLS connection is a 'normal' TLS connection tablishment Details</name>
<t indent="0" pn="section-5.4-1">
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" sectionFormat="of" deriv
<xref target="RFC6125" format="default"/> SHOULD be used in authentica edContent="Section 2.8"/>. The mechanisms in
tion of the <xref target="RFC6125" format="default" sectionFormat="of" derivedCont
ent="RFC6125"/> <bcp14>SHOULD</bcp14> be used 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 indent="0" pn="section-5.4-2">
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 indent="0" pn="section-5.4-3">
As described in <xref target="RFC7030" format="default"/>, the MASA an As described in <xref target="RFC7030" format="default" sectionFormat=
d the "of" derivedContent="RFC7030"/>, the MASA and 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 indent="0" pn="section-5.4-4">
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 indent="0" pn="section-5.4-5">
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" sectionFormat="of" derivedContent="Section 5.8"/>.
</t> </t>
<t> <t indent="0" pn="section-5.4-6">
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="include" remov
<name>MASA authentication of eInRFC="false" pn="section-5.4.1">
customer Registrar</name> <name slugifiedName="name-masa-authentication-of-cust">MASA Authentica
<t> tion of Customer Registrar</name>
Providing per-customer options requires that the customer's <t indent="0" pn="section-5.4.1-1">
registrar be uniquely identified. This can be done by any stateless Providing per-customer options requires the customer's
method that HTTPS supports such as with HTTP Basic registrar to be uniquely identified. This can be done by any statel
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 indent="0" pn="section-5.4.1-2">
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 indent="0" pn="section-5.4.1-3">
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 indent="0" pn="section-5.4.1-4">
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 indent="0" pn="section-5.4.1-5">
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 indent="0" pn="section-5.4.1-6">
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 indent="0" pn="section-5.4.1-7">
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" sectionFormat="of" derivedContent="Section 7.4.2"/>.
</t> </t>
<t> <t indent="0" pn="section-5.4.1-8">
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="include" rem
<name>Registrar Requests Voucher from MASA</name> oveInRFC="false" pn="section-5.5">
<t> <name slugifiedName="name-registrar-requests-voucher-">Registrar Request
When a registrar receives a pledge voucher-request it in turn s Voucher from MASA</name>
<t indent="0" pn="section-5.5-1">
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" sectionFormat= "of" derivedContent="RFC7231"/>.
</t> </t>
<t>This is done with an HTTP POST using the operation path value of <t indent="0" pn="section-5.5-2">This is done with an HTTP POST using th
"/.well-known/est/requestvoucher".</t> e operation path value of
<t>The voucher media type "application/voucher-cms+json" is defined in "/.well-known/brski/requestvoucher".</t>
<xref target="RFC8366" format="default"/> and is also used for the reg <t indent="0" pn="section-5.5-3">The voucher media type "application/vou
istrar voucher-request. It is a JSON document that has been cher-cms+json" is defined in
<xref target="RFC8366" format="default" sectionFormat="of" derivedCont
ent="RFC8366"/> and is also used for the registrar 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 indent="0" pn="section-5.5-4">
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 indent="0" pn="section-5.5-5">
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 <xref target="RFC8366" format="default" sectionFormat="of" derivedCont
y be put into ent="RFC8366"/> is quite flexible in what may 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 indent="0" pn="section-5.5-6">
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 indent="0" pn="section-5.5-7">
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 indent="0" pn="section-5.5-8">
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 indent="0" pn="section-5.5-9">
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" format="default
5.3.2 "Accept" header field indicating the response media types that a " derivedLink="https://rfc-editor.org/rfc/rfc7231#section-5.3.2" derivedContent=
re "RFC7231"/>) indicating the response
acceptable. This list SHOULD be the entire list presented to the media types that are
Registrar in the Pledge's original request (see <xref target="RequestV acceptable. This list <bcp14>SHOULD</bcp14> be the entire list present
oucherFromRegistrar" format="default"/>) but MAY be a subset. ed to the
registrar in the pledge's original request (see <xref target="RequestV
oucherFromRegistrar" format="default" sectionFormat="of" derivedContent="Section
5.2"/>), 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 indent="0" pn="section-5.5-10">The registrar populates the voucher-re
<dl newline="false" spacing="normal"> quest fields as follows:</t>
<dt>created-on:</dt> <dl newline="false" spacing="normal" indent="3" pn="section-5.5-11">
<dd> <dt pn="section-5.5-11.1">created-on:</dt>
The Registrars SHOULD populate this field with the current date and <dd pn="section-5.5-11.2">
time when the Registrar formed this voucher request. This field The registrar <bcp14>SHOULD</bcp14> populate this field with the curre
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 pn="section-5.5-11.3">nonce:</dt>
<dd>This value, if present, is copied from the pledge <dd pn="section-5.5-11.4">This value, if present, is copied from the p
voucher-request. The registrar voucher-request MAY omit ledge
the nonce as per <xref target="noncelessVoucherRequest" format="defa voucher-request. The registrar voucher-request <bcp14>MAY</bcp14> om
ult"/>. it
the nonce as per <xref target="noncelessVoucherRequest" format="defa
ult" sectionFormat="of" derivedContent="Section 3.1"/>.
</dd> </dd>
<dt>serial-number:</dt> <dt pn="section-5.5-11.5">serial-number:</dt>
<dd>The serial number of the pledge the registrar would like a voucher <dd pn="section-5.5-11.6">The serial number of the pledge the registra
for. The registrar r 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" sectionFormat="of" der
The registrar MUST verify that the serial number field it parsed matches ivedContent="Section 2.3"/>.
the serial number field the pledge The registrar <bcp14>MUST</bcp14> verify that the serial-number field it
parsed matches the serial-number field the pledge
provided in its voucher-request. This provides a sanity check useful for detecting error conditions and logging. 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 pn="section-5.5-11.7">idevid-issuer:</dt>
<dd>The Issuer value from the <dd pn="section-5.5-11.8">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 pn="section-5.5-11.9">prior-signed-voucher-request:</dt>
<dd>The signed pledge <dd pn="section-5.5-11.10">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 indent="0" pn="section-5.5-12">
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 indent="0" pn="section-5.5-13">All other fields <bcp14>MAY</bcp14> be omitted in the registrar
voucher-request.</t> voucher-request.</t>
<t> <t indent="0" pn="section-5.5-14">
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 indent="0" pn="section-5.5-15">See example JSON payloads of registrar
<xref target="voucher-request-examples" format="default"/> Examples voucher-requests in
2 through 4.</t> <xref target="voucher-request-examples" format="default" sectionForm
<t>The MASA verifies that the registrar voucher-request is internally co at="of" derivedContent="Section 3.3"/>, Examples 2 through 4.</t>
nsistent <t indent="0" pn="section-5.5-16">The MASA verifies that the registrar v
oucher-request is internally consistent
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="include" removeInRFC="false" pn="section-5
<name>MASA renewal of expired vouchers</name> .5.1">
<t> <name slugifiedName="name-masa-renewal-of-expired-vou">MASA Renewal of
Expired Vouchers</name>
<t indent="0" pn="section-5.5.1-1">
As described in As described in
<xref target="RFC8366" format="default"/> vouchers <xref target="RFC8366" format="default" sectionFormat="of" derivedCo ntent="RFC8366"/>, 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 " sectionFormat="of" derivedContent="Section 5.6"/>.
</t> </t>
<t>To inform the MASA that existing vouchers are not to be renewed one <t indent="0" pn="section-5.5.1-2">To inform the MASA that existing vo
can update or revoke the registrar credentials used to authorize the uchers are not to be renewed, one
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" sectio
nFormat="of" derivedContent="5.5.4"/> and <xref target="revocationcheck" format=
"counter" sectionFormat="of" derivedContent="5.5.3"/>). 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="include" removeInRFC="
<name>MASA pinning of registrar</name> false" pn="section-5.5.2">
<t> <name slugifiedName="name-masa-pinning-of-registrar">MASA Pinning of R
A certificate chain is extracted from the Registrar's signed CMS con egistrar</name>
tainer. <t indent="0" pn="section-5.5.2-1">
This chain may be as short as a single End-Entity Certificate, up A certificate chain is extracted from the registrar's signed CMS con
to the entire registrar certificate chain, including the Domain tainer.
This chain may be as short as a single end-entity certificate, up
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" sectionFormat="of" derivedContent="Section 5.5"/>.
</t> </t>
<t> <t indent="0" pn="section-5.5.2-2">
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 indent="0" pn="section-5.5.2-3">
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.
certificate. This is consistent with <xref target="RFC8366" format=" A MASA <bcp14>MAY</bcp14> have a local policy in which it only pins
default"/>. the end-entity
certificate. This is consistent with <xref target="RFC8366" format="
default" sectionFormat="of" derivedContent="RFC8366"/>.
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="include" removeIn
<name>MASA checking of voucher request signature</name> RFC="false" pn="section-5.5.3">
<t> <name slugifiedName="name-masa-check-of-the-voucher-r">MASA Check of t
As described in <xref target="MASApinned" format="default"/>, the MA he Voucher-Request Signature</name>
SA has <t indent="0" pn="section-5.5.3-1">
extracted Registrar's domain CA. This is used to validate the As described in <xref target="MASApinned" format="default" sectionFo
CMS signature (<xref target="RFC5652" format="default"/>) on the vou rmat="of" derivedContent="Section 5.5.2"/>, the MASA has
cher-request. extracted the registrar's domain CA. This is used to validate the
CMS signature <xref target="RFC5652" format="default" sectionFormat=
"of" derivedContent="RFC5652"/> on the voucher-request.
</t> </t>
<t> <t indent="0" pn="section-5.5.3-2">
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" sectionFormat="of" derivedContent="RFC6960"/>. If they are p
resent, 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 indent="0" pn="section-5.5.3-3">
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 <section anchor="MASAauthenticationOfRegistrar" numbered="true" toc="inc
ault"> lude" removeInRFC="false" pn="section-5.5.4">
<name>MASA verification of domain registrar</name> <name slugifiedName="name-masa-verification-of-the-do">MASA Verificati
<t> on of the Domain Registrar</name>
The MASA MUST verify that the registrar voucher-request is signed <t indent="0" pn="section-5.5.4-1">
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" for mat="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.6.1" der ivedContent="RFC7030"/>) 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 indent="0" pn="section-5.5.4-2">
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 indent="0" pn="section-5.5.4-3">
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 indent="0" pn="section-5.5.4-4">
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#secti
on-3.2.3" derivedContent="RFC7030"/> and
<xref target="RFC7030" sectionFormat="bare" section="3.3.2" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.3.2" derivedContent="RFC7
030"/> of
<xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC70
30"/>)
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 indent="0" pn="section-5.5.4-5">
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="include" removeInRF
<name>MASA verification of pledge prior-signed-voucher-request</name> C="false" pn="section-5.5.5">
<t> <name slugifiedName="name-masa-verification-of-the-pl">MASA Verificati
The MASA MAY verify that the registrar voucher-request on of the Pledge 'prior-signed-voucher-request'</name>
includes the 'prior-signed-voucher-request' field. If so the <t indent="0" pn="section-5.5.5-1">
prior-signed-voucher-request MUST include a The MASA <bcp14>MAY</bcp14> verify that the registrar voucher-reques
'proximity-registrar-cert' that is consistent with the t
includes the prior-signed-voucher-request field. If so, 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" format="d efault" derivedLink="https://rfc-editor.org/rfc/rfc7469#section-2.6" derivedCont ent="RFC7469"/>.
</t> </t>
<t> <t indent="0" pn="section-5.5.5-2">
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 ection 5.3. assertion, as defined by <xref target="RFC8366" sectionFormat="comma " section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8366 #section-5.3" derivedContent="RFC8366"/>.
</t> </t>
</section> </section>
<section anchor="MASAnoncehandling" numbered="true" toc="default"> <section anchor="MASAnoncehandling" numbered="true" toc="include" remove
<name>MASA nonce handling</name> InRFC="false" pn="section-5.5.6">
<t> <name slugifiedName="name-masa-nonce-handling">MASA Nonce Handling</na
me>
<t indent="0" pn="section-5.5.6-1">
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" sect
<xref target="MASAauthenticationOfRegistrar" format="default"/>). ionFormat="of" derivedContent="5.5"/> and
<xref target="MASAauthenticationOfRegistrar" format="counter" sectio
nFormat="of" derivedContent="5.5.4"/>.)
</t> </t>
<t> <t indent="0" pn="section-5.5.6-2">
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="include" removeInRF
<name>MASA and Registrar Voucher Response</name> C="false" pn="section-5.6">
<t>The MASA voucher response to the registrar is forwarded <name slugifiedName="name-masa-and-registrar-voucher-">MASA and Registra
without changes to the pledge; therefore this section applies r Voucher Response</name>
<t indent="0" pn="section-5.6-1">The MASA voucher response to the regist
rar is forwarded
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 indent="0" pn="section-5.6-2">
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 indent="0" pn="section-5.6-3">
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" sectionForma t="of" derivedContent="Section 5.8.3"/>); therefore, 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 indent="0" pn="section-5.6-4">
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>
suitable 4xx or 5xx HTTP <xref target="RFC7230" format="default"/> err contain an HTTP 200 response code. The server <bcp14>MUST</bcp14> answ
or code when a problem occurs. er with a
In this case, the response data from the MASA MUST be a plaintext suitable 4xx or 5xx HTTP <xref target="RFC7230" format="default" secti
onFormat="of" derivedContent="RFC7230"/> error code when a problem occurs.
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 indent="0" pn="section-5.6-5">
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section
client "MUST wait at least the specified 'Retry-After' time before -4.2.3" derivedContent="RFC7030"/>, wherein the
repeating the same request". client "<bcp14>MUST</bcp14> wait at least the specified "retry-after"
(see <xref target="RFC7231" format="default"/> section 6.6.4) time before
The pledge is RECOMMENDED to provide local repeating the same request"
feedback (blinked LED etc) during this wait cycle if mechanisms for th (also see <xref target="RFC7231" sectionFormat="comma" section="6.6.4"
is format="default" derivedLink="https://rfc-editor.org/rfc/rfc7231#section-6.6.4"
derivedContent="RFC7231"/>).
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 indent="0" pn="section-5.6-6">
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 indent="0" pn="section-5.6-7">
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 indent="0" pn="section-5.6-8">A 403 (Forbidden) response is appropria
is not signed correctly, stale, or if the pledge has another te if the voucher-request
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 indent="0" pn="section-5.6-9">A 404 (Not Found) response is appropria te 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 indent="0" pn="section-5.6-10">A 406 (Not Acceptable) response is app
desired type or using the desired algorithms (as indicated by the ropriate if a voucher of the
Accept: header fields, and algorithms used in the signature) cannot be desired type or that uses the desired algorithms (as indicated by the
issued such as because the MASA knows the pledge cannot process "Accept" header fields and algorithms used in the signature) cannot be
that type. The registrar SHOULD use this response if it determines issued as such because the MASA knows the pledge cannot process
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 indent="0" pn="section-5.6-11">
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 indent="0" pn="section-5.6-12">The voucher response format is as indi
Accept header fields or based on the MASA's prior understanding of prope cated in the submitted
r "Accept" header fields or based on the MASA's prior understanding of pro
format for this Pledge. Only the <xref target="RFC8366" format="default" per
/> format for this pledge. Only the
"application/voucher-cms+json" media type is defined at this "application/voucher-cms+json" media type <xref target="RFC8366" format=
"default" sectionFormat="of" derivedContent="RFC8366"/> 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" sectionFormat="of" derivedConten t="RFC8366"/>. <xref target="voucherjsonexample" format="default" sectionFormat= "of" derivedContent="Figure 14"/> 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" align="left" suppress-title="false"
<name>An example voucher</name> pn="figure-14">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-an-example-voucher">An Example Voucher</name
>
<sourcecode type="json" markers="false" pn="section-5.6-13.1">
{ {
"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 indent="0" pn="section-5.6-14">The MASA populates the voucher fields
<dl newline="false" spacing="normal"> as follows:</t>
<dt>nonce:</dt> <dl newline="false" spacing="normal" indent="3" pn="section-5.6-15">
<dd>The nonce from the pledge if available. See <xref target="MASAnonc <dt pn="section-5.6-15.1">nonce:</dt>
ehandling" format="default"/>.</dd> <dd pn="section-5.6-15.2">The nonce from the pledge if available. See
<dt>assertion:</dt> <xref target="MASAnoncehandling" format="default" sectionFormat="of" derivedCont
<dd>The method used to verify the relationship ent="Section 5.5.6"/>.</dd>
between pledge and registrar. See <xref target="MASAassertion" format="d <dt pn="section-5.6-15.3">assertion:</dt>
efault"/>.</dd> <dd pn="section-5.6-15.4">The method used to verify the relationship
<dt>pinned-domain-cert:</dt> between the pledge and registrar. See <xref target="MASAassertion" forma
<dd>A certificate. See <xref target="MASApinned" format="default"/>. T t="default" sectionFormat="of" derivedContent="Section 5.5.5"/>.</dd>
his figure is illustrative, for an example, <dt pn="section-5.6-15.5">pinned-domain-cert:</dt>
see <xref target="exampleprocess" format="default"/> where an End Entity <dd pn="section-5.6-15.6">A certificate; see <xref target="MASApinned"
certificate format="default" sectionFormat="of" derivedContent="Section 5.5.2"/>. This figu
re is illustrative; for an example,
see <xref target="exampleprocess" format="default" sectionFormat="of" de
rivedContent="Appendix C.2"/> where an end-entity certificate
is used. </dd> is used. </dd>
<dt>serial-number:</dt> <dt pn="section-5.6-15.7">serial-number:</dt>
<dd>The serial-number as provided in the <dd pn="section-5.6-15.8">The serial-number as provided in the
voucher-request. Also see <xref target="MASAassertion" format="default voucher-request. Also see <xref target="MASAassertion" format="default
"/>.</dd> " sectionFormat="of" derivedContent="Section 5.5.5"/>.</dd>
<dt>domain-cert-revocation-checks:</dt> <dt pn="section-5.6-15.9">domain-cert-revocation-checks:</dt>
<dd>Set as appropriate for the <dd pn="section-5.6-15.10">Set as appropriate for the
pledge's capabilities and as documented in <xref target="RFC8366" form pledge's capabilities and as documented in <xref target="RFC8366" form
at="default"/>. at="default" sectionFormat="of" derivedContent="RFC8366"/>.
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.< <xref target="RFC6961" format="default" sectionFormat="of" derivedCont
/dd> ent="RFC6961"/>, <xref target="RFC8446" sectionFormat="of" section="4.4.2.1" for
<dt>expires-on:</dt> mat="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.4.2.1" d
<dd>This is set for nonceless vouchers. The MASA erivedContent="RFC8446"/>, or equivalent integrations.</dd>
<dt pn="section-5.6-15.11">expires-on:</dt>
<dd pn="section-5.6-15.12">This is set for nonceless vouchers. The MAS
A
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" sectionFormat="of" der ivedContent="Section 2.6.1"/>. There are three times 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 indent="0" pn="section-5.6-16">
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" sectionFormat="of" derive dContent="Section 5.8.1"/>.
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" <section anchor="CompletingAuthenticationBootstrapping" numbered="true"
toc="default"> toc="include" removeInRFC="false" pn="section-5.6.1">
<name>Pledge voucher verification</name> <name slugifiedName="name-pledge-voucher-verification">Pledge Voucher
<t> Verification</name>
The pledge MUST verify the voucher signature using the <t indent="0" pn="section-5.6.1-1">
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 indent="0" pn="section-5.6.1-2">
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 indent="0" pn="section-5.6.1-3">
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" sectionFormat="of" derivedContent="Section 7.2"/>).
</t> </t>
<t> <t indent="0" pn="section-5.6.1-4">
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 indent="0" pn="section-5.6.1-5">
The pledge MUST be prepared to ignore additional fields that it does n The pledge <bcp14>MUST</bcp14> be prepared to ignore additional fields
ot recognize. that it does not recognize.
</t> </t>
</section> </section>
<section anchor="PledgeAuthenticationOfProvisionalTLS" numbered="true" t <section anchor="PledgeAuthenticationOfProvisionalTLS" numbered="true" t
oc="default"> oc="include" removeInRFC="false" pn="section-5.6.2">
<name>Pledge authentication of provisional TLS connection</name> <name slugifiedName="name-pledge-authentication-of-pr">Pledge Authenti
<t> cation of Provisional TLS Connection</name>
Following the process described in <xref target="RFC8366" format="de <t indent="0" pn="section-5.6.2-1">
fault"/>, Following the process described in <xref target="RFC8366" format="de
fault" sectionFormat="of" derivedContent="RFC8366"/>,
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 indent="0" pn="section-5.6.2-2">
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 indent="0" pn="section-5.6.2-3">
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 indent="0" pn="section-5.6.2-4"> 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 <t indent="0" pn="section-5.6.2-5">The pledge's PKIX path validation o
dity f a registrar certificate's validity
period information is as described in <xref target="timeunknown" for period information is as described in <xref target="timeunknown" for
mat="default"/>. mat="default" sectionFormat="of" derivedContent="Section 2.6.1"/>.
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 indent="0" pn="section-5.6.2-6">The pinned-domain-cert <bcp14>MAY</
trust anchor for future operations such as enrollment (e.g. <xref ta bcp14> be installed as a
rget="RFC7030" format="default"/> as recommended) or trust anchor management or trust anchor for future operations such as enrollment (e.g., as reco
raw protocols that do not need full PKI based key management. It can be used to mmended per <xref target="RFC7030" format="default" sectionFormat="of" derivedCo
authenticate any dynamically ntent="RFC7030"/>) or trust anchor management or raw protocols that do not need
discovered EST server that contain the id-kp-cmcRA extended key full PKI-based key management. It can be used to authenticate any dynamically
usage extension as detailed in EST RFC7030 section 3.6.1; but to discovered EST server that contains the id-kp-cmcRA extended key
reduce system complexity the pledge SHOULD avoid additional usage extension as detailed in EST (see <xref target="RFC7030" secti
discovery operations. Instead the pledge SHOULD communicate directly onFormat="comma" section="3.6.1" format="default" derivedLink="https://rfc-edito
with the registrar as the EST server. The 'pinned-domain-cert' r.org/rfc/rfc7030#section-3.6.1" derivedContent="RFC7030"/>); but to
reduce system complexity, the pledge <bcp14>SHOULD</bcp14> avoid add
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 n 4.1.3 CA Certificate Response, distribution of the CA certificate response, as described in <xref t arget="RFC7030" sectionFormat="comma" section="4.1.3" format="default" derivedLi nk="https://rfc-editor.org/rfc/rfc7030#section-4.1.3" derivedContent="RFC7030"/> ,
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="include" removeInRFC="
<name>Pledge BRSKI Status Telemetry</name> false" pn="section-5.7">
<t>The domain is expected to provide indications to the system <name slugifiedName="name-pledge-brski-status-telemet">Pledge BRSKI Stat
administrators concerning device lifecycle status. To facilitate this us Telemetry</name>
<t indent="0" pn="section-5.7-1">The domain is expected to provide indic
ations to the system
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 indent="0" pn="section-5.7-2">The pledge <bcp14>MUST</bcp14> indicate
It does this by sending a status message to the Registrar.</t> its pledge status regarding the voucher.
<t>The posted data media type: application/json</t> It does this by sending a status message to the registrar.</t>
<t>The client sends an HTTP POST to the server at the URI ".well-known/e <t indent="0" pn="section-5.7-3">The posted data media type: application
st/voucher_status".</t> /json</t>
<t> <t indent="0" pn="section-5.7-4">The client sends an HTTP POST to the se
rver at the URI ".well-known/brski/voucher_status".</t>
<t indent="0" pn="section-5.7-5">
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 indent="0" pn="section-5.7-6">The status field indicates if the vouch er 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 indent="0" pn="section-5.7-7">
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 indent="0" pn="section-5.7-8">
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 indent="0" pn="section-5.7-9">
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 indent="0" pn="section-5.7-10">
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
<xref target="telemetryexample" format="default"/> shows an example JS > be lowercase.
ON. <xref target="telemetryexample" format="default" sectionFormat="of" de
rivedContent="Figure 16"/> shows an example JSON.
</t> </t>
<figure anchor="telemetryexample"> <figure anchor="cddl-voucherstatus" align="left" suppress-title="false"
<name>Example Status Telemetry</name> pn="figure-15">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-cddl-for-voucher-status-pos">CDDL for Vouche
r Status POST</name>
<sourcecode name="voucherstatus.cddl" type="CDDL" markers="true" pn="s
ection-5.7-11.1">
voucherstatus-post = {
"version": uint,
"status": bool,
? "reason": text,
? "reason-context" : { $$arbitrary-map }
}
}
</sourcecode>
</figure>
<figure anchor="telemetryexample" align="left" suppress-title="false" pn
="figure-16">
<name slugifiedName="name-example-status-telemetry">Example Status Tel
emetry</name>
<sourcecode type="json" markers="false" pn="section-5.7-12.1">
{ {
"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 indent="0" pn="section-5.7-13">
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 indent="0" pn="section-5.7-14">
Additional standard JSON fields in this POST MAY be added, see Additional standard JSON fields in this POST <bcp14>MAY</bcp14> be add
<xref target="pledgestatustelemetryregistry" format="default"/>. A se ed; see
rver that <xref target="pledgestatustelemetryregistry" format="default" sectionF
ormat="of" derivedContent="Section 8.5"/>. A server 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="include" removeInRF
<name>Registrar audit-log request</name> C="false" pn="section-5.8">
<t> <name slugifiedName="name-registrar-audit-log-request">Registrar Audit-L
After receiving the pledge status telemetry <xref target="pledgestatu og Request</name>
s" format="default"/>, <t indent="0" pn="section-5.8-1">
the registrar SHOULD request the MASA audit-log from the MASA After receiving the pledge status telemetry (see <xref target="pledge
service.</t> status" format="default" sectionFormat="of" derivedContent="Section 5.7"/>),
<t> the registrar <bcp14>SHOULD</bcp14> request the MASA audit-log from t
he MASA
service.</t>
<t indent="0" pn="section-5.8-2">
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 indent="0" pn="section-5.8-3">
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 indent="0" pn="section-5.8-4">
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 indent="0" pn="section-5.8-5">
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 indent="0" pn="section-5.8-6">
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 indent="0" pn="section-5.8-7">
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" format="default" sectionFormat="of" d
erivedContent="RFC7231"/>, Sections
<xref target="RFC7231" sectionFormat="bare" section="6.3.2" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc7231#section-6.3.2" derivedContent="RFC7
231"/> and <xref target="RFC7231" sectionFormat="bare" section="7.1" format="def
ault" derivedLink="https://rfc-editor.org/rfc/rfc7231#section-7.1" derivedConten
t="RFC7231"/>), 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 indent="0" pn="section-5.8-8">
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" sectionFormat="of" derivedContent="W3C.capability-urls"/> provides very good 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 indent="0" pn="section-5.8-9">
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="include" removeInRFC
<name>MASA audit log response</name> ="false" pn="section-5.8.1">
<t>A log data file is returned consisting of all log entries <name slugifiedName="name-masa-audit-log-response">MASA Audit-Log Resp
onse</name>
<t indent="0" pn="section-5.8.1-1">A log data file is returned consist
ing 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" sectionFormat="of" derivedContent="RFC8259"/>,
and the Content-Type SHOULD be "application/json". and the Content-Type <bcp14>SHOULD</bcp14> be "application/json".
</t> </t>
<t> <t indent="0" pn="section-5.8.1-2">
The following CDDL (<xref target="RFC8610" format="default"/>) expla The following CDDL <xref target="RFC8610" format="default" sectionFo
ins the rmat="of" derivedContent="RFC8610"/> explains 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" align="left" suppress-title="false" pn=
<name>CDDL for audit-log response</name> "figure-17">
<sourcecode name="auditlog.cddl" type="" markers="true"><![CDATA[ <name slugifiedName="name-cddl-for-audit-log-response">CDDL for Audi
t-Log Response</name>
<sourcecode name="auditlog.cddl" type="CDDL" markers="true" pn="sect
ion-5.8.1-3.1">
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,
} }
} }
event = { event = {
"date": text, "date": text,
"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 indent="0" pn="section-5.8.1-4">An example:
</t> </t>
<figure anchor="example-auditlog"> <figure anchor="example-auditlog" align="left" suppress-title="false"
<name>Example of audit-log response</name> pn="figure-18">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-example-of-an-audit-log-res">Example of an
Audit-Log Response</name>
<sourcecode type="json" markers="false" pn="section-5.8.1-5.1">
{ {
"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 3406
"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 indent="0" pn="section-5.8.1-6">
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" sectionFormat= "of" derivedContent="Section 5.8.2"/>.
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 indent="0" pn="section-5.8.1-7">
The date is in <xref target="RFC3339" format="default"/> format, whi The date is formatted per <xref target="RFC3339" format="default" se
ch is ctionFormat="of" derivedContent="RFC3339"/>, which is
consistent with typical JavaScript usage of JSON. consistent with typical JavaScript usage of JSON.
</t> </t>
<t> <t indent="0" pn="section-5.8.1-8">
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 indent="0" pn="section-5.8.1-9">
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 indent="0" pn="section-5.8.1-10">
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 indent="0" pn="section-5.8.1-11">
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 indent="0" pn="section-5.8.1-12">
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 indent="0" pn="section-5.8.1-13">
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 indent="0" pn="section-5.8.1-14">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="include" removeInRFC="fa
<name>Calculation of domainID</name> lse" pn="section-5.8.2">
<t> <name slugifiedName="name-calculation-of-domainid">Calculation of doma
inID</name>
<t indent="0" pn="section-5.8.2-1">
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 indent="0" pn="section-5.8.2-2">
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" format="default" derivedLink="https://rfc-editor.o
4.2.1.2</xref>), then it is to be used as the domainID. If not, rg/rfc/rfc5280#section-4.2.1.2" derivedContent="RFC5280"/>), then it is 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" format="d
This value needs to be calculated by both MASA (to efault" derivedLink="https://rfc-editor.org/rfc/rfc7469#section-2.4" derivedCont
populate the audit-log), and by the Registrar (to recognize ent="RFC7469"/> is used.
itself in the audit log). This value needs to be calculated by both the MASA (to
populate the audit-log) and the registrar (to recognize itself in th
e audit-log).
</t> </t>
<t> <t indent="0" pn="section-5.8.2-3">
<xref target="RFC5280" format="default"/> section 4.2.1.2 does not m <xref target="RFC5280" sectionFormat="comma" section="4.2.1.2" forma
andate that the t="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.2" der
ivedContent="RFC5280"/> does 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 indent="0" pn="section-5.8.2-4">
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="include" rem
<name>Registrar audit log verification</name> oveInRFC="false" pn="section-5.8.3">
<t> <name slugifiedName="name-registrar-audit-log-verific">Registrar Audit
Each time the Manufacturer Authorized Signing Authority (MASA) -Log Verification</name>
<t indent="0" pn="section-5.8.3-1">
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" requests for details as described in <xref target="authzLogRequest"
format="default"/>. format="default" sectionFormat="of" derivedContent="Section 5.8"/>.
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 indent="0" pn="section-5.8.3-2">
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 indent="0" pn="section-5.8.3-3">A registrar <bcp14>SHOULD</bcp14> u se the log information to make an 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" indent="3" pn="section-5.8.3-4">
<dt>date:</dt> <dt pn="section-5.8.3-4.1">date:</dt>
<dd>The date field provides the registrar an <dd pn="section-5.8.3-4.2">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 pn="section-5.8.3-4.3">domainID:</dt>
<dd> If the log includes an unexpected domainID <dd pn="section-5.8.3-4.4"> If the log includes an unexpected domain
ID,
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 pn="section-5.8.3-4.5">nonce:</dt>
<dd>Nonceless entries mean the logged domainID could <dd pn="section-5.8.3-4.6">Nonceless entries mean the logged domainI
D 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 pn="section-5.8.3-4.7">assertion:</dt>
<dd>The assertion leaf in the voucher and <dd pn="section-5.8.3-4.8">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 indent="0" pn="section-5.8.3-5">
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
Endpoint Assessment (NEA) <xref target="RFC5209" format="default"/> configured if hardware-assisted (i.e., Transport Performance Metrics
is supported. (TPM) anchored) Network
Endpoint Assessment (NEA) <xref target="RFC5209" format="default" se
ctionFormat="of" derivedContent="RFC5209"/> is supported.
</t> </t>
</section> </section>
</section> </section>
<section anchor="ESTintegration" numbered="true" toc="default"> <section anchor="ESTintegration" numbered="true" toc="include" removeInRFC
<name>EST Integration for PKI bootstrapping</name> ="false" pn="section-5.9">
<t>The pledge SHOULD follow the BRSKI operations with EST enrollment ope <name slugifiedName="name-est-integration-for-pki-boo">EST Integration f
rations or PKI Bootstrapping</name>
including "CA Certificates Request", "CSR Attributes" and "Client Certif <t indent="0" pn="section-5.9-1">The pledge <bcp14>SHOULD</bcp14> follow
icate Request" the BRSKI operations with EST enrollment operations
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" sectionFormat="of" derivedContent="RFC7030"/>. 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 indent="0" pn="section-5.9-2">
-->
<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" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-4.5" derivedConte
nt="RFC7030"/>).
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="include" removeInRFC="false" pn="section-5
<name>EST Distribution of CA Certificates</name> .9.1">
<t>The pledge SHOULD request the full EST Distribution of CA <name slugifiedName="name-est-distribution-of-ca-cert">EST Distributio
Certificates message. See RFC7030, section 4.1.</t> n of CA Certificates</name>
<t>This ensures that the pledge has the complete set of current CA <t indent="0" pn="section-5.9.1-1">The pledge <bcp14>SHOULD</bcp14> re
certificates beyond the pinned-domain-cert (see <xref target="PledgeAu quest the full EST Distribution of CA
thenticationOfProvisionalTLS" format="default"/> for a discussion of the certificate messages; see <xref target="RFC7030" sectionFormat="comma"
section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#
section-4.1" derivedContent="RFC7030"/>.</t>
<t indent="0" pn="section-5.9.1-2">This ensures that the pledge has th
e complete set of current CA
certificates beyond the pinned-domain-cert (see <xref target="PledgeAu
thenticationOfProvisionalTLS" format="default" sectionFormat="of" derivedContent
="Section 5.6.2"/> 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="include" removeInRF
<name>EST CSR Attributes</name> C="false" pn="section-5.9.2">
<t>Automated bootstrapping occurs without local administrative <name slugifiedName="name-est-csr-attributes">EST CSR Attributes</name
configuration of the pledge. In some deployments it is plausible that >
<t indent="0" pn="section-5.9.2-1">Automated bootstrapping occurs with
out local administrative
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 indent="0" pn="section-5.9.2-2">To alleviate these operational diff iculties, 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 indent="0" pn="section-5.9.2-3">
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" format=
<xref target="I-D.ietf-anima-autonomic-control-plane" format="defaul "default" derivedLink="https://rfc-editor.org/rfc/rfc8994#section-6.2.2" derived
t"/> section 6.1.1. Content="RFC8994"/>.
</t> </t>
<t>The registrar MUST also confirm that the resulting CSR is formatted as <t indent="0" pn="section-5.9.2-4">The registrar <bcp14>MUST</bcp14> a lso confirm that the resulting CSR 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="include" removeInRFC="false" pn="section-5
<name>EST Client Certificate Request</name> .9.3">
<t>The pledge MUST request a new client certificate. See RFC7030, <name slugifiedName="name-est-client-certificate-requ">EST Client Cert
section 4.2.</t> ificate Request</name>
<t indent="0" pn="section-5.9.3-1">The pledge <bcp14>MUST</bcp14> requ
est a new Client
Certificate; see <xref target="RFC7030" sectionFormat="comma" section="4.2" form
at="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-4.2" derive
dContent="RFC7030"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-5
<name>Enrollment Status Telemetry</name> .9.4">
<t> <name slugifiedName="name-enrollment-status-telemetry">Enrollment Stat
us Telemetry</name>
<t indent="0" pn="section-5.9.4-1">
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" sectionFormat="of" derivedContent="RFC7030"/>, a final success indication b
not include a final success indication back to the server. This is ack to the server is not included. This is
insufficient for automated use cases. insufficient for automated use cases.
</t> </t>
<t> <t indent="0" pn="section-5.9.4-2">
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 indent="0" pn="section-5.9.4-3">
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 indent="0" pn="section-5.9.4-4">
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 indent="0" pn="section-5.9.4-5">
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 indent="0" pn="section-5.9.4-6">
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> <figure anchor="cddl-enrollstatus" align="left" suppress-title="false"
In the case of a SUCCESS the Reason string is omitted. pn="figure-19">
</t> <name slugifiedName="name-cddl-for-enrollment-status-">CDDL for Enro
<figure anchor="cddl-enrollstatus"> llment Status POST</name>
<name>CDDL for enrollment status POST</name> <sourcecode name="enrollstatus.cddl" type="CDDL" markers="true" pn="
<sourcecode name="enrollstatus.cddl" type="" markers="true"><![CDATA section-5.9.4-7.1">
[
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 indent="0" pn="section-5.9.4-8">
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" align="left" suppress-title="fal
<name>Example of se" pn="figure-20">
enrollment status POST</name> <name slugifiedName="name-example-of-enrollment-statu">Example of En
<artwork name="" type="" align="left" alt=""><![CDATA[ rollment Status POST</name>
<sourcecode type="json" markers="false" pn="section-5.9.4-9.1">
{ {
"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 indent="0" pn="section-5.9.4-10">The server <bcp14>SHOULD</bcp14> r espond with an HTTP 200 but <bcp14>MAY</bcp14> simply fail
with an HTTP 404 error.</t> with an HTTP 404 error.</t>
<t> <t indent="0" pn="section-5.9.4-11">
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="include" removeInRFC="false" pn="section-5
<name>Multiple certificates</name> .9.5">
<t> <name slugifiedName="name-multiple-certificates">Multiple Certificates
</name>
<t indent="0" pn="section-5.9.5-1">
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="include" removeInRFC="false" pn="section-5
<name>EST over CoAP</name> .9.6">
<t>This document describes extensions to EST for the purposes <name slugifiedName="name-est-over-coap">EST over CoAP</name>
of bootstrapping of remote key infrastructures. <t indent="0" pn="section-5.9.6-1">This document describes extensions
to EST for the purpose
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" sectionForma t="of" derivedContent="ACE-COAP-EST"/> 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="include" removeInRFC="false
<name>Clarification of transfer-encoding</name> " pn="section-6">
<t> <name slugifiedName="name-clarification-of-transfer-e">Clarification of Tr
<xref target="RFC7030" format="default"/> defines its endpoints to inclu ansfer-Encoding</name>
de a <t indent="0" pn="section-6-1">
"Content-Transfer-Encoding" heading, and the payloads to be <xref target="RFC7030" format="default" sectionFormat="of" derivedConten
<xref target="RFC4648" format="default"/> Base64 encoded DER. t="RFC7030"/> defines endpoints to include a
"Content-Transfer-Encoding" heading and payloads to be
base64-encoded DER <xref target="RFC4648" format="default" sectionForma
t="of" derivedContent="RFC4648"/>.
</t> </t>
<t> <t indent="0" pn="section-6-2">
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" format="default" sectionFormat="of
ry " derivedContent="RFC7030"/> (as clarified by <xref target="RFC8951" format="def
artifacts (specifically, "/.well-known/est/requestvoucher") are ault" sectionFormat="of" derivedContent="RFC8951"/>), but the new BRSKI endpoint
s that send and receive binary
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 indent="0" pn="section-6-3">
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="include" removeI
<name>Reduced security operational modes</name> nRFC="false" pn="section-7">
<t> <name slugifiedName="name-reduced-security-operationa">Reduced Security Op
erational Modes</name>
<t indent="0" pn="section-7-1">
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 alternative deployment architectures and mitigate life-cycle management
ssues issues
identified in <xref target="privacyconsiderations" format="default"/>. identified in <xref target="privacyconsiderations" format="default" sect
They are presented here as informative ionFormat="of" derivedContent="Section 10"/>. They are presented here as inform
ative
(non-normative) design guidance for future standardization (non-normative) design guidance for future standardization
activities. activities.
<xref target="acpapplicability" format="default"/> provides standardizat <xref target="acpapplicability" format="default" sectionFormat="of" deri
ion applicability statements vedContent="Section 9"/> provides standardization 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" sectionFormat="of" deri vedContent="Section 9"/>.
</t> </t>
<t> <t indent="0" pn="section-7-2">
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
specific profiles of BRSKI, such as in <xref target="acpapplicability" f etailed in
ormat="default"/>. specific profiles of BRSKI, such as in <xref target="acpapplicability" f
ormat="default" sectionFormat="of" derivedContent="Section 9"/>.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1
<name>Trust Model</name> ">
<t> <name slugifiedName="name-trust-model">Trust Model</name>
This section explains the trust relationships detailed in <xref target=" <t indent="0" pn="section-7.1-1">
flow" format="default"/>: This section explains the trust relationships detailed in <xref target="
flow" format="default" sectionFormat="of" derivedContent="Section 2.4"/>:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <figure align="left" suppress-title="false" pn="figure-21">
<name slugifiedName="name-elements-of-brski-trust-mod">Elements of BRS
KI Trust Model</name>
<artwork name="" type="" align="left" alt="" pn="section-7.1-2.1">
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| 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" indent="3" pn="section-7.1-3">
<dt>Pledge:</dt> <dt pn="section-7.1-3.1">Pledge:</dt>
<dd>The pledge could be compromised and <dd pn="section-7.1-3.2">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
<dt>Join Proxy:</dt> out of scope of this document.</dd>
<dd>Provides proxy functionalities but is not <dt pn="section-7.1-3.3">Join Proxy:</dt>
<dd pn="section-7.1-3.4">Provides proxy functionalities but is not
involved in security considerations.</dd> involved in security considerations.</dd>
<dt>Registrar:</dt> <dt pn="section-7.1-3.5">Registrar:</dt>
<dd>When interacting with a MASA a <dd pn="section-7.1-3.6">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" sectionFormat="of" derivedContent="RFC8366"
to />), the registrar is provided an opportunity to
accept MASA decisions.</dd> accept MASA decisions.</dd>
<dt>Vendor Service, MASA:</dt> <dt pn="section-7.1-3.7">Vendor Service, MASA:</dt>
<dd>This form of manufacturer service is <dd pn="section-7.1-3.8">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 pn="section-7.1-3.9">Vendor Service, Ownership Validation:</dt>
<dd>This form of <dd pn="section-7.1-3.10">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="include" removeInR
<name>Pledge security reductions</name> FC="false" pn="section-7.2">
<t> <name slugifiedName="name-pledge-security-reductions">Pledge Security Re
The following is a list of alternative behaviours that the ductions</name>
pledge can be programmed to implement. These behaviours are not <t indent="0" pn="section-7.2-1">
The following is a list of alternative behaviors that the
pledge can be programmed to implement. These behaviors are not
mutually exclusive, nor are they dependent upon each other. 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" indent="adaptive" start="1" pn="section-7.
<li> 2-2">
The pledge MUST accept nonceless vouchers. This allows for <li pn="section-7.2-2.1" derivedCounter="1.">
a use case where the registrar can not connect to the MASA The pledge <bcp14>MUST</bcp14> accept nonceless vouchers. This a
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 pn="section-7.2-2.2" derivedCounter="2.">
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 pn="section-7.2-2.3" derivedCounter="3.">
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 pn="section-7.2-2.4" derivedCounter="4.">
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 indent="0" pn="section-7.2-3">It is <bcp14>RECOMMENDED</bcp14> that "
voucher trust on first use" or any method 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" sectionFormat="
of" derivedContent="RFC5209"/>
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="include" removeInRFC="false" pn="section-7.3
<name>Registrar security reductions</name> ">
<t> <name slugifiedName="name-registrar-security-reductio">Registrar Securit
y Reductions</name>
<t indent="0" pn="section-7.3-1">
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" indent="adaptive" start="1" pn="section-7.
<li>A registrar MAY choose to accept all devices, or all devices of 3-2">
a particular type, at the administrator's discretion. This could
occur when informing all registrars of unique identifiers of new <li pn="section-7.3-2.1" derivedCounter="1.">A registrar <bcp14>MAY</b
entities might be operationally difficult.</li> cp14> choose to accept all devices, or all devices of
<li>A registrar MAY choose to accept devices that claim a unique a particular type. The administrator could make this choice in cases w
here it
is operationally difficult to configure the registrar with the unique
identifier of each new device expected.</li>
<li pn="section-7.3-2.2" derivedCounter="2.">A registrar <bcp14>MAY</b
cp14> 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" sectionFormat="of" deriv
<xref target="RequestVoucherFromMASA" format="default"/> format to e edContent="Section 5.2"/> using the
nsure the format per <xref target="RequestVoucherFromMASA" format="default" se
ctionFormat="of" derivedContent="Section 5.5"/> 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" sectionFor
mat="comma" section="3.3.2" format="default" derivedLink="https://rfc-editor.org
/rfc/rfc7030#section-3.3.2" derivedContent="RFC7030"/>. 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 pn="section-7.3-2.3" derivedCounter="3.">A registrar <bcp14>MAY</b
service (by not including a nonce in the voucher-request.) The resul cp14> submit a nonceless voucher-request 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 pn="section-7.3-2.4" derivedCounter="4.">
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 pn="section-7.3-2.5" derivedCounter="5.">A registrar <bcp14>MAY</b
can not be parsed by the Registrar. This reduces the Registrar's cp14> accept voucher formats of future types that
cannot be parsed by the registrar. This reduces the registrar's
visibility into the exact voucher contents but does not change 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="include" rem
<name>MASA security reductions</name> oveInRFC="false" pn="section-7.4">
<t> <name slugifiedName="name-masa-security-reductions">MASA Security Reduct
ions</name>
<t indent="0" pn="section-7.4-1">
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 <section anchor="masasecurityreduction_nonce" numbered="true" toc="inclu
lt"> de" removeInRFC="false" pn="section-7.4.1">
<name>Issuing Nonceless vouchers</name> <name slugifiedName="name-issuing-nonceless-vouchers">Issuing Nonceles
<t> s Vouchers</name>
A MASA has the option of not including a nonce in the voucher, <t indent="0" pn="section-7.4.1-1">
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 indent="0" pn="section-7.4.1-2">
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 indent="0" pn="section-7.4.1-3">
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 indent="0" pn="section-7.4.1-4">
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 indent="0" pn="section-7.4.1-5">
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 <section anchor="masasecurityreduction_tofu" numbered="true" toc="includ
t"> e" removeInRFC="false" pn="section-7.4.2">
<name>Trusting Owners on First Use</name> <name slugifiedName="name-trusting-owners-on-first-us">Trusting Owners
<t> on First Use</name>
<t indent="0" pn="section-7.4.2-1">
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 indent="0" pn="section-7.4.2-2">
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 <section anchor="masasecurityreduction_newanchor" numbered="true" toc="i
efault"> nclude" removeInRFC="false" pn="section-7.4.3">
<name>Updating or extending voucher trust anchors</name> <name slugifiedName="name-updating-or-extending-vouch">Updating or Ext
<t> ending Voucher Trust Anchors</name>
This section deals with the problem of a MASA that is no longer <t indent="0" pn="section-7.4.3-1">
available due to a failed business, or the situation where a This section deals with two problems: A MASA that is no longer avail
MASA is uncooperative to a secondary sale. able due to
a failed business and a MASA that is uncooperative to a secondary sal
e.
</t> </t>
<t> <t indent="0" pn="section-7.4.3-2">
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" sectionFor mat="of" derivedContent="YANG-KEYSTORE"/> describes 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 indent="0" pn="section-7.4.3-3">
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= use a mechanism described in <xref target="pledgeReductions" format=
"default"/> "default" sectionFormat="of" derivedContent="Section 7.2"/>
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 indent="0" pn="section-7.4.3-4">
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 indent="0" pn="section-7.4.3-5">
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 indent="0" pn="section-7.4.3-6">
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="include" removeInRFC="false" pn="section-8">
<name>IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document requires the following IANA actions:</t> <t indent="0" pn="section-8-1">Per this document, IANA has completed the f
<section numbered="true" toc="default"> ollowing actions.</t>
<name>The IETF XML Registry</name> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.1
<t> ">
<name slugifiedName="name-the-ietf-xml-registry">The IETF XML Registry</
name>
<t indent="0" pn="section-8.1-1">
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" sectionFormat="of" d
IANA is asked to register the following:</t> erivedContent="RFC3688"/>.
<artwork name="" type="" align="left" alt=""><![CDATA[ IANA has registered the following:</t>
URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request <dl spacing="compact" indent="3" newline="false" pn="section-8.1-2">
Registrant Contact: The ANIMA WG of the IETF. <dt pn="section-8.1-2.1">URI:</dt>
XML: N/A, the requested URI is an XML namespace. <dd pn="section-8.1-2.2">urn:ietf:params:xml:ns:yang:ietf-voucher-requ
]]></artwork> est</dd>
<dt pn="section-8.1-2.3">Registrant Contact:</dt>
<dd pn="section-8.1-2.4">The ANIMA WG of the IETF.</dd>
<dt pn="section-8.1-2.5">XML:</dt>
<dd pn="section-8.1-2.6">N/A; the requested URI is an XML namespace.</
dd>
</dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.2
<name>YANG Module Names Registry</name> ">
<t> <name slugifiedName="name-yang-module-names-registry">YANG Module Names
Registry</name>
<t indent="0" pn="section-8.2-1">
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" s
. ectionFormat="of" derivedContent="RFC6020"/>.
IANA is asked to register the following:</t> IANA has registered the following:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dl spacing="compact" indent="3" newline="false" pn="section-8.2-2">
name: ietf-voucher-request <dt pn="section-8.2-2.1">Name:</dt>
namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request <dd pn="section-8.2-2.2">ietf-voucher-request</dd>
prefix: vch <dt pn="section-8.2-2.3">Namespace:</dt>
reference: THIS DOCUMENT <dd pn="section-8.2-2.4">urn:ietf:params:xml:ns:yang:ietf-voucher-requ
]]></artwork> est</dd>
<dt pn="section-8.2-2.5">Prefix:</dt>
<dd pn="section-8.2-2.6">vch</dd>
<dt pn="section-8.2-2.7">Reference:</dt>
<dd pn="section-8.2-2.8">RFC 8995</dd>
</dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.3
<name>Well-known EST registration</name> ">
<t> <name slugifiedName="name-brski-well-known-considerat">BRSKI Well-Known
This document extends the definitions of "est" (so far defined via Considerations</name>
RFC7030) in the <section numbered="true" toc="include" removeInRFC="false" pn="section-8
"https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtm .3.1">
l" <name slugifiedName="name-brski-well-known-registrati">BRSKI .well-kno
registry. IANA is asked to change the registration of "est" to wn Registration</name>
include RFC7030 and this document. <t indent="0" pn="section-8.3.1-1">
</t> To the "Well-Known URIs" registry at
<eref target="https://www.iana.org/assignments/well-known-uris/" bra
ckets="none"/>,
this document registers the well-known name "brski" with the
following filled-in template from <xref target="RFC8615" format="def
ault" sectionFormat="of" derivedContent="RFC8615"/>:
</t>
<dl newline="false" spacing="compact" indent="3" pn="section-8.3.1-2">
<dt pn="section-8.3.1-2.1">URI Suffix:</dt>
<dd pn="section-8.3.1-2.2">brski</dd>
<dt pn="section-8.3.1-2.3">Change Controller:</dt>
<dd pn="section-8.3.1-2.4">IETF</dd>
</dl>
<t indent="0" pn="section-8.3.1-3">
IANA has changed the registration of "est" to now only
include <xref target="RFC7030" format="default" sectionFormat="of" d
erivedContent="RFC7030"/> 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="include" removeInRFC="false" pn="section-8
.3.2">
<name slugifiedName="name-brski-well-known-registry">BRSKI .well-known
Registry</name>
<t indent="0" pn="section-8.3.2-1">
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" sectionFormat="of" derivedContent="RFC8126"/> proces
s.
The initial contents of this registry are:
</t>
<table anchor="table_IANA" align="center" pn="table-1">
<name slugifiedName="name-brski-well-known-uris">BRSKI Well-Known UR
Is</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">URI</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">requestvoucher</td>
<td align="left" colspan="1" rowspan="1">pledge to registrar, an
d from registrar to MASA</td>
<td align="left" colspan="1" rowspan="1">RFC 8995</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">voucher_status</td>
<td align="left" colspan="1" rowspan="1">pledge to registrar</td
>
<td align="left" colspan="1" rowspan="1">RFC 8995</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">requestauditlog</td>
<td align="left" colspan="1" rowspan="1">registrar to MASA</td>
<td align="left" colspan="1" rowspan="1">RFC 8995</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">enrollstatus</td>
<td align="left" colspan="1" rowspan="1">pledge to registrar</td
>
<td align="left" colspan="1" rowspan="1">RFC 8995</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.4
<name>PKIX Registry</name> ">
<t>IANA is requested to register the following:</t> <name slugifiedName="name-pkix-registry">PKIX Registry</name>
<t> <t indent="0" pn="section-8.4-1">IANA has registered the following:</t>
This document requests a number for id-mod-MASAURLExtn2016(TBD) <t indent="0" pn="section-8.4-2">
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 indent="0" pn="section-8.4-3">
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 <section anchor="pledgestatustelemetryregistry" numbered="true" toc="inclu
lt"> de" removeInRFC="false" pn="section-8.5">
<name>Pledge BRSKI Status Telemetry</name> <name slugifiedName="name-pledge-brski-status-telemetr">Pledge BRSKI Sta
<t> tus Telemetry</name>
IANA is requested to create a new Registry entitled: "BRSKI <t indent="0" pn="section-8.5-1">
Parameters", and within that Registry to create a table called: IANA has created a new registry entitled "BRSKI
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" sectionFormat="of" derivedContent="Section 5.7"/>) as the r
eference:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
<li>version</li> .5-2">
<li>Status</li> <li pn="section-8.5-2.1">version</li>
<li>Reason</li> <li pn="section-8.5-2.2">Status</li>
<li>reason-context</li> <li pn="section-8.5-2.3">Reason</li>
<li pn="section-8.5-2.4">reason-context</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.6
<name>DNS Service Names</name> ">
<t>IANA is requested to register the following Service Names:</t> <name slugifiedName="name-dns-service-names">DNS Service Names</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <t indent="0" pn="section-8.6-1">IANA has registered the following servi
Service Name: brski-proxy ce names:</t>
Transport Protocol(s): tcp <dl spacing="compact" indent="3" newline="false" pn="section-8.6-2">
Assignee: IESG <iesg@ietf.org>. <dt pn="section-8.6-2.1">Service Name:</dt>
Contact: IESG <iesg@ietf.org> <dd pn="section-8.6-2.2">brski-proxy</dd>
Description: The Bootstrapping Remote Secure Key <dt pn="section-8.6-2.3">Transport Protocol(s):</dt>
Infrastructures Proxy <dd pn="section-8.6-2.4">tcp</dd>
Reference: [This document] <dt pn="section-8.6-2.5">Assignee:</dt>
<dd pn="section-8.6-2.6">IESG &lt;iesg@ietf.org&gt;</dd>
Service Name: brski-registrar <dt pn="section-8.6-2.7">Contact:</dt>
Transport Protocol(s): tcp <dd pn="section-8.6-2.8">IESG &lt;iesg@ietf.org&gt;</dd>
Assignee: IESG <iesg@ietf.org>. <dt pn="section-8.6-2.9">Description:</dt>
Contact: IESG <iesg@ietf.org> <dd pn="section-8.6-2.10">The Bootstrapping Remote Secure Key Infrastr
Description: The Bootstrapping Remote Secure Key ucture
Infrastructures Registrar Proxy</dd>
Reference: [This document] <dt pn="section-8.6-2.11">Reference:</dt>
]]></artwork> <dd pn="section-8.6-2.12">RFC 8995</dd>
</dl>
<dl spacing="compact" indent="3" newline="false" pn="section-8.6-3">
<dt pn="section-8.6-3.1">Service Name:</dt>
<dd pn="section-8.6-3.2">brski-registrar</dd>
<dt pn="section-8.6-3.3">Transport Protocol(s):</dt>
<dd pn="section-8.6-3.4">tcp</dd>
<dt pn="section-8.6-3.5">Assignee:</dt>
<dd pn="section-8.6-3.6">IESG &lt;iesg@ietf.org&gt;</dd>
<dt pn="section-8.6-3.7">Contact:</dt>
<dd pn="section-8.6-3.8">IESG &lt;iesg@ietf.org&gt;</dd>
<dt pn="section-8.6-3.9">Description:</dt>
<dd pn="section-8.6-3.10">The Bootstrapping Remote Secure Key Infrastr
ucture
Registrar</dd>
<dt pn="section-8.6-3.11">Reference:</dt>
<dd pn="section-8.6-3.12">RFC 8995</dd>
</dl>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8.7
">
<name slugifiedName="name-grasp-objective-names">GRASP Objective Names</
name>
<t indent="0" pn="section-8.7-1">IANA has registered the following GRASP
Objective
Names:</t>
<t indent="0" pn="section-8.7-2">
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" sectionFormat="of" derivedContent="Section 4.1.1"/> of this document.
</t>
<t indent="0" pn="section-8.7-3">
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" sectionFormat="of" derivedContent="Section 4.3"/> of this document.
</t>
</section> </section>
</section> </section>
<section anchor="acpapplicability" numbered="true" toc="default"> <section anchor="acpapplicability" numbered="true" toc="include" removeInRFC
<name>Applicability to the Autonomic Control Plane (ACP)</name> ="false" pn="section-9">
<t> <name slugifiedName="name-applicability-to-the-autono">Applicability to th
e Autonomic Control Plane (ACP)</name>
<t indent="0" pn="section-9-1">
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" format="title" secti
tonomic Control Plane for onFormat="of" derivedContent="Using an Autonomic Control Plane for Stable Connec
Stable Connectivity of Network Operations, Administration, and tivity of Network Operations, Administration, and Maintenance (OAM)"/>" <xref ta
Maintenance </xref>, rget="RFC8368" format="default" sectionFormat="of" derivedContent="RFC8368"/>,
<xref target="I-D.ietf-anima-reference-model" format="default">A Referen "A Reference Model for Autonomic Networking" <xref target="RFC8993" forma
ce Model for t="default" sectionFormat="of" derivedContent="RFC8993"/>, and specifically
Autonomic Networking</xref> and specifically the "An Autonomic Control Plane (ACP)" <xref target="RFC8994" format="default
<xref target="I-D.ietf-anima-autonomic-control-plane" format="default">A " sectionFormat="of" derivedContent="RFC8994"/>; see Sections <xref target="RFC8
n Autonomic 994" sectionFormat="bare" section="3.2" format="default" derivedLink="https://rf
Control Plane (ACP)</xref>, section 3.2 (Secure Bootstrap), and c-editor.org/rfc/rfc8994#section-3.2" derivedContent="RFC8994"/> ("Secure Bootst
section 6.1 (ACP Domain, Certificate and Network). rap over an Unconfigured Network") and
<xref target="RFC8994" sectionFormat="bare" section="6.2" format="defaul
t" derivedLink="https://rfc-editor.org/rfc/rfc8994#section-6.2" derivedContent="
RFC8994"/> ("ACP Domain, Certificate, and Network").
</t> </t>
<t> <t indent="0" pn="section-9-2">
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 indent="0" pn="section-9-3">
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 indent="0" pn="section-9-4">
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 indent="0" pn="section-9-5">
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 indent="0" pn="section-9-6">
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" sectionFormat="of" derivedContent="RFC8994"/>
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 indent="0" pn="section-9-7">
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" sectionFormat="of" deri
T provide at vedContent="Section 7.2"/>. The manufacturer <bcp14>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 indent="0" pn="section-9-8">
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="include" re
<name>Operational Requirements</name> moveInRFC="false" pn="section-9.1">
<t> <name slugifiedName="name-operational-requirements">Operational Requirem
ents</name>
<t indent="0" pn="section-9.1-1">
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 indent="0" pn="section-9.1-2">
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" sectionFormat="of" derivedCont
mat="default"/>) ent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" deriv
language. These do not represent new normative statements, just a edContent="RFC8174"/>.
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="include" removeI
<name>MASA Operational Requirements</name> nRFC="false" pn="section-9.1.1">
<t> <name slugifiedName="name-masa-operational-requiremen">MASA Operationa
The manufacturer MUST arrange for an online service to be available l Requirements</name>
called the MASA. It MUST be available at the URL which is encoded <t indent="0" pn="section-9.1.1-1">
in the IDevID certificate extensions described in <xref target="MASA The manufacturer <bcp14>MUST</bcp14> arrange for an online service c
URL" format="default"/>. 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" sectionFormat="of" derivedContent="Section 2.3.2"/>.
</t> </t>
<t> <t indent="0" pn="section-9.1.1-2">
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" secti
key, certificate, or certificate chain MUST be built in to the onFormat="of" derivedContent="RFC8366"/>. The 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 indent="0" pn="section-9.1.1-3">
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" sectionFormat="of" derivedContent="softwareescrow"/>.
</t> </t>
<t> <t indent="0" pn="section-9.1.1-4">
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 indent="0" pn="section-9.1.1-5">
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="include"
<name>Domain Owner Operational Requirements</name> removeInRFC="false" pn="section-9.1.2">
<t> <name slugifiedName="name-domain-owner-operational-re">Domain Owner Op
The domain owner MUST operate an EST (<xref target="RFC7030" format= erational Requirements</name>
"default"/>) <t indent="0" pn="section-9.1.2-1">
The domain owner <bcp14>MUST</bcp14> operate an EST <xref target="RF
C7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>
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 indent="0" pn="section-9.1.2-2">
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 indent="0" pn="section-9.1.2-3">
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 indent="0" pn="section-9.1.2-4">
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 indent="0" pn="section-9.1.2-5">
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 indent="0" pn="section-9.1.2-6">
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="include" remov
<name>Device Operational Requirements</name> eInRFC="false" pn="section-9.1.3">
<t> <name slugifiedName="name-device-operational-requirem">Device Operatio
Devices MUST come with built-in trust anchors that permit the device nal Requirements</name>
to <t indent="0" pn="section-9.1.3-1">
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 indent="0" pn="section-9.1.3-2">
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 indent="0" pn="section-9.1.3-3">
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 indent="0" pn="section-9.1.3-4">
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" sectionFormat=
format="default"/>. "of" derivedContent="RFC8994"/>.
</t> </t>
<t> <t indent="0" pn="section-9.1.3-5">
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 indent="0" pn="section-9.1.3-6">
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="include" remove
<name>Privacy Considerations</name> InRFC="false" pn="section-10">
<section numbered="true" toc="default"> <name slugifiedName="name-privacy-considerations">Privacy Considerations</
<name>MASA audit log</name> name>
<t> <section numbered="true" toc="include" removeInRFC="false" pn="section-10.
The MASA audit log includes the domainID for each 1">
<name slugifiedName="name-masa-audit-log">MASA Audit-Log</name>
<t indent="0" pn="section-10.1-1">
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" sectionFormat="of" derivedContent="Section 11.1"/>),
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 indent="0" pn="section-10.1-2">
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 indent="0" pn="section-10.1-3">
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="include" removeInRF
<name>What BRSKI-EST reveals</name> C="false" pn="section-10.2">
<t> <name slugifiedName="name-what-brski-est-reveals">What BRSKI-EST Reveals
</name>
<t indent="0" pn="section-10.2-1">
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 indent="0" pn="section-10.2-2">
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 indent="0" pn="section-10.2-3">
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 indent="0" pn="section-10.2-4">
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" sectionFormat="o
validations are expected to be done, the contents could be easily f" derivedContent="RFC6125"/> are expected to be done, the contents could be eas
pseudonymized. Any device that can see a join proxy would be ily
able to connect to the Registrar and learn the identity of the pseudonymized. Any device that can see a Join Proxy would be
able to connect to the registrar and learn the identity of the
network in question. Even if the contents of the certificate 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 indent="0" pn="section-10.2-5">
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 indent="0" pn="section-10.2-6">
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="include" removeInRFC=
<name>What BRSKI-MASA reveals to the manufacturer</name> "false" pn="section-10.3">
<t> <name slugifiedName="name-what-brski-masa-reveals-to-">What BRSKI-MASA R
eveals to the Manufacturer</name>
<t indent="0" pn="section-10.3-1">
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" sectionFormat="of" der
TstrangeThings" format="default"/> for exemplars. The Autonomic Control ivedContent="livingwithIoT"/> and <xref target="IoTstrangeThings" format="defaul
Plane (ACP) usage of BRSKI is not targeted at individual usage of t" sectionFormat="of" derivedContent="IoTstrangeThings"/> for exemplars. The AC
IoT devices, but rather at the Enterprise and ISP creation of P usage of BRSKI is not targeted at individual usage of
IoT devices but rather at the enterprise and ISP creation of
networks in a zero-touch fashion where the "call-home" represents 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 indent="0" pn="section-10.3-2">
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 indent="0" pn="section-10.3-3">
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 indent="0" pn="section-10.3-4">
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 indent="0" pn="section-10.3-5">
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" bare="false" empty="false" indent="3" pn="section-1
<li> 0.3-6">
<li pn="section-10.3-6.1">
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 pn="section-10.3-6.2">
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 method, as per <xref target="MASAauthenticationOfRegistrar" form
at="default"/>. at="default" sectionFormat="of" derivedContent="Section 5.5.4"/>.
</li> </li>
<li> <li pn="section-10.3-6.3">
the time the device is activated, the time the device is activated.
</li> </li>
<li> <li pn="section-10.3-6.4">
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" sectionFormat ="of" derivedContent="RFC8981"/> can do anything 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 indent="0" pn="section-10.3-7">
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 indent="0" pn="section-10.3-8">
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 indent="0" pn="section-10.3-9">
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 indent="0" pn="section-10.3-10">
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" sectionFormat="of" derivedContent="Dingledine"/>, as a TLS 1.2 connect
1.2 connection ion
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 indent="0" pn="section-10.3-11">
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="include" removeInRFC="false" pn="section-10.
<name>Manufacturers and Used or Stolen Equipment</name> 4">
<t> <name slugifiedName="name-manufacturers-and-used-or-s">Manufacturers and
Used or Stolen Equipment</name>
<t indent="0" pn="section-10.4-1">
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 indent="0" pn="section-10.4-2">
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" indent="adaptive" start="1" pn="section-10
<li> .4-3">
<li pn="section-10.4-3.1" derivedCounter="1.">
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 pn="section-10.4-3.2" derivedCounter="2.">
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 pn="section-10.4-3.3" derivedCounter="3.">
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 pn="section-10.4-3.4" derivedCounter="4.">
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 pn="section-10.4-3.5" derivedCounter="5.">
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 indent="0" pn="section-10.4-4">
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="include" removeInRFC="false" pn="section-10.
<name>Manufacturers and Grey market equipment</name> 5">
<t> <name slugifiedName="name-manufacturers-and-grey-mark">Manufacturers and
Grey Market Equipment</name>
<t indent="0" pn="section-10.5-1">
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 indent="0" pn="section-10.5-2">
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 indent="0" pn="section-10.5-3">
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 indent="0" pn="section-10.5-4">
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 indent="0" pn="section-10.5-5">
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="include" removeInRFC="false" pn="section-10.
<name>Some mitigations for meddling by manufacturers</name> 6">
<t> <name slugifiedName="name-some-mitigations-for-meddli">Some Mitigations
for Meddling by Manufacturers</name>
<t indent="0" pn="section-10.6-1">
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 indent="0" pn="section-10.6-2">
<xref target="masasecurityreduction_newanchor" format="default"/> <xref target="masasecurityreduction_newanchor" format="default" sect
ionFormat="of" derivedContent="Section 7.4.3"/>
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 indent="0" pn="section-10.6-3">
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 indent="0" pn="section-10.6-4">
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 indent="0" pn="section-10.6-5">
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 indent="0" pn="section-10.6-6">
As discussed at the end of <xref target="MASAauditlog" format="defau As discussed at the end of <xref target="MASAauditlog" format="defau
lt"/>, lt" sectionFormat="of" derivedContent="Section 5.8.1"/>,
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="include" removeInRFC="false" pn="section-10.
<name>Death of a manufacturer</name> 7">
<t> <name slugifiedName="name-death-of-a-manufacturer">Death of a Manufactur
er</name>
<t indent="0" pn="section-10.7-1">
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 indent="0" pn="section-10.7-2">
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 indent="0" pn="section-10.7-3">
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="include" remov
<name>Security Considerations</name> eInRFC="false" pn="section-11">
<t> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-11-1">
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" sectionFormat="of" derivedContent="Section 7"/>,
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 indent="0" pn="section-11-2">
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 <t indent="0" pn="section-11-3">To facilitate truly limited clients, EST
requirements that the client MUST support a client authentication model requires that the client <bcp14>MUST</bcp14> support a client authenticati
have been reduced in <xref target="reducedsecuritymodes" format="default"/ on model (see <xref target="RFC7030" sectionFormat="comma" section="3.3.2" forma
> to a t="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.3.2" deriv
statement that the registrar "MAY" choose to accept devices edContent="RFC7030"/>);
<xref target="reducedsecuritymodes" format="default" sectionFormat="of" de
rivedContent="Section 7"/> updates these requirements by stating that the regist
rar <bcp14>MAY</bcp14> choose to accept devices
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 <t indent="0" pn="section-11-4">During the provisional period of the conne
ll HTTP header and ction, 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 indent="0" pn="section-11-5">Pledges might chose to engage in protocol
multiple discovered registrars in parallel. As noted above they operations with
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="include" removeInRFC="false
<name>Denial of Service (DoS) against MASA</name> " pn="section-11.1">
<t>There are uses cases where the MASA could be unavailable or <name slugifiedName="name-denial-of-service-dos-again">Denial of Service
uncooperative to the Registrar. They include active DoS attacks, planned (DoS) against MASA</name>
and unplanned <t indent="0" pn="section-11.1-1">There are use cases where the MASA cou
ld be unavailable or
uncooperative to the registrar. They include active DoS attacks, planned
and unplanned
network partitions, changes to MASA policy, or other instances where 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 indent="0" pn="section-11.1-2">The issuance of nonceless vouchers the
concern. If the Registrar of a previous domain can intercept protocol mselves creates a security
communications then it can use a previously issued nonceless voucher to concern. If the registrar of a previous domain can intercept protocol
communications, then it can use a previously issued nonceless voucher to
establish management control of a pledge device even after having sold 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 indent="0" pn="section-11.1-3">The MASA is exposed to DoS attacks whe rein 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="include" removeInRFC="false" pn="section-11.
<name>DomainID must be resistant to second-preimage attacks</name> 2">
<t> <name slugifiedName="name-domainid-must-be-resistant-">DomainID Must Be
The domainID is used as the reference in the audit log to the Resistant to Second-Preimage Attacks</name>
<t indent="0" pn="section-11.2-1">
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="include" removeInRFC="false" pn="section-11.
<name>Availability of good random numbers</name> 3">
<t> <name slugifiedName="name-availability-of-good-random">Availability of G
The nonce used by the Pledge in the voucher-request SHOULD be ood Random Numbers</name>
generated by a Strong Cryptographic Sequence (<xref target="RFC4086" f <t indent="0" pn="section-11.3-1">
ormat="default"/> section 6.2). TLS has a similar requirement. The nonce used by the pledge in the voucher-request <bcp14>SHOULD</bcp
14> be
generated by a Strong Cryptographic Sequence (<xref target="RFC4086" s
ectionFormat="comma" section="6.2" format="default" derivedLink="https://rfc-edi
tor.org/rfc/rfc4086#section-6.2" derivedContent="RFC4086"/>). TLS has a similar
requirement.
</t> </t>
<t> <t indent="0" pn="section-11.3-2">
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" sectionFormat="of" derived
ection 3.4. Content="RFC4086"/>; see Sections <xref target="RFC4086" sectionFormat="bare" se
The random seed used by a device at boot MUST be ction="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4086#secti
on-3" derivedContent="RFC4086"/> and, in particular,
<xref target="RFC4086" sectionFormat="bare" section="3.4" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc4086#section-3.4" derivedContent="RFC4086
"/>.
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="include" removeInRFC="false" pn="section-11.
<name>Freshness in Voucher-Requests</name> 4">
<t> <name slugifiedName="name-freshness-in-voucher-reques">Freshness in Vouc
her-Requests</name>
<t indent="0" pn="section-11.4-1">
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>
<t> <t indent="0" pn="section-11.4-2">
There are a number of operational problems with getting a nonce There are a number of operational problems with getting a nonce
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 indent="0" pn="section-11.4-3">
Because the registrar authenticates the pledge, a full Man-in-the-Midd Because the registrar authenticates the pledge, a full MITM
le
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" sec
Instead we examine the case of a fake registrar (Rm) tionFormat="of" derivedContent="Section 5"/>.)
that communicates with the pledge in parallel or in close time proximi Instead, we examine the case of a fake registrar (Rm)
ty that communicates with the pledge in parallel or in close-time proximi
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" sectionFormat=" of" derivedContent="Section 4.1"/>.)
</t> </t>
<t> <t indent="0" pn="section-11.4-4">
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 indent="0" pn="section-11.4-5">
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 indent="0" pn="section-11.4-6">
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" sectionFormat="of" der
a voucher-request but wait until after the intended registrar complete ivedContent="Section 5.8"/>. The Rm might chose 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
<t> g random or pseudo-random number nonce.</t>
Additionally, in order to successfully use the resulting voucher the R <t indent="0" pn="section-11.4-7">
m Additionally, in order to successfully use the resulting voucher, the
would have to attack the pledge and return it to a bootstrapping Rm
enabled state. This would require wiping the pledge of current would have to attack the pledge and return it to a bootstrapping-enabl
configuration and triggering a re-bootstrapping of the pledge. ed
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" bare="false" empty="false" indent="3" pn="section-1
<li>Ongoing network monitoring for unexpected bootstrapping attempts b 1.4-8">
y pledges.</li> <li pn="section-11.4-8.1">Ongoing network monitoring for unexpected bo
<li>Retrieval and examination of MASA log information upon the occurre otstrapping attempts by pledges.</li>
nce <li pn="section-11.4-8.2">Retrieval and examination of MASA log inform
of any such unexpected events. Rm will be listed in the logs along ation upon the occurrence
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="include" removeInRFC="false" pn="section-11.
<name>Trusting manufacturers</name> 5">
<t> <name slugifiedName="name-trusting-manufacturers">Trusting Manufacturers
</name>
<t indent="0" pn="section-11.5-1">
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 indent="0" pn="section-11.5-2">
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 from <xref target="IDevIDextension" format="default" sectionFormat="of
pledge will have no problem " derivedContent="Section 2.3"/>, 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 indent="0" pn="section-11.5-3">
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" format="default" sectionFor
eds to mat="of" derivedContent="RFC7030"/> and BRSKI, the domain
trust the manufacturer. (registrar) still needs to trust the manufacturer.
</t> </t>
<t> <t indent="0" pn="section-11.5-4">
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" bare="false" empty="false" indent="3" pn="section-1
<li> 1.5-5">
<li pn="section-11.5-5.1">
Manually configuring each manufacturer's trust anchor. Manually configuring each manufacturer's trust anchor.
</li> </li>
<li> <li pn="section-11.5-5.2">
A Trust-On-First-Use (TOFU) mechanism. A human would be queried up A TOFU mechanism. A human would be queried upon
on
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 pn="section-11.5-5.3">
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 pn="section-11.5-5.4">
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 pn="section-11.5-5.5">
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" sectionFormat="of" derivedContent="docsisroot"/> and <xref target="TR069"
format="default" sectionFormat="of" derivedContent="TR069"/>.
</li> </li>
</ul> </ul>
<t> <t indent="0" pn="section-11.5-6">
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="include" removeInRFC="false" pn="section-11.
<name>Manufacturer Maintenance of trust anchors</name> 6">
<t> <name slugifiedName="name-manufacturer-maintenance-of">Manufacturer Main
tenance of Trust Anchors</name>
<t indent="0" pn="section-11.6-1">
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 indent="0" pn="section-11.6-2">
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 indent="0" pn="section-11.6-3">
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 indent="0" pn="section-11.6-4">
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 indent="0" pn="section-11.6-5">
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 indent="0" pn="section-11.6-6">
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 <xref target="cabforumaudit" format="default" sectionFormat="of" deriv
perations are well edContent="cabforumaudit"/>, and the DNSSEC root operations are well
documented at <xref target="dnssecroot" format="default"/>. documented in <xref target="dnssecroot" format="default" sectionFormat
="of" derivedContent="dnssecroot"/>.
</t> </t>
<t> <t indent="0" pn="section-11.6-7">
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 indent="0" pn="section-11.6-8">
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="include" removeInRFC="false" pn="section-1
<name>Compromise of Manufacturer IDevID signing keys</name> 1.6.1">
<t> <name slugifiedName="name-compromise-of-manufacturer-">Compromise of M
anufacturer IDevID Signing Keys</name>
<t indent="0" pn="section-11.6.1-1">
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 indent="0" pn="section-11.6.1-2">
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 indent="0" pn="section-11.6.1-3">
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 indent="0" pn="section-11.6.1-4">
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="include" removeInRFC="false" pn="section-1
<name>Compromise of MASA signing keys</name> 1.6.2">
<t> <name slugifiedName="name-compromise-of-masa-signing-">Compromise of M
ASA Signing Keys</name>
<t indent="0" pn="section-11.6.2-1">
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="exclude" removeInRFC="false" pn="section
<name>Attacker opportunties with compromised MASA key</name> -11.6.2.1">
<t> <name slugifiedName="name-attacker-opportunities-with">Attacker Oppo
rtunities with a Compromised MASA Key</name>
<t indent="0" pn="section-11.6.2.1-1">
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 indent="0" pn="section-11.6.2.1-2">
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 indent="0" pn="section-11.6.2.1-3">
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 indent="0" pn="section-11.6.2.1-4">
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 indent="0" pn="section-11.6.2.1-5">
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="exclude" removeInRFC="false" pn="section
<name>Risks after key compromise is known</name> -11.6.2.2">
<t> <name slugifiedName="name-risks-after-key-compromise-">Risks after K
ey Compromise is Known</name>
<t indent="0" pn="section-11.6.2.2-1">
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 indent="0" pn="section-11.6.2.2-2">
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 indent="0" pn="section-11.6.2.2-3">
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 indent="0" pn="section-11.6.2.2-4">
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 indent="0" pn="section-11.6.2.2-5">
<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" format="default" derivedLink="https:/
for short-lived vouchers. The nonce guarantees freshness, /rfc-editor.org/rfc/rfc8366#section-6.1" derivedContent="RFC8366"/>. 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 indent="0" pn="section-11.6.2.2-6">
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="include" removeInRFC="false" pn="section-1
<name>Compromise of MASA web service</name> 1.6.3">
<t> <name slugifiedName="name-compromise-of-masa-web-serv">Compromise of M
An attacker that takes over the MASA web service has a number of ASA Web Service</name>
<t indent="0" pn="section-11.6.3-1">
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 indent="0" pn="section-11.6.3-2">
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 indent="0" pn="section-11.6.3-3">
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 indent="0" pn="section-11.6.3-4">
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 indent="0" pn="section-11.6.3-5">
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="include" removeInRFC="false" pn="section-11.
<name>YANG Module Security Considerations</name> 7">
<t> <name slugifiedName="name-yang-module-security-consid">YANG Module Secur
As described in the Security Considerations section of <xref target="R ity Considerations</name>
FC8366" format="default"/> (section 7.4), the YANG module specified <t indent="0" pn="section-11.7-1">
As described in Section <xref target="RFC8366" section="7.4" sectionFo
rmat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8366#sec
tion-7.4" derivedContent="RFC8366"/> (Security Considerations) of <xref target="
RFC8366" format="default" sectionFormat="of" derivedContent="RFC8366"/>, the YAN
G 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" format="default"
As such, all of the YANG modeled data is protected from modification. derivedLink="https://rfc-editor.org/rfc/rfc5652#section-5" derivedContent="RFC5
652"/>.
As such, all of the YANG-modeled data is protected from modification.
</t> </t>
<t> <t indent="0" pn="section-11.7-2">
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" sectionFormat
F <xref target="RFC8040" format="default"/>. For this ="of" derivedContent="RFC6241"/> and RESTCONF <xref target="RFC8040" format="def
reason, these guidelines do not follow template described by ault" sectionFormat="of" derivedContent="RFC8040"/>. For this
Section 3.7 of <xref target="RFC8407" format="default"/>. reason, these guidelines do not follow the template described by
<xref target="RFC8407" sectionFormat="of" section="3.7" format="defau
lt" derivedLink="https://rfc-editor.org/rfc/rfc8407#section-3.7" derivedContent=
"RFC8407"/>.
</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>
<references> <displayreference target="I-D.ietf-ace-coap-est" to="ACE-COAP-EST"/>
<name>References</name> <displayreference target="I-D.richardson-anima-state-for-joinrouter" to="ANI
<references> MA-STATE"/>
<name>Normative References</name> <displayreference target="I-D.ietf-anima-constrained-voucher" to="ANIMA-CONS
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 TRAINED-VOUCHER"/>
119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21 <displayreference target="I-D.ietf-netconf-keystore" to="YANG-KEYSTORE"/>
19.xml"> <references pn="section-12">
<name slugifiedName="name-references">References</name>
<references pn="section-12.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="IDevID" target="https://1.ieee802.org/security/802-1a
r" quoteTitle="true" derivedAnchor="IDevID">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <title>IEEE Standard for Local and metropolitan area networks - Secu
le> re Device Identity</title>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <author>
<seriesInfo name="RFC" value="2119"/> <organization showOnFrontPage="true">IEEE</organization>
<seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author> </author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front> </front>
<refcontent>IEEE 802.1AR</refcontent>
</reference> </reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81 74.xml"> <reference anchor="ITU.X690" target="https://www.itu.int/rec/T-REC-X.690 " quoteTitle="true" derivedAnchor="ITU.X690">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <title>Information Technology - ASN.1 encoding rules: Specification
tle> of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
<seriesInfo name="DOI" value="10.17487/RFC8174"/> Encoding Rules (DER)</title>
<seriesInfo name="RFC" value="8174"/> <author>
<seriesInfo name="BCP" value="14"/> <organization showOnFrontPage="true">ITU-T</organization>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author> </author>
<date year="2017" month="May"/> <date month="August" year="2015"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front> </front>
<refcontent>ITU-T Recommendation X.690</refcontent>
<refcontent>ISO/IEC 8825-1:2015</refcontent>
</reference> </reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4 648" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.46 48.xml"> <reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/d issertation/fielding_dissertation.pdf" quoteTitle="true" derivedAnchor="REST">
<front> <front>
<title>The Base16, Base32, and Base64 Data Encodings</title> <title>Architectural Styles and the Design of Network-based Software
<seriesInfo name="DOI" value="10.17487/RFC4648"/> Architectures</title>
<seriesInfo name="RFC" value="4648"/> <author initials="R.F." surname="Fielding" fullname="Roy Fielding">
<author initials="S." surname="Josefsson" fullname="S. Josefsson"> <organization showOnFrontPage="true">University of California, Irv
<organization/> ine</organization>
</author> </author>
<date year="2006" month="October"/> <date year="2000"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and
base 16 encoding schemes. It also discusses the use of line-feeds in encoded d
ata, use of padding in encoded data, use of non-alphabet characters in encoded d
ata, use of different encoding alphabets, and canonical encodings. [STANDARDS-T
RACK]</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7 030" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.70 30.xml"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>Enrollment over Secure Transport</title> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<seriesInfo name="DOI" value="10.17487/RFC7030"/> le>
<seriesInfo name="RFC" value="7030"/> <author initials="S." surname="Bradner" fullname="S. Bradner">
<author initials="M." surname="Pritikin" fullname="M. Pritikin" role <organization showOnFrontPage="true"/>
="editor">
<organization/>
</author>
<author initials="P." surname="Yee" fullname="P. Yee" role="editor">
<organization/>
</author>
<author initials="D." surname="Harkins" fullname="D. Harkins" role="
editor">
<organization/>
</author> </author>
<date year="2013" month="October"/> <date year="1997" month="March"/>
<abstract> <abstract>
<t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This p rofile, called Enrollment over Secure Transport (EST), describes a simple, yet f unctional, certificate management protocol targeting Public Key Infrastructure ( PKI) clients that need to acquire client certificates and associated Certificati on Authority (CA) certificates. It also supports client-generated public/privat e key pairs as well as key pairs generated by the CA.</t> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often ca pitalized. This document defines these words as they should be interpreted in IE TF documents. This document specifies an Internet Best Current Practices for th e Internet Community, and requests discussion and suggestions for improvements.< /t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5 652" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.56 52.xml"> <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3 339" quoteTitle="true" derivedAnchor="RFC3339">
<front> <front>
<title>Cryptographic Message Syntax (CMS)</title> <title>Date and Time on the Internet: Timestamps</title>
<seriesInfo name="DOI" value="10.17487/RFC5652"/> <author initials="G." surname="Klyne" fullname="G. Klyne">
<seriesInfo name="RFC" value="5652"/> <organization showOnFrontPage="true"/>
<seriesInfo name="STD" value="70"/>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author> </author>
<date year="2009" month="September"/> <author initials="C." surname="Newman" fullname="C. Newman">
<organization showOnFrontPage="true"/>
</author>
<date year="2002" month="July"/>
<abstract> <abstract>
<t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitr ary message content. [STANDARDS-TRACK]</t> <t indent="0">This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representa tion of dates and times using the Gregorian calendar.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="3339"/>
<seriesInfo name="DOI" value="10.17487/RFC3339"/>
</reference> </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"> <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 688" quoteTitle="true" derivedAnchor="RFC3688">
<front> <front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl <title>The IETF XML Registry</title>
e> <author initials="M." surname="Mealling" fullname="M. Mealling">
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="8446"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author> </author>
<date year="2018" month="August"/> <date year="2004" month="January"/>
<abstract> <abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu <t indent="0">This document describes an IANA maintained registry
rity (TLS) protocol. TLS allows client/server applications to communicate over for IETF standards which use Extensible Markup Language (XML) related items such
the Internet in a way that is designed to prevent eavesdropping, tampering, and as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip
message forgery.</t> tion Framework (RDF) Schemas.</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> </abstract>
</front> </front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference> </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"> <reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3 748" quoteTitle="true" derivedAnchor="RFC3748">
<front> <front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert <title>Extensible Authentication Protocol (EAP)</title>
ificate Revocation List (CRL) Profile</title> <author initials="B." surname="Aboba" fullname="B. Aboba">
<seriesInfo name="DOI" value="10.17487/RFC5280"/> <organization showOnFrontPage="true"/>
<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>
<author initials="S." surname="Farrell" fullname="S. Farrell"> <author initials="L." surname="Blunk" fullname="L. Blunk">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen"> <author initials="J." surname="Vollbrecht" fullname="J. Vollbrecht">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="R." surname="Housley" fullname="R. Housley"> <author initials="J." surname="Carlson" fullname="J. Carlson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="W." surname="Polk" fullname="W. Polk"> <author initials="H." surname="Levkowetz" fullname="H. Levkowetz" ro
<organization/> le="editor">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2008" month="May"/> <date year="2004" month="June"/>
<abstract> <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> <t indent="0">This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authenticati on methods. EAP typically runs directly over data link layers such as Point-to- Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own su pport for duplicate elimination and retransmission, but is reliant on lower laye r ordering guarantees. Fragmentation is not supported within EAP itself; howeve r, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appe ndix A. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="3748"/>
<seriesInfo name="DOI" value="10.17487/RFC3748"/>
</reference> </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"> <reference anchor="RFC3927" target="https://www.rfc-editor.org/info/rfc3 927" quoteTitle="true" derivedAnchor="RFC3927">
<front> <front>
<title>Certificate Management over CMS (CMC)</title> <title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
<seriesInfo name="DOI" value="10.17487/RFC5272"/> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<seriesInfo name="RFC" value="5272"/> <organization showOnFrontPage="true"/>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author> </author>
<author initials="M." surname="Myers" fullname="M. Myers"> <author initials="B." surname="Aboba" fullname="B. Aboba">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2008" month="June"/> <author initials="E." surname="Guttman" fullname="E. Guttman">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="May"/>
<abstract> <abstract>
<t>This document defines the base syntax for CMC, a Certificate Ma <t indent="0">To participate in wide-area IP networking, a host ne
nagement protocol using the Cryptographic Message Syntax (CMS). This protocol ad eds to be configured with IP addresses for its interfaces, either manually by th
dresses two immediate needs within the Internet Public Key Infrastructure (PKI) e user or automatically from a source on the network such as a Dynamic Host Conf
community:</t> iguration Protocol (DHCP) server. Unfortunately, such address configuration inf
<t>1. The need for an interface to public key certification produ ormation may not always be available. It is therefore beneficial for a host to b
cts and services based on CMS and PKCS #10 (Public Key Cryptography Standard), a e able to depend on a useful subset of IP networking functions even when no addr
nd</t> ess configuration is available. This document describes how a host may automati
<t>2. The need for a PKI enrollment protocol for encryption only cally configure an interface with an IPv4 address within the 169.254/16 prefix t
keys due to algorithm or hardware design.</t> hat is valid for communication with other devices connected to the same physical
<t>CMC also requires the use of the transport document and the req (or logical) link.</t>
uirements usage document along with this document for a full definition. [STAND <t indent="0">IPv4 Link-Local addresses are not suitable for commu
ARDS-TRACK]</t> nication with devices not directly connected to the same physical (or logical) l
ink, and are only used where stable, routable addresses are not available (such
as on ad hoc or isolated networks). This document does not recommend that IPv4
Link-Local addresses and routable addresses be configured simultaneously on the
same interface. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="3927"/>
<seriesInfo name="DOI" value="10.17487/RFC3927"/>
</reference> </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"> <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4 086" quoteTitle="true" derivedAnchor="RFC4086">
<front> <front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format <title>Randomness Requirements for Security</title>
</title> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
<seriesInfo name="DOI" value="10.17487/RFC8259"/> rd">
<seriesInfo name="RFC" value="8259"/> <organization showOnFrontPage="true"/>
<seriesInfo name="STD" value="90"/>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor
">
<organization/>
</author> </author>
<date year="2017" month="December"/> <author initials="J." surname="Schiller" fullname="J. Schiller">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Crocker" fullname="S. Crocker">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="June"/>
<abstract> <abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, <t indent="0">Security systems are built on strong cryptographic a
language-independent data interchange format. It was derived from the ECMAScri lgorithms that foil pattern analysis attempts. However, the security of these s
pt Programming Language Standard. JSON defines a small set of formatting rules ystems is dependent on generating secret quantities for passwords, cryptographic
for the portable representation of structured data.</t> keys, and similar quantities. The use of pseudo-random processes to generate s
<t>This document removes inconsistencies with other specifications ecret quantities can result in pseudo-security. A sophisticated attacker may fin
of JSON, repairs specification errors, and offers experience-based interoperabi d it easier to reproduce the environment that produced the secret quantities and
lity guidance.</t> to search the resulting small set of possibilities than to locate the quantitie
s in the whole of the potential number space.</t>
<t indent="0">Choosing random quantities to foil a resourceful and
motivated adversary is surprisingly difficult. This document points out many p
itfalls in using poor entropy sources or traditional pseudo-random number genera
tion techniques for generating such quantities. It recommends the use of truly
random hardware techniques and shows that the existing hardware on many systems
can be used for this purpose. It provides suggestions to ameliorate the problem
when a hardware solution is not available, and it gives examples of how large su
ch quantities need to be for some applications. This document specifies an Inte
rnet Best Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference> </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"> <reference anchor="RFC4519" target="https://www.rfc-editor.org/info/rfc4 519" quoteTitle="true" derivedAnchor="RFC4519">
<front> <front>
<title>The YANG 1.1 Data Modeling Language</title> <title>Lightweight Directory Access Protocol (LDAP): Schema for User
<seriesInfo name="DOI" value="10.17487/RFC7950"/> Applications</title>
<seriesInfo name="RFC" value="7950"/> <author initials="A." surname="Sciberras" fullname="A. Sciberras" ro
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro le="editor">
le="editor"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<date year="2016" month="August"/> <date year="2006" month="June"/>
<abstract> <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> <t indent="0">This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a techni cal specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These obje cts are widely used as a basis for the schema in many LDAP directories. This do cument does not cover attributes used for the administration of directory server s, nor does it include directory objects defined for specific uses in other docu ments. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4519"/>
<seriesInfo name="DOI" value="10.17487/RFC4519"/>
</reference> </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"> <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4 648" quoteTitle="true" derivedAnchor="RFC4648">
<front> <front>
<title>JSON Encoding of Data Modeled with YANG</title> <title>The Base16, Base32, and Base64 Data Encodings</title>
<seriesInfo name="DOI" value="10.17487/RFC7951"/> <author initials="S." surname="Josefsson" fullname="S. Josefsson">
<seriesInfo name="RFC" value="7951"/> <organization showOnFrontPage="true"/>
<author initials="L." surname="Lhotka" fullname="L. Lhotka">
<organization/>
</author> </author>
<date year="2016" month="August"/> <date year="2006" month="October"/>
<abstract> <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> <t indent="0">This document describes the commonly used base 64, b ase 32, and base 16 encoding schemes. It also discusses the use of line-feeds i n encoded data, use of padding in encoded data, use of non-alphabet characters i n encoded data, use of different encoding alphabets, and canonical encodings. [ STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference> </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"> <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4 862" quoteTitle="true" derivedAnchor="RFC4862">
<front> <front>
<title>Lightweight Directory Access Protocol (LDAP): Schema for User <title>IPv6 Stateless Address Autoconfiguration</title>
Applications</title> <author initials="S." surname="Thomson" fullname="S. Thomson">
<seriesInfo name="DOI" value="10.17487/RFC4519"/> <organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="4519"/>
<author initials="A." surname="Sciberras" fullname="A. Sciberras" ro
le="editor">
<organization/>
</author> </author>
<date year="2006" month="June"/> <author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract> <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> <t indent="0">This document specifies the steps a host takes in de ciding how to autoconfigure its interfaces in IP version 6. The autoconfigurati on process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection pr ocedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]< /t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference> </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"> <reference anchor="RFC5272" target="https://www.rfc-editor.org/info/rfc5 272" quoteTitle="true" derivedAnchor="RFC5272">
<front> <front>
<title>Multicast DNS</title> <title>Certificate Management over CMS (CMC)</title>
<seriesInfo name="DOI" value="10.17487/RFC6762"/> <author initials="J." surname="Schaad" fullname="J. Schaad">
<seriesInfo name="RFC" value="6762"/> <organization showOnFrontPage="true"/>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author> </author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal"> <author initials="M." surname="Myers" fullname="M. Myers">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="February"/> <date year="2008" month="June"/>
<abstract> <abstract>
<t>As networked devices become smaller, more portable, and more ub <t indent="0">This document defines the base syntax for CMC, a Cer
iquitous, the ability to operate with less configured infrastructure is increasi tificate Management protocol using the Cryptographic Message Syntax (CMS). This
ngly important. In particular, the ability to look up DNS resource record data protocol addresses two immediate needs within the Internet Public Key Infrastruc
types (including, but not limited to, host names) in the absence of a convention ture (PKI) community:</t>
al managed DNS server is useful.</t> <t indent="0">1. The need for an interface to public key certific
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like o ation products and services based on CMS and PKCS #10 (Public Key Cryptography S
perations on the local link in the absence of any conventional Unicast DNS serve tandard), and</t>
r. In addition, Multicast DNS designates a portion of the DNS namespace to be f <t indent="0">2. The need for a PKI enrollment protocol for encry
ree for local use, without the need to pay any annual fee, and without the need ption only keys due to algorithm or hardware design.</t>
to set up delegations or otherwise configure a conventional DNS server to answer <t indent="0">CMC also requires the use of the transport document
for those names.</t> and the requirements usage document along with this document for a full definiti
<t>The primary benefits of Multicast DNS names are that (i) they r on. [STANDARDS-TRACK]</t>
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> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5272"/>
<seriesInfo name="DOI" value="10.17487/RFC5272"/>
</reference> </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"> <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5 280" quoteTitle="true" derivedAnchor="RFC5280">
<front> <front>
<title>DNS-Based Service Discovery</title> <title>Internet X.509 Public Key Infrastructure Certificate and Cert
<seriesInfo name="DOI" value="10.17487/RFC6763"/> ificate Revocation List (CRL) Profile</title>
<seriesInfo name="RFC" value="6763"/> <author initials="D." surname="Cooper" fullname="D. Cooper">
<author initials="S." surname="Cheshire" fullname="S. Cheshire"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal"> <author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="February"/> <author initials="S." surname="Farrell" fullname="S. Farrell">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="May"/>
<abstract> <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> <t indent="0">This memo profiles the X.509 v3 certificate and X.50 9 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificat e format is described in detail, with additional information regarding the forma t and semantics of Internet name forms. Standard certificate extensions are des cribed and two Internet-specific extensions are defined. A set of required cert ificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 c ertification path validation is described. An ASN.1 module and examples are pro vided in the appendices. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference> </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"> <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5 652" quoteTitle="true" derivedAnchor="RFC5652">
<front> <front>
<title>Dynamic Configuration of IPv4 Link-Local Addresses</title> <title>Cryptographic Message Syntax (CMS)</title>
<seriesInfo name="DOI" value="10.17487/RFC3927"/> <author initials="R." surname="Housley" fullname="R. Housley">
<seriesInfo name="RFC" value="3927"/> <organization showOnFrontPage="true"/>
<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> </author>
<date year="2005" month="May"/> <date year="2009" month="September"/>
<abstract> <abstract>
<t>To participate in wide-area IP networking, a host needs to be c <t indent="0">This document describes the Cryptographic Message Sy
onfigured with IP addresses for its interfaces, either manually by the user or a ntax (CMS). This syntax is used to digitally sign, digest, authenticate, or enc
utomatically from a source on the network such as a Dynamic Host Configuration P rypt arbitrary message content. [STANDARDS-TRACK]</t>
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> </abstract>
</front> </front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference> </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"> <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6 020" quoteTitle="true" derivedAnchor="RFC6020">
<front> <front>
<title>Date and Time on the Internet: Timestamps</title> <title>YANG - A Data Modeling Language for the Network Configuration
<seriesInfo name="DOI" value="10.17487/RFC3339"/> Protocol (NETCONF)</title>
<seriesInfo name="RFC" value="3339"/> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
<author initials="G." surname="Klyne" fullname="G. Klyne"> le="editor">
<organization/> <organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Newman" fullname="C. Newman">
<organization/>
</author> </author>
<date year="2002" month="July"/> <date year="2010" month="October"/>
<abstract> <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> <t indent="0">YANG is a data modeling language used to model confi guration and state data manipulated by the Network Configuration Protocol (NETCO NF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK ]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference> </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"> <reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6 125" quoteTitle="true" derivedAnchor="RFC6125">
<front> <front>
<title>Randomness Requirements for Security</title> <title>Representation and Verification of Domain-Based Application S
<seriesInfo name="DOI" value="10.17487/RFC4086"/> ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
<seriesInfo name="RFC" value="4086"/> tificates in the Context of Transport Layer Security (TLS)</title>
<seriesInfo name="BCP" value="106"/> <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3 ">
rd"> <organization showOnFrontPage="true"/>
<organization/>
</author>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization/>
</author> </author>
<author initials="S." surname="Crocker" fullname="S. Crocker"> <author initials="J." surname="Hodges" fullname="J. Hodges">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2005" month="June"/> <date year="2011" month="March"/>
<abstract> <abstract>
<t>Security systems are built on strong cryptographic algorithms t <t indent="0">Many application technologies enable secure communic
hat foil pattern analysis attempts. However, the security of these systems is d ation between two entities by means of Internet Public Key Infrastructure Using
ependent on generating secret quantities for passwords, cryptographic keys, and X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This
similar quantities. The use of pseudo-random processes to generate secret quant document specifies procedures for representing and verifying the identity of ap
ities can result in pseudo-security. A sophisticated attacker may find it easier plication services in such interactions. [STANDARDS-TRACK]</t>
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> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
</reference> </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"> <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 241" quoteTitle="true" derivedAnchor="RFC6241">
<front> <front>
<title>IPv6 Stateless Address Autoconfiguration</title> <title>Network Configuration Protocol (NETCONF)</title>
<seriesInfo name="DOI" value="10.17487/RFC4862"/> <author initials="R." surname="Enns" fullname="R. Enns" role="editor
<seriesInfo name="RFC" value="4862"/> ">
<author initials="S." surname="Thomson" fullname="S. Thomson"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="T." surname="Narten" fullname="T. Narten"> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
<organization/> le="editor">
<organization showOnFrontPage="true"/>
</author> </author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei"> <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
<organization/> lder" role="editor">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2007" month="September"/> <author initials="A." surname="Bierman" fullname="A. Bierman" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract> <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> <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the con figuration of network devices. It uses an Extensible Markup Language (XML)-base d data encoding for the configuration data as well as the protocol messages. Th e NETCONF protocol operations are realized as remote procedure calls (RPCs). Th is document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference> </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"> <reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6 762" quoteTitle="true" derivedAnchor="RFC6762">
<front> <front>
<title>Privacy Extensions for Stateless Address Autoconfiguration in <title>Multicast DNS</title>
IPv6</title> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<seriesInfo name="DOI" value="10.17487/RFC4941"/> <organization showOnFrontPage="true"/>
<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>
<author initials="S." surname="Krishnan" fullname="S. Krishnan"> <author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2007" month="September"/> <date year="2013" month="February"/>
<abstract> <abstract>
<t>Nodes use IPv6 stateless address autoconfiguration to generate <t indent="0">As networked devices become smaller, more portable,
addresses using a combination of locally available information and information a and more ubiquitous, the ability to operate with less configured infrastructure
dvertised by routers. Addresses are formed by combining network prefixes with a is increasingly important. In particular, the ability to look up DNS resource r
n interface identifier. On an interface that contains an embedded IEEE Identifi ecord data types (including, but not limited to, host names) in the absence of a
er, the interface identifier is typically derived from it. On other interface t conventional managed DNS server is useful.</t>
ypes, the interface identifier is generated through other means, for example, vi <t indent="0">Multicast DNS (mDNS) provides the ability to perform
a random number generation. This document describes an extension to IPv6 statel DNS-like operations on the local link in the absence of any conventional Unicas
ess address autoconfiguration for interfaces whose interface identifier is deriv t DNS server. In addition, Multicast DNS designates a portion of the DNS namesp
ed from an IEEE identifier. Use of the extension causes nodes to generate globa ace to be free for local use, without the need to pay any annual fee, and withou
l scope addresses from interface identifiers that change over time, even in case t the need to set up delegations or otherwise configure a conventional DNS serve
s where the interface contains an embedded IEEE identifier. Changing the interf r to answer for those names.</t>
ace identifier (and the global scope addresses generated from it) over time make <t indent="0">The primary benefits of Multicast DNS names are that
s it more difficult for eavesdroppers and other information collectors to identi (i) they require little or no administration or configuration to set them up, (
fy when different addresses used in different transactions actually correspond t ii) they work when no infrastructure is present, and (iii) they work during infr
o the same node. [STANDARDS-TRACK]</t> astructure failures.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6762"/>
<seriesInfo name="DOI" value="10.17487/RFC6762"/>
</reference> </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"> <reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6 763" quoteTitle="true" derivedAnchor="RFC6763">
<front> <front>
<title>Extensible Authentication Protocol (EAP)</title> <title>DNS-Based Service Discovery</title>
<seriesInfo name="DOI" value="10.17487/RFC3748"/> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<seriesInfo name="RFC" value="3748"/> <organization showOnFrontPage="true"/>
<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>
<author initials="H." surname="Levkowetz" fullname="H. Levkowetz" ro <author initials="M." surname="Krochmal" fullname="M. Krochmal">
le="editor"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<date year="2004" month="June"/> <date year="2013" month="February"/>
<abstract> <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> <t indent="0">This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for th at service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6763"/>
<seriesInfo name="DOI" value="10.17487/RFC6763"/>
</reference> </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"> <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7 030" quoteTitle="true" derivedAnchor="RFC7030">
<front> <front>
<title>Representation and Verification of Domain-Based Application S <title>Enrollment over Secure Transport</title>
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer <author initials="M." surname="Pritikin" fullname="M. Pritikin" role
tificates in the Context of Transport Layer Security (TLS)</title> ="editor">
<seriesInfo name="DOI" value="10.17487/RFC6125"/> <organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="6125"/>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
">
<organization/>
</author> </author>
<author initials="J." surname="Hodges" fullname="J. Hodges"> <author initials="P." surname="Yee" fullname="P. Yee" role="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2011" month="March"/> <author initials="D." surname="Harkins" fullname="D. Harkins" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="October"/>
<abstract> <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> <t indent="0">This document profiles certificate enrollment for cl ients using Certificate Management over CMS (CMC) messages over a secure transpo rt. This profile, called Enrollment over Secure Transport (EST), describes a si mple, yet functional, certificate management protocol targeting Public Key Infra structure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated pu blic/private key pairs as well as key pairs generated by the CA.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7030"/>
<seriesInfo name="DOI" value="10.17487/RFC7030"/>
</reference> </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"> <reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7 230" quoteTitle="true" derivedAnchor="RFC7230">
<front> <front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Ro uting</title> <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"> <author initials="R." surname="Fielding" fullname="R. Fielding" role ="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J." surname="Reschke" fullname="J. Reschke" role=" editor"> <author initials="J." surname="Reschke" fullname="J. Reschke" role=" editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2014" month="June"/> <date year="2014" month="June"/>
<abstract> <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> <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateles s application-level protocol for distributed, collaborative, hypertext informati on systems. This document provides an overview of HTTP architecture and its ass ociated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7230"/>
<seriesInfo name="DOI" value="10.17487/RFC7230"/>
</reference> </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"> <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7 231" quoteTitle="true" derivedAnchor="RFC7231">
<front> <front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content </title> <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"> <author initials="R." surname="Fielding" fullname="R. Fielding" role ="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J." surname="Reschke" fullname="J. Reschke" role=" editor"> <author initials="J." surname="Reschke" fullname="J. Reschke" role=" editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2014" month="June"/> <date year="2014" month="June"/>
<abstract> <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> <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateles s \%application- level protocol for distributed, collaborative, hypertext inform ation systems. This document defines the semantics of HTTP/1.1 messages, as exp ressed by request methods, request header fields, response status codes, and res ponse header fields, along with the payload of messages (metadata and body conte nt) and mechanisms for content negotiation.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7231"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/>
</reference> </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"> <reference anchor="RFC7469" target="https://www.rfc-editor.org/info/rfc7 469" quoteTitle="true" derivedAnchor="RFC7469">
<front> <front>
<title>Public Key Pinning Extension for HTTP</title> <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"> <author initials="C." surname="Evans" fullname="C. Evans">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="C." surname="Palmer" fullname="C. Palmer"> <author initials="C." surname="Palmer" fullname="C. Palmer">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="R." surname="Sleevi" fullname="R. Sleevi"> <author initials="R." surname="Sleevi" fullname="R. Sleevi">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2015" month="April"/> <date year="2015" month="April"/>
<abstract> <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> <t indent="0">This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' crypto graphic identities over a period of time. During that time, user agents (UAs) w ill require that the host presents a certificate chain including at least one Su bject Public Key Info structure whose fingerprint matches one of the pinned fing erprints for that host. By effectively reducing the number of trusted authoriti es who can authenticate the domain during the lifetime of the pin, pinning may r educe the incidence of man-in-the-middle attacks due to compromised Certificatio n Authorities.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7469"/>
<seriesInfo name="DOI" value="10.17487/RFC7469"/>
</reference> </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"> <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7 950" quoteTitle="true" derivedAnchor="RFC7950">
<front> <front>
<title>An Autonomic Control Plane (ACP)</title> <title>The YANG 1.1 Data Modeling Language</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic- <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
control-plane-28"/> le="editor">
<author initials="T" surname="Eckert" fullname="Toerless Eckert"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="M" surname="Behringer" fullname="Michael Behringer <date year="2016" month="August"/>
"> <abstract>
<organization/> <t indent="0">YANG is a data modeling language used to model confi
guration data, state data, Remote Procedure Calls, and notifications for network
management protocols. This document describes the syntax and semantics of vers
ion 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the
YANG language, addressing ambiguities and defects in the original specification.
There are a small number of backward incompatibilities from YANG version 1. T
his document also specifies the YANG mappings to the Network Configuration Proto
col (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7
951" quoteTitle="true" derivedAnchor="RFC7951">
<front>
<title>JSON Encoding of Data Modeled with YANG</title>
<author initials="L." surname="Lhotka" fullname="L. Lhotka">
<organization showOnFrontPage="true"/>
</author> </author>
<author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnas <date year="2016" month="August"/>
on"> <abstract>
<organization/> <t indent="0">This document defines encoding rules for representin
g configuration data, state data, parameters of Remote Procedure Call (RPC) oper
ations or actions, and notifications defined using YANG as JavaScript Object Not
ation (JSON) text.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7951"/>
<seriesInfo name="DOI" value="10.17487/RFC7951"/>
</reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040" quoteTitle="true" derivedAnchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization showOnFrontPage="true"/>
</author> </author>
<date month="July" day="28" year="2020"/> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="January"/>
<abstract> <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> <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference> </reference>
<reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8 <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
366" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83 174" quoteTitle="true" derivedAnchor="RFC8174">
66.xml"> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
259" quoteTitle="true" derivedAnchor="RFC8259">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format
</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="December"/>
<abstract>
<t indent="0">JavaScript Object Notation (JSON) is a lightweight,
text-based, language-independent data interchange format. It was derived from t
he ECMAScript Programming Language Standard. JSON defines a small set of format
ting rules for the portable representation of structured data.</t>
<t indent="0">This document removes inconsistencies with other spe
cifications of JSON, repairs specification errors, and offers experience-based i
nteroperability guidance.</t>
</abstract>
</front>
<seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference>
<reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8
366" quoteTitle="true" derivedAnchor="RFC8366">
<front> <front>
<title>A Voucher Artifact for Bootstrapping Protocols</title> <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"> <author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Richardson" fullname="M. Richardson"> <author initials="M." surname="Richardson" fullname="M. Richardson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Pritikin" fullname="M. Pritikin"> <author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="T." surname="Eckert" fullname="T. Eckert"> <author initials="T." surname="Eckert" fullname="T. Eckert">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2018" month="May"/> <date year="2018" month="May"/>
<abstract> <abstract>
<t>This document defines a strategy to securely assign a pledge to <t indent="0">This document defines a strategy to securely assign
an owner using an artifact signed, directly or indirectly, by the pledge's manu a pledge to an owner using an artifact signed, directly or indirectly, by the pl
facturer. This artifact is known as a "voucher".</t> edge's manufacturer. This artifact is known as a "voucher".</t>
<t>This document defines an artifact format as a YANG-defined JSON <t indent="0">This document defines an artifact format as a YANG-d
document that has been signed using a Cryptographic Message Syntax (CMS) struct efined JSON document that has been signed using a Cryptographic Message Syntax (
ure. Other YANG-derived formats are possible. The voucher artifact is normally CMS) structure. Other YANG-derived formats are possible. The voucher artifact
generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signi is normally generated by the pledge's manufacturer (i.e., the Manufacturer Autho
ng Authority (MASA)).</t> rized Signing Authority (MASA)).</t>
<t>This document only defines the voucher artifact, leaving it to <t indent="0">This document only defines the voucher artifact, lea
other documents to describe specialized protocols for accessing it.</t> ving it to other documents to describe specialized protocols for accessing it.</
t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8366"/>
<seriesInfo name="DOI" value="10.17487/RFC8366"/>
</reference> </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"> <reference anchor="RFC8368" target="https://www.rfc-editor.org/info/rfc8 368" quoteTitle="true" derivedAnchor="RFC8368">
<front> <front>
<title>Using an Autonomic Control Plane for Stable Connectivity of N etwork Operations, Administration, and Maintenance (OAM)</title> <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"> <author initials="T." surname="Eckert" fullname="T. Eckert" role="ed itor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Behringer" fullname="M. Behringer"> <author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2018" month="May"/> <date year="2018" month="May"/>
<abstract> <abstract>
<t>Operations, Administration, and Maintenance (OAM), as per BCP 1 <t indent="0">Operations, Administration, and Maintenance (OAM), a
61, for data networks is often subject to the problem of circular dependencies w s per BCP 161, for data networks is often subject to the problem of circular dep
hen relying on connectivity provided by the network to be managed for the OAM pu endencies when relying on connectivity provided by the network to be managed for
rposes.</t> the OAM purposes.</t>
<t>Provisioning while bringing up devices and networks tends to be <t indent="0">Provisioning while bringing up devices and networks
more difficult to automate than service provisioning later on. Changes in core tends to be more difficult to automate than service provisioning later on. Chan
network functions impacting reachability cannot be automated because of ongoing ges in core network functions impacting reachability cannot be automated because
connectivity requirements for the OAM equipment itself, and widely used OAM pro of ongoing connectivity requirements for the OAM equipment itself, and widely u
tocols are not secure enough to be carried across the network without security c sed OAM protocols are not secure enough to be carried across the network without
oncerns.</t> security concerns.</t>
<t>This document describes how to integrate OAM processes with an <t indent="0">This document describes how to integrate OAM process
autonomic control plane in order to provide stable and secure connectivity for t es with an autonomic control plane in order to provide stable and secure connect
hose OAM processes. This connectivity is not subject to the aforementioned circ ivity for those OAM processes. This connectivity is not subject to the aforemen
ular dependencies.</t> tioned circular dependencies.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8368"/>
<seriesInfo name="DOI" value="10.17487/RFC8368"/>
</reference> </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"> <reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8 407" quoteTitle="true" derivedAnchor="RFC8407">
<front> <front>
<title>A Generic Autonomic Signaling Protocol (GRASP)</title> <title>Guidelines for Authors and Reviewers of Documents Containing
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-grasp-15"/ YANG Data Models</title>
> <author initials="A." surname="Bierman" fullname="A. Bierman">
<author initials="C" surname="Bormann" fullname="Carsten Bormann"> <organization showOnFrontPage="true"/>
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author> </author>
<author initials="B" surname="Liu" fullname="Bing Liu"> <date year="2018" month="October"/>
<organization/> <abstract>
<t indent="0">This memo provides guidelines for authors and review
ers of specifications containing YANG modules. Recommendations and procedures a
re defined, which are intended to increase interoperability and usability of Net
work Configuration Protocol (NETCONF) and RESTCONF protocol implementations that
utilize YANG modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author> </author>
<date month="July" day="13" year="2017"/> <date year="2018" month="August"/>
<abstract> <abstract>
<t>This document specifies the GeneRic Autonomic Signaling Protoco <t indent="0">This document specifies version 1.3 of the Transport
l (GRASP), which enables autonomic nodes and autonomic service agents to dynamic Layer Security (TLS) protocol. TLS allows client/server applications to commun
ally discover peers, to synchronize state with each other, and to negotiate para icate over the Internet in a way that is designed to prevent eavesdropping, tamp
meter settings with each other. GRASP depends on an external security environme ering, and message forgery.</t>
nt that is described elsewhere. The technical objectives and parameters for spe <t indent="0">This document updates RFCs 5705 and 6066, and obsole
cific application scenarios are to be described in separate documents. Appendic tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
es briefly discuss requirements for the protocol and existing protocols with com r TLS 1.2 implementations.</t>
parable features.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference> </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"> <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8 610" quoteTitle="true" derivedAnchor="RFC8610">
<front> <front>
<title>Concise Data Definition Language (CDDL): A Notational Convent ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu res</title> <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"> <author initials="H." surname="Birkholz" fullname="H. Birkholz">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="C." surname="Vigano" fullname="C. Vigano"> <author initials="C." surname="Vigano" fullname="C. Vigano">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="C." surname="Bormann" fullname="C. Bormann"> <author initials="C." surname="Bormann" fullname="C. Bormann">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2019" month="June"/> <date year="2019" month="June"/>
<abstract> <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> <t indent="0">This document proposes a notational convention to ex press Concise Binary Object Representation (CBOR) data structures (RFC 7049). I ts main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference> </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"> <reference anchor="RFC8951" target="https://www.rfc-editor.org/info/rfc8 951" quoteTitle="true" derivedAnchor="RFC8951">
<front> <front>
<title>RESTCONF Protocol</title> <title>Clarification of Enrollment over Secure Transport (EST): Tran
<seriesInfo name="DOI" value="10.17487/RFC8040"/> sfer Encodings and ASN.1</title>
<seriesInfo name="RFC" value="8040"/> <author initials="M." surname="Richardson" fullname="M. Richardson">
<author initials="A." surname="Bierman" fullname="A. Bierman"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund"> <author initials="T." surname="Werner" fullname="T. Werner">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="K." surname="Watsen" fullname="K. Watsen"> <author initials="W." surname="Pan" fullname="W. Pan">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2017" month="January"/> <date year="2020" month="November"/>
<abstract> <abstract>
<t>This document describes an HTTP-based protocol that provides a <t indent="0">This document updates RFC 7030: Enrollment over Secu
programmatic interface for accessing data defined in YANG, using the datastore c re Transport to resolve some errata that were reported and that have proven to c
oncepts defined in the Network Configuration Protocol (NETCONF).</t> ause interoperability issues when RFC 7030 was extended.</t>
<t indent="0">This document deprecates the specification of "Conte
nt-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoin
ts. This document fixes some syntactical errors in ASN.1 that were present.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8951"/>
<seriesInfo name="DOI" value="10.17487/RFC8951"/>
</reference> </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"> <reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8 981" quoteTitle="true" derivedAnchor="RFC8981">
<front> <front>
<title>YANG - A Data Modeling Language for the Network Configuration <title>Temporary Address Extensions for Stateless Address Autoconfig
Protocol (NETCONF)</title> uration in IPv6</title>
<seriesInfo name="DOI" value="10.17487/RFC6020"/> <author initials="F." surname="Gont" fullname="F. Gont">
<seriesInfo name="RFC" value="6020"/> <organization showOnFrontPage="true"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author> </author>
<date year="2010" month="October"/> <author initials="S." surname="Krishnan" fullname="S. Krishnan">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Draves" fullname="R. Draves">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="February"/>
<abstract> <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> <t indent="0">This document describes an extension to IPv6 Statele ss Address Autoconfiguration that causes hosts to generate temporary addresses w ith randomized interface identifiers for each prefix advertised with autoconfigu ration enabled. Changing addresses over time limits the window of time during wh ich eavesdroppers and other information collectors may trivially perform address -based network-activity correlation when the same address is employed for multip le transactions by the same host. Additionally, it reduces the window of exposur e of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8981"/>
<seriesInfo name="DOI" value="10.17487/RFC8981"/>
</reference> </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"> <reference anchor="RFC8990" quoteTitle="true" target="https://www.rfc-ed itor.org/rfc/rfc8990" derivedAnchor="RFC8990">
<front> <front>
<title>Network Configuration Protocol (NETCONF)</title> <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
<seriesInfo name="DOI" value="10.17487/RFC6241"/> <author initials="C" surname="Bormann" fullname="Carsten Bormann">
<seriesInfo name="RFC" value="6241"/> <organization showOnFrontPage="true"/>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor
">
<organization/>
</author> </author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro <author initials="B" surname="Carpenter" fullname="Brian Carpenter"
le="editor"> role="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae <author initials="B" surname="Liu" fullname="Bing Liu" role="editor"
lder" role="editor"> >
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role=" <date month="May" year="2021"/>
editor"> </front>
<organization/> <seriesInfo name="RFC" value="8990"/>
<seriesInfo name="DOI" value="10.17487/RFC8990"/>
</reference>
<reference anchor="RFC8994" quoteTitle="true" target="https://www.rfc-ed
itor.org/rfc/rfc8994" derivedAnchor="RFC8994">
<front>
<title>An Autonomic Control Plane (ACP)</title>
<author initials="T" surname="Eckert" fullname="Toerless Eckert" rol
e="editor">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2011" month="June"/> <author initials="M" surname="Behringer" fullname="Michael Behringer
<abstract> " role="editor">
<t>The Network Configuration Protocol (NETCONF) defined in this do <organization showOnFrontPage="true"/>
cument provides mechanisms to install, manipulate, and delete the configuration </author>
of network devices. It uses an Extensible Markup Language (XML)-based data enco <author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnas
ding for the configuration data as well as the protocol messages. The NETCONF p on">
rotocol operations are realized as remote procedure calls (RPCs). This document <organization showOnFrontPage="true"/>
obsoletes RFC 4741. [STANDARDS-TRACK]</t> </author>
</abstract> <date month="May" year="2021"/>
</front> </front>
<seriesInfo name="RFC" value="8994"/>
<seriesInfo name="DOI" value="10.17487/RFC8994"/>
</reference> </reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8 </references>
407" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84 <references pn="section-12.2">
07.xml"> <name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.ietf-ace-coap-est" quoteTitle="true" target="http
s://tools.ietf.org/html/draft-ietf-ace-coap-est-18" derivedAnchor="ACE-COAP-EST"
>
<front> <front>
<title>Guidelines for Authors and Reviewers of Documents Containing <title>EST over secure CoAP (EST-coaps)</title>
YANG Data Models</title> <author initials="P" surname="van der Stok" fullname="Peter van der
<seriesInfo name="DOI" value="10.17487/RFC8407"/> Stok">
<seriesInfo name="RFC" value="8407"/> <organization showOnFrontPage="true">Consultant</organization>
<seriesInfo name="BCP" value="216"/>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author> </author>
<date year="2018" month="October"/> <author fullname="Panos Kampanakis">
<abstract> <organization showOnFrontPage="true">Cisco Systems</organization>
<t>This memo provides guidelines for authors and reviewers of spec </author>
ifications containing YANG modules. Recommendations and procedures are defined, <author fullname="Michael Richardson">
which are intended to increase interoperability and usability of Network Config <organization showOnFrontPage="true">Sandelman Software Works</org
uration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YA anization>
NG modules. This document obsoletes RFC 6087.</t> </author>
</abstract> <author fullname="Shahid Raza">
<organization showOnFrontPage="true">RISE SICS</organization>
</author>
<date month="January" day="6" year="2020"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="ITU.X690.1994" xml:base="https://xml2rfc.tools.ietf.o rg/public/rfc/bibxml2/reference.ITU.X690.1994.xml"> <reference anchor="I-D.ietf-anima-constrained-voucher" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-10" de rivedAnchor="ANIMA-CONSTRAINED-VOUCHER">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification <title>Constrained Voucher Artifacts for Bootstrapping Protocols</ti
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished tle>
Encoding Rules (DER)</title> <author fullname="Michael Richardson">
<seriesInfo name="ITU-T" value="Recommendation X.690"/> <organization showOnFrontPage="true">Sandelman Software Works</org
<author> anization>
<organization>International Telecommunications Union</organization
>
</author> </author>
<date month="" year="1994"/> <author initials="P" surname="van der Stok" fullname="Peter van der
Stok">
<organization showOnFrontPage="true">vanderstok consultancy</organ
ization>
</author>
<author fullname="Panos Kampanakis">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Esko Dijk">
<organization showOnFrontPage="true">IoTconsultancy.nl</organizati
on>
</author>
<date month="February" day="21" year="2021"/>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-
voucher-10"/>
<refcontent>Work in Progress</refcontent>
</reference> </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"> <reference anchor="I-D.richardson-anima-state-for-joinrouter" quoteTitle ="true" target="https://tools.ietf.org/html/draft-richardson-anima-state-for-joi nrouter-03" derivedAnchor="ANIMA-STATE">
<front> <front>
<title>The IETF XML Registry</title> <title>Considerations for stateful vs stateless join router in ANIMA
<seriesInfo name="DOI" value="10.17487/RFC3688"/> bootstrap</title>
<seriesInfo name="RFC" value="3688"/> <author fullname="Michael Richardson">
<seriesInfo name="BCP" value="81"/> <organization showOnFrontPage="true">Sandelman Software Works</org
<author initials="M." surname="Mealling" fullname="M. Mealling"> anization>
<organization/>
</author> </author>
<date year="2004" month="January"/> <date month="September" day="22" year="2020"/>
<abstract> <abstract>
<t>This document describes an IANA maintained registry for IETF st <t indent="0"> This document explores a number of issues affecti
andards which use Extensible Markup Language (XML) related items such as Namespa ng the decision to
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew use a stateful or stateless forwarding mechanism by the join router
ork (RDF) Schemas.</t> (aka join assistant) during the bootstrap process for ANIMA.
</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-richardson-anima-state-
for-joinrouter-03"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="IDevID" target="http://standards.ieee.org/findstds/st andard/802.1AR-2009.html"> <reference anchor="brewski" target="https://www.urbandictionary.com/defi ne.php?term=brewski" quoteTitle="true" derivedAnchor="brewski">
<front> <front>
<title>IEEE 802.1AR Secure Device Identifier</title> <title>brewski</title>
<author surname="IEEE Standard"/> <author>
<date month="December" year="2009"/> <organization showOnFrontPage="true">Urban Dictionary</organizatio
n>
</author>
<date month="March" year="2003"/>
</front> </front>
</reference> </reference>
<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/d issertation/top.htm"> <reference anchor="cabforumaudit" target="https://cabforum.org/informati on-for-auditors-and-assessors/" quoteTitle="true" derivedAnchor="cabforumaudit">
<front> <front>
<title>Architectural Styles and the Design of Network-based Software <title>Information for Auditors and Assessors</title>
Architectures</title> <author>
<author initials="R.F." surname="Fielding" fullname="Roy Fielding"> <organization showOnFrontPage="true">CA/Browser Forum</organizatio
<organization>University of California, Irvine</organization> n>
</author> </author>
<date year="2000"/> <date month="August" year="2019"/>
</front> </front>
</reference> </reference>
</references> <reference anchor="Dingledine" target="https://svn-archive.torproject.or
<references> g/svn/projects/design-paper/tor-design.pdf" quoteTitle="true" derivedAnchor="Din
<name>Informative References</name> gledine">
<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> <front>
<title>A Reference Model for Autonomic Networking</title> <title>Tor: The Second-Generation Onion Router</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-reference- <author initials="R." surname="Dingledine">
model-10"/> <organization showOnFrontPage="true"/>
<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>
<author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia <author initials="N." surname="Mathewson">
"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<author initials="J" surname="Nobre" fullname="Jeferson Nobre"> <author initials="P." surname="Syverson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date month="November" day="22" year="2018"/> <date month="August" year="2004"/>
<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> </front>
</reference> </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"> <reference anchor="dnssecroot" target="https://www.iana.org/dnssec/proce dures/zsk-operator/dps-zsk-operator-v2.1.pdf" quoteTitle="true" derivedAnchor="d nssecroot">
<front> <front>
<title>Opportunistic Security: Some Protection Most of the Time</tit <title>DNSSEC Practice Statement for the Root Zone ZSK Operator</tit
le> le>
<seriesInfo name="DOI" value="10.17487/RFC7435"/> <author surname="Verisign"/>
<seriesInfo name="RFC" value="7435"/> <date month="December" year="2017"/>
<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> </front>
</reference> </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"> <reference anchor="docsisroot" target="https://www.cablelabs.com/resourc es/digital-certificate-issuance-service/" quoteTitle="true" derivedAnchor="docsi sroot">
<front> <front>
<title>Autonomic Networking: Definitions and Design Goals</title> <title>CableLabs Digital Certificate Issuance Service</title>
<seriesInfo name="DOI" value="10.17487/RFC7575"/> <author surname="CableLabs"/>
<seriesInfo name="RFC" value="7575"/> <date month="February" year="2018"/>
<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> </front>
</reference> </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"> <reference anchor="imprinting" target="https://en.wikipedia.org/w/index. php?title=Imprinting_(psychology)&amp;=999211441" quoteTitle="true" derivedAncho r="imprinting">
<front> <front>
<title>Terminology for Constrained-Node Networks</title> <title>Imprinting (psychology)</title>
<seriesInfo name="DOI" value="10.17487/RFC7228"/> <author>
<seriesInfo name="RFC" value="7228"/> <organization showOnFrontPage="true">Wikipedia</organization>
<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> </author>
<date year="2014" month="May"/> <date month="January" year="2021"/>
<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> </front>
</reference> </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"> <reference anchor="IoTstrangeThings" target="https://www.welivesecurity. com/2017/03/03/internet-of-things-security-privacy-iot-update/" quoteTitle="true " derivedAnchor="IoTstrangeThings">
<front> <front>
<title>Pervasive Monitoring Is an Attack</title> <title>IoT of toys stranger than fiction: Cybersecurity and data pri
<seriesInfo name="DOI" value="10.17487/RFC7258"/> vacy update</title>
<seriesInfo name="RFC" value="7258"/> <author>
<seriesInfo name="BCP" value="188"/> <organization showOnFrontPage="true">ESET</organization>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author> </author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig"> <date month="March" year="2017"/>
<organization/> </front>
</reference>
<reference anchor="livingwithIoT" target="https://www.siliconrepublic.co
m/machines/iot-smart-devices-reality" quoteTitle="true" derivedAnchor="livingwit
hIoT">
<front>
<title>What is it actually like to live in a house filled with IoT d
evices?</title>
<author>
<organization showOnFrontPage="true">Silicon Republic</organizatio
n>
</author> </author>
<date year="2014" month="May"/> <date month="February" year="2018"/>
<abstract>
<t>Pervasive monitoring is a technical attack that should be mitig
ated in the design of IETF protocols, where possible.</t>
</abstract>
</front> </front>
</reference> </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"> <reference anchor="minerva" target="https://minerva.sandelman.ca/" quote Title="true" derivedAnchor="minerva">
<front> <front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</titl <title>Minerva reference implementation for BRSKI</title>
e> <author fullname="Michael Richardson" initials="M." surname="Richard
<seriesInfo name="DOI" value="10.17487/RFC5785"/> son"/>
<seriesInfo name="RFC" value="5785"/> <date year="2020"/>
<author initials="M." surname="Nottingham" fullname="M. Nottingham"> </front>
<organization/> </reference>
<reference anchor="minervagithub" target="https://github.com/ANIMAgus-mi
nerva" quoteTitle="true" derivedAnchor="minervagithub">
<front>
<title>ANIMA Minerva toolkit</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="openssl" target="https://www.openssl.org/docs/man1.1.
1/man1/openssl-x509.html/" quoteTitle="true" derivedAnchor="openssl">
<front>
<title>OpenSSL X509 Utility</title>
<author>
<organization showOnFrontPage="true">OpenSSL</organization>
</author> </author>
<author initials="E." surname="Hammer-Lahav" fullname="E. Hammer-Lah <date month="September" year="2019"/>
av"> </front>
<organization/> </reference>
<reference anchor="RFC2131" target="https://www.rfc-editor.org/info/rfc2
131" quoteTitle="true" derivedAnchor="RFC2131">
<front>
<title>Dynamic Host Configuration Protocol</title>
<author initials="R." surname="Droms" fullname="R. Droms">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2010" month="April"/> <date year="1997" month="March"/>
<abstract> <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> <t indent="0">The Dynamic Host Configuration Protocol (DHCP) provi des a framework for passing configuration information to hosts on a TCPIP networ k. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of au tomatic allocation of reusable network addresses and additional configuration op tions. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="2131"/>
<seriesInfo name="DOI" value="10.17487/RFC2131"/>
</reference> </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"> <reference anchor="RFC2663" target="https://www.rfc-editor.org/info/rfc2 663" quoteTitle="true" derivedAnchor="RFC2663">
<front> <front>
<title>IP Network Address Translator (NAT) Terminology and Considera tions</title> <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"> <author initials="P." surname="Srisuresh" fullname="P. Srisuresh">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Holdrege" fullname="M. Holdrege"> <author initials="M." surname="Holdrege" fullname="M. Holdrege">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="1999" month="August"/> <date year="1999" month="August"/>
<abstract> <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> <t indent="0">This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the term inology used to identify various flavors of NAT. This memo provides information for the Internet community.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="2663"/>
<seriesInfo name="DOI" value="10.17487/RFC2663"/>
</reference> </reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6 <reference anchor="RFC5209" target="https://www.rfc-editor.org/info/rfc5
960" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.69 209" quoteTitle="true" derivedAnchor="RFC5209">
60.xml"> <front>
<title>Network Endpoint Assessment (NEA): Overview and Requirements<
/title>
<author initials="P." surname="Sangster" fullname="P. Sangster">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Khosravi" fullname="H. Khosravi">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Mani" fullname="M. Mani">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Narayan" fullname="K. Narayan">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Tardo" fullname="J. Tardo">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="June"/>
<abstract>
<t indent="0">This document defines the problem statement, scope,
and protocol requirements between the components of the NEA (Network Endpoint As
sessment) reference model. NEA provides owners of networks (e.g., an enterprise
offering remote access) a mechanism to evaluate the posture of a system. This
may take place during the request for network access and/or subsequently at any
time while connected to the network. The learned posture information can then b
e applied to a variety of compliance-oriented decisions. The posture informatio
n is frequently useful for detecting systems that are lacking or have out-of-dat
e security protection mechanisms such as: anti-virus and host-based firewall sof
tware. In order to provide context for the requirements, a reference model and
terminology are introduced. This memo provides information for the Internet com
munity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5209"/>
<seriesInfo name="DOI" value="10.17487/RFC5209"/>
</reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
960" quoteTitle="true" derivedAnchor="RFC6960">
<front> <front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S tatus Protocol - OCSP</title> <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"> <author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Myers" fullname="M. Myers"> <author initials="M." surname="Myers" fullname="M. Myers">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="R." surname="Ankney" fullname="R. Ankney"> <author initials="R." surname="Ankney" fullname="R. Ankney">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="A." surname="Malpani" fullname="A. Malpani"> <author initials="A." surname="Malpani" fullname="A. Malpani">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S." surname="Galperin" fullname="S. Galperin"> <author initials="S." surname="Galperin" fullname="S. Galperin">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="C." surname="Adams" fullname="C. Adams"> <author initials="C." surname="Adams" fullname="C. Adams">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="June"/> <date year="2013" month="June"/>
<abstract> <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> <t indent="0">This document specifies a protocol useful in determi ning the current status of a digital certificate without requiring Certificate R evocation Lists (CRLs). Additional mechanisms addressing PKIX operational requir ements are specified in separate documents. This document obsoletes RFCs 2560 a nd 6277. It also updates RFC 5912.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6960"/>
<seriesInfo name="DOI" value="10.17487/RFC6960"/>
</reference> </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"> <reference anchor="RFC6961" target="https://www.rfc-editor.org/info/rfc6 961" quoteTitle="true" derivedAnchor="RFC6961">
<front> <front>
<title>The Transport Layer Security (TLS) Multiple Certificate Statu s Request Extension</title> <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"> <author initials="Y." surname="Pettersen" fullname="Y. Pettersen">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="June"/> <date year="2013" month="June"/>
<abstract> <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> <t indent="0">This document defines the Transport Layer Security ( TLS) Certificate Status Version 2 Extension to allow clients to specify and supp ort several certificate status methods. (The use of the Certificate Status exte nsion is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6961"/>
<seriesInfo name="DOI" value="10.17487/RFC6961"/>
</reference> </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"> <reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7 228" quoteTitle="true" derivedAnchor="RFC7228">
<front> <front>
<title>YANG Tree Diagrams</title> <title>Terminology for Constrained-Node Networks</title>
<seriesInfo name="DOI" value="10.17487/RFC8340"/> <author initials="C." surname="Bormann" fullname="C. Bormann">
<seriesInfo name="RFC" value="8340"/> <organization showOnFrontPage="true"/>
<seriesInfo name="BCP" value="215"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author> </author>
<author initials="L." surname="Berger" fullname="L. Berger" role="ed <author initials="M." surname="Ersue" fullname="M. Ersue">
itor"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<date year="2018" month="March"/> <author initials="A." surname="Keranen" fullname="A. Keranen">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="May"/>
<abstract> <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> <t indent="0">The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources , creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node net works.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7228"/>
<seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference> </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"> <reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7 258" quoteTitle="true" derivedAnchor="RFC7258">
<front> <front>
<title>EST over secure CoAP (EST-coaps)</title> <title>Pervasive Monitoring Is an Attack</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-coap-est-18" <author initials="S." surname="Farrell" fullname="S. Farrell">
/> <organization showOnFrontPage="true"/>
<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>
<author initials="S" surname="Raza" fullname="Shahid Raza"> <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date month="January" day="6" year="2020"/> <date year="2014" month="May"/>
<abstract> <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> <t indent="0">Pervasive monitoring is a technical attack that shou ld be mitigated in the design of IETF protocols, where possible.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="188"/>
<seriesInfo name="RFC" value="7258"/>
<seriesInfo name="DOI" value="10.17487/RFC7258"/>
</reference> </reference>
<!-- not referenced anymore: <?rfc <reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7
include="reference.I-D.ietf-anima-stable-connectivity" ?> --> 435" quoteTitle="true" derivedAnchor="RFC7435">
<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> <front>
<title>Considerations for stateful vs stateless join router in ANIMA <title>Opportunistic Security: Some Protection Most of the Time</tit
bootstrap</title> le>
<seriesInfo name="Internet-Draft" value="draft-richardson-anima-stat <author initials="V." surname="Dukhovni" fullname="V. Dukhovni">
e-for-joinrouter-02"/> <organization showOnFrontPage="true"/>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization/>
</author> </author>
<date month="January" day="25" year="2018"/> <date year="2014" month="December"/>
<abstract> <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> <t indent="0">This document defines the concept "Opportunistic Sec urity" in the context of communications protocols. Protocol designs based on Op portunistic Security use encryption even when authentication is not available, a nd use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7435"/>
<seriesInfo name="DOI" value="10.17487/RFC7435"/>
</reference> </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"> <reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7 575" quoteTitle="true" derivedAnchor="RFC7575">
<front> <front>
<title>Constrained Voucher Artifacts for Bootstrapping Protocols</ti <title>Autonomic Networking: Definitions and Design Goals</title>
tle> <author initials="M." surname="Behringer" fullname="M. Behringer">
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constraine <organization showOnFrontPage="true"/>
d-voucher-08"/>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization/>
</author> </author>
<author initials="P" surname="Stok" fullname="Peter van der Stok"> <author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="P" surname="Kampanakis" fullname="Panos Kampanakis <author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<date month="July" day="13" year="2020"/> <author initials="A." surname="Clemm" fullname="A. Clemm">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="June"/>
<abstract> <abstract>
<t>This document defines a strategy to securely assign a pledge to <t indent="0">Autonomic systems were first described in 2001. The
an owner, using an artifact signed, directly or indirectly, by the pledge's man fundamental goal is self-management, including self-configuration, self-optimiz
ufacturer. This artifact is known as a "voucher". This document builds upon th ation, self-healing, and self-protection. This is achieved by an autonomic func
e work in [RFC8366], encoding the resulting artifact in CBOR. Use with two sign tion having minimal dependencies on human administrators or centralized manageme
ature technologies are described. Additionally, this document explains how cons nt systems. It usually implies distribution across network elements.</t>
trained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-es <t indent="0">This document defines common language and outlines d
t] protocol.</t> esign goals (and what are not design goals) for autonomic functions. A high-lev
el reference model illustrates how functional elements in an Autonomic Network i
nteract. This document is a product of the IRTF's Network Management Research G
roup.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7575"/>
<seriesInfo name="DOI" value="10.17487/RFC7575"/>
</reference> </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"> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8 126" quoteTitle="true" derivedAnchor="RFC8126">
<front> <front>
<title>A YANG Data Model for a Keystore</title> <title>Guidelines for Writing an IANA Considerations Section in RFCs
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-keystore </title>
-19"/> <author initials="M." surname="Cotton" fullname="M. Cotton">
<author initials="K" surname="Watsen" fullname="Kent Watsen"> <organization showOnFrontPage="true"/>
<organization/>
</author> </author>
<date month="July" day="10" year="2020"/> <author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract> <abstract>
<t>This document defines a YANG 1.1 module called "ietf-keystore" <t indent="0">Many protocols make use of points of extensibility t
that enables centralized configuration of both symmetric and asymmetric keys. T hat use constants to identify various protocol parameters. To ensure that the v
he secret value for both key types may be encrypted. Asymmetric keys may be asso alues in these fields do not have conflicting uses and to promote interoperabili
ciated with certificates. Notifications are sent when certificates are about to ty, their allocations are often coordinated by a central record keeper. For IET
expire. Editorial Note (To be removed by RFC Editor) This draft contains plac F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
eholder values that need to be replaced with finalized values at the time of pub A).</t>
lication. This note summarizes all of the substitutions that are needed. No ot <t indent="0">To make assignments in a given registry prudently, g
her RFC Editor instructions are specified elsewhere in this document. Artwork i uidance describing the conditions under which new values should be assigned, as
n this document contains shorthand references to drafts in progress. Please app well as when and how modifications to existing values can be made, is needed. T
ly the following replacements: * "AAAA" --&gt; the assigned RFC value for draf his document defines a framework for the documentation of these guidelines by sp
t-ietf-netconf-crypto- types * "CCCC" --&gt; the assigned RFC value for this d ecification authors, in order to assure that the provided guidance for the IANA
raft Artwork in this document contains placeholder values for the date of publi Considerations is clear and addresses the various issues that are likely in the
cation of this draft. Please apply the following replacement: * "2020-07-10" operation of a registry.</t>
--&gt; the publication date of this draft The following Appendix section is to <t indent="0">This is the third edition of this document; it obsol
be removed prior to publication: * Appendix A. Change Log</t> etes RFC 5226.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference> </reference>
<!-- not referenced anywhere: <?rfc include="reference.RFC.8572" ?> --> <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340" quoteTitle="true" derivedAnchor="RFC8340">
<reference anchor="W3C.WD-capability-urls-20140218" target="http://www.w3.
org/TR/2014/WD-capability-urls-20140218" xml:base="https://xml2rfc.tools.ietf.or
g/public/rfc/bibxml4/reference.W3C.WD-capability-urls-20140218.xml">
<front> <front>
<title>Good Practices for Capability URLs</title> <title>YANG Tree Diagrams</title>
<seriesInfo name="World Wide Web Consortium WD" value="WD-capability <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
-urls-20140218"/> <organization showOnFrontPage="true"/>
<author initials="J." surname="Tennison" fullname="Jeni Tennison">
<organization/>
</author> </author>
<date month="February" day="18" year="2014"/> <author initials="L." surname="Berger" fullname="L. Berger" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document captures the current syntax used in YA
NG module tree diagrams. The purpose of this document is to provide a single lo
cation for this definition. This syntax may be updated from time to time based
on the evolution of the YANG language.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference> </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"> <reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8 615" quoteTitle="true" derivedAnchor="RFC8615">
<front> <front>
<title>Network Endpoint Assessment (NEA): Overview and Requirements< <title>Well-Known Uniform Resource Identifiers (URIs)</title>
/title> <author initials="M." surname="Nottingham" fullname="M. Nottingham">
<seriesInfo name="DOI" value="10.17487/RFC5209"/> <organization showOnFrontPage="true"/>
<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> </author>
<date year="2008" month="June"/> <date year="2019" month="May"/>
<abstract> <abstract>
<t>This document defines the problem statement, scope, and protoco <t indent="0">This memo defines a path prefix for "well-known loca
l requirements between the components of the NEA (Network Endpoint Assessment) r tions", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.<
eference model. NEA provides owners of networks (e.g., an enterprise offering r /t>
emote access) a mechanism to evaluate the posture of a system. This may take pl <t indent="0">In doing so, it obsoletes RFC 5785 and updates the U
ace during the request for network access and/or subsequently at any time while RI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595
connected to the network. The learned posture information can then be applied t to track URI schemes that support well-known URIs in their registry.</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> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8615"/>
<seriesInfo name="DOI" value="10.17487/RFC8615"/>
</reference> </reference>
<reference anchor="docsisroot" target="https://www.cablelabs.com/resourc es/digital-certificate-issuance-service/"> <reference anchor="RFC8993" target="https://www.rfc-editor.org/info/rfc8 993" quoteTitle="true" derivedAnchor="RFC8993">
<front> <front>
<title>CableLabs Digital Certificate Issuance Service</title> <title>A Reference Model for Autonomic Networking</title>
<author surname="CableLabs"/> <author initials="M" surname="Behringer" fullname="Michael Behringer
<date month="February" year="2018"/> " role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization showOnFrontPage="true"/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia
">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Nobre" fullname="Jeferson Nobre">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2021"/>
</front> </front>
<seriesInfo name="RFC" value="8993"/>
<seriesInfo name="DOI" value="10.17487/RFC8993"/>
</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/" quoteTitle="true" derivedAnchor="slowloris">
<front> <front>
<title>Slowloris (computer security)</title> <title>Slowloris (computer security)</title>
<author surname="Wikipedia"/> <author>
<date month="February" year="2019"/> <organization showOnFrontPage="true">Wikipedia</organization>
</front> </author>
</reference> <date month="January" year="2021"/>
<reference anchor="openssl" target="https://www.openssl.org/docs/man1.1.
1/man1/openssl-x509.html/">
<front>
<title>OpenSSL X509 utility</title>
<author surname="Openssl"/>
<date month="September" year="2019"/>
</front>
</reference>
<reference anchor="TR069" target="https://www.broadband-forum.org/standa
rds-and-software/technical-specifications/tr-069-files-tools">
<front>
<title>TR-69: CPE WAN Management Protocol</title>
<author surname="Broadband Forum"/>
<date month="February" year="2018"/>
</front>
</reference>
<reference anchor="imprinting" target="https://en.wikipedia.org/wiki/Imp
rinting_(psychology)">
<front>
<title>Wikipedia article: Imprinting</title>
<author surname="Wikipedia"/>
<date month="July" year="2015"/>
</front>
</reference>
<reference anchor="softwareescrow" target="https://en.wikipedia.org/wiki
/Source_code_escrow">
<front>
<title>Wikipedia article: Software Escrow</title>
<author surname="Wikipedia"/>
<date month="October" year="2019"/>
</front>
</reference>
<reference anchor="IoTstrangeThings" target="https://www.welivesecurity.
com/2017/03/03/internet-of-things-security-privacy-iot-update/">
<front>
<title>IoT of toys stranger than fiction: Cybersecurity and data
privacy update (accessed 2018-12-02)</title>
<author surname="Internet"/>
<date month="March" year="2017"/>
</front>
</reference>
<reference anchor="livingwithIoT" target="https://www.siliconrepublic.co
m/machines/iot-smart-devices-reality">
<front>
<title>What is it actually like to live in a house filled with IoT
devices? (accessed 2018-12-02)</title>
<author surname="Internet"/>
<date month="February" year="2018"/>
</front>
</reference>
<reference anchor="brewski" target="https://www.urbandictionary.com/defi
ne.php?term=brewski">
<front>
<title>Urban Dictionary: Brewski</title>
<author surname="Internet"/>
<date month="October" year="2019"/>
</front>
</reference>
<reference anchor="cabforumaudit" target="https://cabforum.org/informati
on-for-auditors-and-assessors/">
<front>
<title>Information for Auditors and Assessors</title>
<author surname="CA/Browser Forum"/>
<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="softwareescrow" target="https://en.wikipedia.org/w/in dex.php?title=Source_code_escrow&amp;oldid=948073074" quoteTitle="true" derivedA nchor="softwareescrow">
<front> <front>
<title>DNSSEC Practice Statement for the Root Zone ZSK Operator</tit <title>Source code escrow</title>
le> <author>
<author surname="Verisign"/> <organization showOnFrontPage="true">Wikipedia</organization>
<date month="December" year="2017"/> </author>
<date month="March" year="2020"/>
</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" quoteTitle="true" derivedAncho r="Stajano99theresurrecting">
<front> <front>
<title>The resurrecting duckling: security issues for ad-hoc <title>The Resurrecting Duckling: Security Issues for Ad-hoc Wireles
wireless networks</title> s 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="TR069" target="https://www.broadband-forum.org/downlo ad/TR-069_Amendment-6.pdf" quoteTitle="true" derivedAnchor="TR069">
<front> <front>
<title>Minerva reference implementation for BRSKI</title> <title>CPE WAN Management Protocol</title>
<author fullname="Michael Richardson" initials="M." surname="Richard <author>
sdon"/> <organization showOnFrontPage="true">Broadband Forum</organization
<date year="2020"/> >
</author>
<date month="March" year="2018"/>
</front> </front>
<refcontent>TR-069, Issue 1, Amendment 6</refcontent>
</reference> </reference>
<reference anchor="minervagithub" target="https://github.com/ANIMAgus-mi nerva"> <reference anchor="W3C.capability-urls" target="https://www.w3.org/TR/20 14/WD-capability-urls" quoteTitle="true" derivedAnchor="W3C.capability-urls">
<front> <front>
<title>GITHUB hosting of Minerva reference code</title> <title>Good Practices for Capability URLs</title>
<author fullname="Michael Richardson" initials="M." surname="Richard <seriesInfo name="World Wide Web Consortium WD" value="WD-capability
sdon"/> -urls-20140218"/>
<date year="2020"/> <author initials="J." surname="Tennison" fullname="Jeni Tennison">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2014"/>
</front> </front>
<refcontent>W3C First Public Working Draft</refcontent>
</reference> </reference>
<reference anchor="Dingledine2004" target="https://spec.torproject.org/t or-spec"> <reference anchor="I-D.ietf-netconf-keystore" quoteTitle="true" target=" https://tools.ietf.org/html/draft-ietf-netconf-keystore-22" derivedAnchor="YANG- KEYSTORE">
<front> <front>
<title>Tor: the second-generation onion router</title> <title>A YANG Data Model for a Keystore</title>
<author initials="R." surname="Dingledine"> <author fullname="Kent Watsen">
<organization/> <organization showOnFrontPage="true">Watsen Networks</organization
</author> >
<author initials="N." surname="Mathewson">
<organization/>
</author>
<author initials="P." surname="Syverson">
<organization/>
</author> </author>
<date year="2004"/> <date month="May" day="18" year="2021"/>
<abstract>
<t indent="0"> This document defines a YANG module called "ietf-
keystore" that
enables centralized configuration of both symmetric and asymmetric
keys. The secret value for both key types may be encrypted or
hidden. Asymmetric keys may be associated with certificates.
Notifications are sent when certificates are about to expire.
Editorial Note (To be removed by RFC Editor)
This draft contains placeholder values that need to be replaced with
finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.
Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
* "AAAA" --&gt; the assigned RFC value for draft-ietf-netconf-crypto-
types
* "CCCC" --&gt; the assigned RFC value for this draft
Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement:
* "2021-05-18" --&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> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-keystore-2
2"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
netconf-keystore-22.txt"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="IPv4operations" numbered="true" toc="default"> <section anchor="IPv4operations" numbered="true" toc="include" removeInRFC="
<name>IPv4 and non-ANI operations</name> false" pn="section-appendix.a">
<t> <name slugifiedName="name-ipv4-and-non-ani-operations">IPv4 and Non-ANI Op
The specification of BRSKI in <xref target="proxydetails" format="defaul erations</name>
t"/> <t indent="0" pn="section-appendix.a-1">
intentionally only covers the mechanisms for an IPv6 pledge using The specification of BRSKI in <xref target="proxydetails" format="defaul
Link-Local addresses. This section describes non-normative t" sectionFormat="of" derivedContent="Section 4"/>
intentionally covers only the mechanisms for an IPv6 pledge using
link-local addresses. This section describes non-normative
extensions that can be used in other environments. extensions that can be used in other environments.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-a.1
<name>IPv4 Link Local addresses</name> ">
<t>Instead of an IPv6 link-local address, an IPv4 address may be <name slugifiedName="name-ipv4-link-local-addresses">IPv4 Link-Local Add
generated using <xref target="RFC3927" format="default"/> Dynamic Configu resses</name>
ration of <t indent="0" pn="section-a.1-1">Instead of an IPv6 link-local address,
IPv4 Link-Local Addresses. an IPv4 address may be
generated using "Dynamic Configuration of
IPv4 Link-Local Addresses" <xref target="RFC3927" format="default" section
Format="of" derivedContent="RFC3927"/>.
</t> </t>
<t> In the case that an IPv4 Link-Local address is formed, then the <t indent="0" pn="section-a.1-2"> In the case where an IPv4 link-local a
bootstrap process would continue as in the IPv6 case by looking for ddress is formed, the
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="include" removeInRFC="fals
<name>Use of DHCPv4</name> e" pn="section-a.2">
<t> <name slugifiedName="name-use-of-dhcpv4">Use of DHCPv4</name>
The Pledge MAY obtain an IP address via <t indent="0" pn="section-a.2-1">
DHCP [RFC2131]. The DHCP provided parameters for the Domain Name The pledge <bcp14>MAY</bcp14> obtain an IP address via
DHCP (<xref target="RFC2131" format="default" sectionFormat="of" derived
Content="RFC2131"/>. The DHCP-provided parameters 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="include" removeInRFC="fal
<name>mDNS / DNSSD proxy discovery options</name> se" pn="section-appendix.b">
<t>Pledge discovery of the proxy (<xref target="discovery" format="default <name slugifiedName="name-mdns-dns-sd-proxy-discovery">mDNS / DNS-SD Proxy
"/>) MAY be performed with DNS-based Service Discovery <xref target="RFC6763" fo Discovery Options</name>
rmat="default"/> over Multicast DNS <xref target="RFC6762" format="default"/> to <t indent="0" pn="section-appendix.b-1">Pledge discovery of the proxy (<xr
discover the proxy at ef target="discovery" format="default" sectionFormat="of" derivedContent="Sectio
n 4.1"/>) <bcp14>MAY</bcp14> be performed with DNS-based Service Discovery <xref
target="RFC6763" format="default" sectionFormat="of" derivedContent="RFC6763"/>
over Multicast DNS <xref target="RFC6762" format="default" sectionFormat="of" d
erivedContent="RFC6762"/> 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 indent="0" pn="section-appendix.b-2">Proxy discovery of the registrar ( <xref target="JRCgrasp" format="default" sectionFormat="of" derivedContent="Sect ion 4.3"/>) <bcp14>MAY</bcp14> be performed with DNS-based Service Discovery ove r Multicast DNS to discover registrars by searching for the service
"_brski-registrar._tcp.local.".</t> "_brski-registrar._tcp.local.".</t>
<t> <t indent="0" pn="section-appendix.b-3">
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" format="default
e " derivedLink="https://rfc-editor.org/rfc/rfc6762#section-7" derivedContent="RFC
pledge SHOULD listen for an unsolicited broadcast response as 6762"/> <bcp14>MUST</bcp14> be followed. The
described in <xref target="RFC6762" format="default"/>. This allows devi pledge <bcp14>SHOULD</bcp14> listen for an unsolicited broadcast respons
ces e as
described in <xref target="RFC6762" format="default" sectionFormat="of"
derivedContent="RFC6762"/>. This allows devices
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 indent="0" pn="section-appendix.b-4">
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" secti
onFormat="comma" section="11" format="default" derivedLink="https://rfc-editor.o
rg/rfc/rfc6763#section-11" derivedContent="RFC6763"/> (<xref target="IPv4dhcp" f
ormat="default" sectionFormat="of" derivedContent="Appendix A.2"/> of this docum
ent
suggests the use of DHCP parameters). suggests the use of DHCP parameters).
</t> </t>
<t> <t indent="0" pn="section-appendix.b-5">
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" sectionFormat="o f" derivedContent="Section 2.7"/>.
</t> </t>
<t> <t indent="0" pn="section-appendix.b-6">
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="include" removeInRFC="false" pn="section-appen
<name>Example Vouchers</name> dix.c">
<t> <name slugifiedName="name-example-vouchers">Example Vouchers</name>
<t indent="0" pn="section-appendix.c-1">
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 indent="0" pn="section-appendix.c-2">
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" sectionFormat="
It is available on github <xref target="minervagithub" format="default"/ of" derivedContent="minerva"/>.
>. It is available on GitHub <xref target="minervagithub" format="default"
sectionFormat="of" derivedContent="minervagithub"/>.
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 indent="0" pn="section-appendix.c-3">
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" sectionFormat="of" derivedContent="openssl"/>.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-c.1
<name>Keys involved</name> ">
<t> <name slugifiedName="name-keys-involved">Keys Involved</name>
The Manufacturer has a Certificate Authority that signs the <t indent="0" pn="section-c.1-1">
pledge's IDevID. In addition the Manufacturer's signing authority The manufacturer has a CA that signs the
pledge's IDevID. In addition, the Manufacturer's signing authority
(the MASA) signs the vouchers, and that certificate must (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="include" removeInRFC="false" pn="section-c
<name>Manufacturer Certificate Authority for IDevID signatures</name> .1.1">
<t> <name slugifiedName="name-manufacturer-certification-">Manufacturer Ce
This private key is Certificate Authority that signs IDevID certific rtification Authority for IDevID Signatures</name>
ates: <t indent="0" pn="section-c.1.1-1">
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" pn="section-c.1.1 -2">
-----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 indent="0" keepWithNext="true" pn="section-c.1.1-3">
This public key validates IDevID certificates: This public key validates IDevID certificates:
</t> </t>
<t keepWithPrevious="true">file: examples/vendor.key</t> <t indent="0" pn="section-c.1.1-4">file: examples/vendor.key</t>
<sourcecode name="vendor.cert" type="" markers="true"><![CDATA[ <sourcecode name="vendor.cert" type="example-crypto-material" markers=
"true" pn="section-c.1.1-5">
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="include" removeInRFC="false" pn="section-c
<name>MASA key pair for voucher signatures</name> .1.2">
<t> <name slugifiedName="name-masa-key-pair-for-voucher-s">MASA Key Pair f
or Voucher Signatures</name>
<t indent="0" pn="section-c.1.2-1">
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" sectionFormat="of" derivedContent="Section 5.
s not provided as it is a 4"/>)
HTTP authentication is not provided as it is a
common form. common form.
</t> </t>
<t> <t indent="0" pn="section-c.1.2-2">
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" pn="section-c.1.2-3">
-----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 indent="0" keepWithNext="true" pn="section-c.1.2-4">
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 indent="0" pn="section-c.1.2-5">file: examples/masa.key</t>
<sourcecode name="masa.cert" type="" markers="true"><![CDATA[ <sourcecode name="masa.cert" type="example-crypto-material" markers="t
rue" pn="section-c.1.2-6">
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="include" removeInRFC="false" pn="section-c
<name>Registrar Certificate Authority</name> .1.3">
<t> <name slugifiedName="name-registrar-certification-aut">Registrar Certi
This Certificate Authority enrolls the pledge once it is fication Authority</name>
authorized, and it also signs the Registrar's certificate. <t indent="0" pn="section-c.1.3-1">
This CA enrolls the pledge once it is
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" pn="section-c.1.3-2">
-----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 indent="0" keepWithNext="true" pn="section-c.1.3-3">
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 indent="0" pn="section-c.1.3-4">file: examples/ownerca_secp384r1.ke
<sourcecode name="ownerca_secp384r1.cert" type="" markers="true"><![CD y</t>
ATA[ <sourcecode name="ownerca_secp384r1.cert" type="example-crypto-materia
l" markers="true" pn="section-c.1.3-5">
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 6218 skipping to change at line 6895
FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRh FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRh
aW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMHYw aW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMHYw
EAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYikb23VoAH EAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYikb23VoAH
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="include" removeInRFC="false" pn="section-c
<name>Registrar key pair</name> .1.4">
<t> <name slugifiedName="name-registrar-key-pair">Registrar Key Pair</name
The Registrar is the representative of the domain owner. >
This key signs registrar voucher-requests, and terminates <t indent="0" pn="section-c.1.4-1">
The registrar is the representative of the domain owner.
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" pn="section-c.1.4-2">
-----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 indent="0" pn="section-c.1.4-3">
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" pn="section-c.1.4-4">
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 6284 skipping to change at line 6963
YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe
Fw0yMDAyMjUyMTMxNTRaFw0yMjAyMjQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZ Fw0yMDAyMjUyMTMxNTRaFw0yMjAyMjQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZ
FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRh FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRh
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="include" removeInRFC="false" pn="section-c
<name>Pledge key pair</name> .1.5">
<t> <name slugifiedName="name-pledge-key-pair">Pledge Key Pair</name>
<t indent="0" pn="section-c.1.5-1">
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" pn="section-c.1.5-2">
-----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 indent="0" pn="section-c.1.5-3">
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" pn="section-c.1.5-4">
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="include" removeInRFC
<name>Example process</name> ="false" pn="section-c.2">
<t> <name slugifiedName="name-example-process">Example Process</name>
<t indent="0" pn="section-c.2-1">
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 indent="0" pn="section-c.2-2">
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="include" removeInRFC="false" pn="section-c
<name>Pledge to Registrar</name> .2.1">
<t> <name slugifiedName="name-pledge-to-registrar">Pledge to Registrar</na
As described in <xref target="RequestVoucherFromRegistrar" format="d me>
efault"/>, <t indent="0" pn="section-c.2.1-1">
As described in <xref target="RequestVoucherFromRegistrar" format="d
efault" sectionFormat="of" derivedContent="Section 5.2"/>,
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"><![ <sourcecode name="vr_00-D0-E5-F2-00-02.b64" type="" markers="true" pn=
CDATA[ "section-c.2.1-2">
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
]]></sourcecode> MEUCIQCmYuCE61HFQXH/E16GDOCsVquDtgr+Q/6/Du/9QkzA7gIgf7MFhAIPW2PNwRa2
<t> vZFQAKXUbimkiHKzXBA8md0VHbU=
</sourcecode>
<t indent="0" keepWithNext="true" pn="section-c.2.1-3">
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 indent="0" pn="section-c.2.1-4">file: examples/vr_00-D0-E5-F2-00-02
<artwork name="" type="" align="left" alt=""><![CDATA[ .b64</t>
0:d=0 hl=4 l=1759 cons: SEQUENCE <artwork name="" type="" align="left" alt="" pn="section-c.2.1-5">
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 </artwork>
1516:d=8 hl=2 l= 34 cons: SEQUENCE <t indent="0" pn="section-c.2.1-6">
1518:d=9 hl=2 l= 3 prim: OBJECT :commonName The JSON contained in the voucher-request:
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>
<t>
The JSON contained in the voucher request:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json" markers="false" pn="section-c.2.1-7">
{"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="include" removeInRFC="false" pn="section-c
<name>Registrar to MASA</name> .2.2">
<t> <name slugifiedName="name-registrar-to-masa">Registrar to MASA</name>
As described in <xref target="RequestVoucherFromMASA" format="defaul <t indent="0" pn="section-c.2.2-1">
t"/> As described in <xref target="RequestVoucherFromMASA" format="defaul
the registrar will sign a registrar voucher-request, and will t" sectionFormat="of" derivedContent="Section 5.5"/>,
include pledge's voucher request in the prior-signed-voucher-request the registrar will sign a registrar voucher-request and will
. 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= <sourcecode name="parboiled_vr_00-D0-E5-F2-00-02.b64" type="" markers=
"true"><![CDATA[ "true" pn="section-c.2.2-2">
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
]]></sourcecode> MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFp
<t> biBSb290IENBAgQ/mJtSMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQxMzIxNDMyM1owLwYJKoZIhvcNAQkEMSIE
IEnOrdWjlG70K74IhCJ7UXi+wPS+r2C8DFEqjabGP+G8MAoGCCqGSM49BAMCBEcwRQIh
AMhO3M+tSWb2wKTBOXPArN+XvjSzAhaQA/uLj3qhPwi/AiBDDthf6mjMuirqXE0yjMif
C2UY9oNUFF9Nl0wEQpBBAA==
</sourcecode>
<t indent="0" keepWithNext="true" pn="section-c.2.2-3">
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- <t indent="0" pn="section-c.2.2-4">file: examples/parboiled_vr_00_D0-E
2D.b64</t> 5-02-00-2D.b64</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-c.2.2-5">
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>
<t> </artwork>
The JSON contained in the voucher request. Note that the previous <t indent="0" pn="section-c.2.2-6">
voucher request is in the prior-signed-voucher-request attribute. The JSON contained in the voucher-request. Note that the previous
voucher-request is in the prior-signed-voucher-request attribute.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="json" markers="false" pn="section-c.2.2-7">
{"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="include" removeInRFC="false" pn="section-c
<name>MASA to Registrar</name> .2.3">
<t> <name slugifiedName="name-masa-to-registrar">MASA to Registrar</name>
The MASA will return a voucher to the registrar, to be relayed to <t indent="0" pn="section-c.2.3-1">
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 <sourcecode name="voucher_00-D0-E5-F2-00-02.b64" type="" markers="true
"><![CDATA[ " pn="section-c.2.3-2">
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 indent="0" keepWithNext="true" pn="section-c.2.3-3">
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 <t indent="0" pn="section-c.2.3-4">file: examples/voucher_00-D0-E5-F2-
4</t> 00-02.b64</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-c.2.3-5">
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="include" removeInRFC="false" pn="section-
1444:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada c.2.4">
1452:d=7 hl=2 l= 16 cons: SET <name slugifiedName="name-acknowledgements">Acknowledgements</name>
1454:d=8 hl=2 l= 14 cons: SEQUENCE <t indent="0" pn="section-c.2.4-1">We would like to thank the various
1456:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName reviewers for their input, in
1461:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario particular
1470:d=7 hl=2 l= 18 cons: SET <contact fullname="William Atwood"/>,
1472:d=8 hl=2 l= 16 cons: SEQUENCE <contact fullname="Brian Carpenter"/>,
1474:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName <contact fullname="Fuyu Eleven"/>,
1479:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman <contact fullname="Eliot Lear"/>,
1490:d=7 hl=2 l= 36 cons: SET <contact fullname="Sergey Kasatkin"/>,
1492:d=8 hl=2 l= 34 cons: SEQUENCE <contact fullname="Anoop Kumar"/>,
1494:d=9 hl=2 l= 3 prim: OBJECT :commonName <contact fullname="Tom Petch"/>,
1499:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com <contact fullname="Markus Stenberg"/>,
1528:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 <contact fullname="Peter van der Stok"/>,
1534:d=5 hl=2 l= 11 cons: SEQUENCE and
1536:d=6 hl=2 l= 9 prim: OBJECT :sha256 <contact fullname="Thomas Werner"/>.
1547:d=5 hl=2 l= 105 cons: cont [ 0 ] </t>
1549:d=6 hl=2 l= 24 cons: SEQUENCE <t indent="0" pn="section-c.2.4-2">
1551:d=7 hl=2 l= 9 prim: OBJECT :contentType Significant reviews were done by <contact fullname="Jari Arkko"/>,
1562:d=7 hl=2 l= 11 cons: SET <contact fullname="Christian Huitema"/>, and <contact fullname="Russ Housley"/>.
1564:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data </t>
1575:d=6 hl=2 l= 28 cons: SEQUENCE <t indent="0" pn="section-c.2.4-3">
1577:d=7 hl=2 l= 9 prim: OBJECT :signingTime <contact fullname="Henk Birkholz"/> contributed the CDDL for the audit-l
1588:d=7 hl=2 l= 15 cons: SET og response.
1590:d=8 hl=2 l= 13 prim: UTCTIME :200225230449Z </t>
1605:d=6 hl=2 l= 47 cons: SEQUENCE <t indent="0" pn="section-c.2.4-4">
1607:d=7 hl=2 l= 9 prim: OBJECT :messageDigest This document started its life as a two-page idea from <contact fullname
1618:d=7 hl=2 l= 34 cons: SET ="Steinthor Bjarnason"/>.
1620:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:8942CA3867D9AC </t>
1654:d=5 hl=2 l= 10 cons: SEQUENCE <t indent="0" pn="section-c.2.4-5">
1656:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 In addition, significant review comments were provided by many IESG
1666:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450221008A11 members, including <contact fullname="Adam Roach"/>, <contact fullname="
]]></artwork> Alexey Melnikov"/>, <contact fullname="Alissa Cooper"/>, <contact fullname="Benj
amin Kaduk"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyl
iw"/>, and <contact fullname="Magnus Westerlund"/>.
</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<name>Additional References</name> ="include" pn="section-appendix.d">
<t> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
RFC EDITOR Please remove this section before publication. <author fullname="Max Pritikin" initials="M." surname="Pritikin">
It exists just to include <organization showOnFrontPage="true">Cisco</organization>
references to the things in the YANG descriptions which are not <address>
otherwise referenced in the text so that xml2rfc will not complain. <email>pritikin@cisco.com</email>
</t> </address>
<t> </author>
<xref target="ITU.X690.1994" format="default"/> <author fullname="Michael C. Richardson" initials="M." surname="Richardson
</t> ">
<organization abbrev="Sandelman Software Works" showOnFrontPage="true">S
andelman Software Works</organization>
<address>
<email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/</uri>
</address>
</author>
<author fullname="Toerless Eckert" initials="T." surname="Eckert">
<organization abbrev="Futurewei USA" showOnFrontPage="true">Futurewei Te
chnologies Inc. USA</organization>
<address>
<postal>
<street>2330 Central Expy</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<email>tte+ietf@cs.fau.de</email>
</address>
</author>
<author fullname="Michael H. Behringer" initials="M." surname="Behringer">
<address>
<email>Michael.H.Behringer@gmail.com</email>
</address>
</author>
<author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization>
<address>
<email>kent+ietf@watsen.net</email>
</address>
</author>
</section> </section>
</back> </back>
</rfc> </rfc>
<!--
Local Variables:
mode: xml
End:
 End of changes. 1484 change blocks. 
4539 lines changed or deleted 6406 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/