rfc9646.original.xml   rfc9646.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes" ?> <!ENTITY nbhy "&#8209;">
<?rfc compact="yes"?> <!ENTITY wj "&#8288;">
<?rfc subcompact="no"?> ]>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc comments="yes" ?> std" consensus="true" docName="draft-ietf-netconf-sztp-csr-14" number="9646" ipr
<?rfc inline="yes"?> ="trust200902" updates="8572" obsoletes="" xml:lang="en" tocInclude="true" symRe
<?rfc rfcedstyle="yes"?> fs="true" sortRefs="true" version="3">
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
ipr="trust200902" docName="draft-ietf-netconf-sztp-csr-14" updates="8572" obsole
tes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sort
Refs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.45.3 --> <!-- xml2rfc v2v3 conversion 2.45.3 -->
<front> <front>
<title abbrev="Conveying a CSR in an SZTP Request">Conveying a Certificate S <title abbrev="Conveying a CSR in an SZTP Request">Conveying a Certificate S
igning Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Re igning Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Re
quest</title> quest</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-sztp-csr-14"/> <seriesInfo name="RFC" value="9646"/>
<author initials="K." surname="Watsen" fullname="Kent Watsen"> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Watsen Networks</organization> <organization>Watsen Networks</organization>
<address> <address>
<email>kent+ietf@watsen.net</email> <email>kent+ietf@watsen.net</email>
</address> </address>
</author> </author>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Turner" fullname="Sean Turner"> <author initials="S." surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization> <organization>sn3rd</organization>
<address> <address>
<email>sean@sn3rd.com</email> <email>sean@sn3rd.com</email>
</address> </address>
</author> </author>
<date/> <date year="2024" month="October"/>
<area>Operations</area> <area>ops</area>
<workgroup>NETCONF Working Group</workgroup> <workgroup>netconf</workgroup>
<keyword>zerotouch</keyword> <keyword>zerotouch</keyword>
<keyword>bootstrap</keyword> <keyword>bootstrap</keyword>
<keyword>sztp</keyword> <keyword>sztp</keyword>
<keyword>ztp</keyword> <keyword>ztp</keyword>
<keyword>csr</keyword> <keyword>csr</keyword>
<keyword>pkcs#10</keyword> <keyword>pkcs#10</keyword>
<keyword>p10</keyword> <keyword>p10</keyword>
<keyword>p10cr</keyword> <keyword>p10cr</keyword>
<keyword>cmc</keyword> <keyword>cmc</keyword>
<keyword>cmp</keyword> <keyword>cmp</keyword>
<abstract> <abstract>
<t>This draft extends the input to the "get-bootstrapping-data" RPC define d in <t>This document extends the input to the "get-bootstrapping-data" RPC def ined in
RFC 8572 to include an optional certificate signing request (CSR), RFC 8572 to include an optional certificate signing request (CSR),
enabling a bootstrapping device to additionally obtain an identity enabling a bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID from IEEE 802.1AR) as part of the certificate (e.g., a Local Device Identifier (LDevID) from IEEE 802. 1AR) as part of the
"onboarding information" response provided in the RPC-reply.</t> "onboarding information" response provided in the RPC-reply.</t>
</abstract> </abstract>
<note>
<name>Editorial Note (To be removed by RFC Editor)</name>
<t>This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note summarize
s
all of the substitutions that are needed. No other
RFC Editor instructions are specified elsewhere in this document.</t>
<t>Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
</t>
<ul spacing="normal">
<li>
<tt>XXXX</tt> --&gt; the assigned numerical RFC value for this draft</
li>
<li>
<tt>AAAA</tt> --&gt; the assigned RFC value for I-D.ietf-netconf-crypt
o-types</li>
</ul>
<t>Artwork in this document contains a placeholder value for the publicati
on date of this
draft. Please apply the following replacement:
</t>
<ul spacing="normal">
<li>
<tt>2022-03-02</tt> --&gt; the publication date of this draft</li>
</ul>
<t>This document contains references to other drafts in progress, both in
the Normative References section, as well as in body text throughout.
Please update the following references to reflect their final RFC assi
gnments:
</t>
<ul spacing="normal">
<li>I-D.ietf-netconf-crypto-types</li>
<li>I-D.ietf-netconf-keystore</li>
<li>I-D.ietf-netconf-trust-anchors</li>
</ul>
<!--
<t>The following one Appendix section is to be removed prior to public
ation:
<list style="symbols">
<t>Appendix A. Change Log</t>
</list>
</t>
-->
</note>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t>This draft extends the input to the "get-bootstrapping-data" RPC defi ned in <t>This document extends the input to the "get-bootstrapping-data" RPC d efined in
<xref target="RFC8572" format="default"/> to include an optional cer tificate <xref target="RFC8572" format="default"/> to include an optional cer tificate
signing request (CSR) <xref target="RFC2986" format="default"/>, ena bling a signing request (CSR) <xref target="RFC2986" format="default"/>, ena bling a
bootstrapping device to additionally obtain an identity bootstrapping device to additionally obtain an identity
certificate (e.g., an LDevID <xref target="Std-802.1AR-2018" format= "default"/>) certificate (e.g., an LDevID from <xref target="Std-802.1AR-2018" fo rmat="default"/>)
as part of the "onboarding information" response provided in as part of the "onboarding information" response provided in
the RPC-reply.</t> the RPC-reply.</t>
<t>The ability to provision an identity certificate that is purpose-buil t <t>The ability to provision an identity certificate that is purpose-buil t
for a production environment during the bootstrapping process for a production environment during the bootstrapping process
removes reliance on the manufacturer CA, and it also enables the removes reliance on the manufacturer Certification Authority (CA), a nd it also enables the
bootstrapped device to join the production environment with an bootstrapped device to join the production environment with an
appropriate identity and other attributes in its identity appropriate identity and other attributes in its identity
certificate (e.g., an LDevID).</t> certificate (e.g., an LDevID).</t>
<t>Two YANG <xref target="RFC7950" format="default"/> modules are define d. The <t>Two YANG <xref target="RFC7950" format="default"/> modules are define d. The
"ietf-ztp-types" module defines three YANG groupings for the "ietf-ztp-types" module defines three YANG groupings for the
various messages defined in this document. The "ietf-sztp-csr" various messages defined in this document. The "ietf-sztp-csr"
module augments two groupings into the "get-bootstrapping-data" module augments two groupings into the "get-bootstrapping-data"
RPC and defines a YANG Data Structure <xref target="RFC8791" format ="default"/> RPC and defines a YANG data structure <xref target="RFC8791" format ="default"/>
around the third grouping.</t> around the third grouping.</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>This document uses the following terms from <xref target="RFC8572" fo rmat="default"/>:</t> <t>This document uses the following terms from <xref target="RFC8572" fo rmat="default"/>:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>Bootstrap Server</li> <li>Bootstrap Server</li>
<li>Bootstrapping Data</li> <li>Bootstrapping Data</li>
<li>Conveyed Information</li> <li>Conveyed Information</li>
<li>Device</li> <li>Device</li>
<li>Manufacturer</li> <li>Manufacturer</li>
<li>Onboarding Information</li> <li>Onboarding Information</li>
<li>Signed Data</li> <li>Signed Data</li>
</ul> </ul>
<t>This document defines the following new terms:</t> <t>This document defines the following new terms:</t>
<!--<dl hanging="false"> FIXME: xml2rfc fails -->
<dl> <dl>
<dt>SZTP-client</dt> <dt>SZTP-client:</dt>
<dd>The term "SZTP-client" refers to a "device" that is using a <dd>The term "SZTP-client" refers to a "device" that is using a
"bootstrap server" as a source of "bootstrapping data".</dd> "bootstrap server" as a source of "bootstrapping data".</dd>
<dt>SZTP-server</dt> <dt>SZTP-server:</dt>
<dd>The term "SZTP-server" is an alternative term for "bootstrap <dd>The term "SZTP-server" is an alternative term for "bootstrap
server" that is symmetric with the "SZTP-client" term.</dd> server" that is symmetric with the "SZTP-client" term.</dd>
<!--
<list style="hanging" hangIndent="4">
<t hangText="SZTP-client:">The term "SZTP-client" refers
to a "device" that is using a "bootstrap server" as a
source of "bootstrapping data".</t>
<t hangText="SZTP-server:">The term "SZTP-server" refers
to a "bootstrap server".</t>
</list>
-->
</dl> </dl>
</section> </section>
<section anchor="requirements-language" numbered="true" toc="default"> <section anchor="requirements-language" numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "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
described in BCP 14 <xref target="RFC2119" format="default"/> <xref ta NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
rget="RFC8174" format="default"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions</name> <name>Conventions</name>
<t>Various examples used in this document use a placeholder <t>Various examples in this document use "BASE64VALUE=" as a placeholder
value for binary data that has been base64 encoded (e.g., value for binary data that has been base64 encoded (per <xref target
"BASE64VALUE="). This placeholder value is used as real ="RFC7950" sectionFormat="of" section="9.8"/>). This placeholder value is used
base64 encoded structures are often many lines long and because real
hence distracting to the example being presented.</t> base64-encoded structures are often many lines long and
hence distracting to the example being presented.</t>
<t> Various examples in this document contain long lines that may be fold
ed,
as described in <xref target="RFC8792"/>.</t>
</section> </section>
</section> </section>
<!-- end Introduction -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>The "ietf-sztp-csr" Module</name> <name>The "ietf-sztp-csr" Module</name>
<t>The "ietf-sztp-csr" module is a YANG 1.1 <xref target="RFC7950" format= "default"/> <t>The "ietf-sztp-csr" module is a YANG 1.1 <xref target="RFC7950" format= "default"/>
module that augments the "ietf-sztp-bootstrap-server" module defined i n module that augments the "ietf-sztp-bootstrap-server" module defined i n
<xref target="RFC8572" format="default"/> and defines a YANG "structur e" that is to be <xref target="RFC8572" format="default"/> and defines a YANG "structur e" that is to be
conveyed in the "error-info" node defined in <relref section="7.1" tar get="RFC8040"/>.</t> conveyed in the "error-info" node defined in <relref section="7.1" tar get="RFC8040"/>.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates the <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates the
"ietf-sztp-csr" module.</t> "ietf-sztp-csr" module.</t>
<artwork name="ietf-sztp-csr-tree.txt" type="" align="left" alt=""><![CD ATA[ <sourcecode type="yangtree" name="ietf-sztp-csr-tree.txt"><![CDATA[
module: ietf-sztp-csr module: ietf-sztp-csr
augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: augment /sztp-svr:get-bootstrapping-data/sztp-svr:input:
+---w (msg-type)? +---w (msg-type)?
+--:(csr-support) +--:(csr-support)
| +---w csr-support | +---w csr-support
| +---w key-generation! | +---w key-generation!
| | +---w supported-algorithms | | +---w supported-algorithms
| | +---w algorithm-identifier* binary | | +---w algorithm-identifier* binary
| +---w csr-generation | +---w csr-generation
skipping to change at line 215 skipping to change at line 162
+---w cmp-csr? binary +---w cmp-csr? binary
structure csr-request: structure csr-request:
+-- key-generation! +-- key-generation!
| +-- selected-algorithm | +-- selected-algorithm
| +-- algorithm-identifier binary | +-- algorithm-identifier binary
+-- csr-generation +-- csr-generation
| +-- selected-format | +-- selected-format
| +-- format-identifier identityref | +-- format-identifier identityref
+-- cert-req-info? ct:csr-info +-- cert-req-info? ct:csr-info
]]></artwork> ]]></sourcecode>
<t>The augmentation defines two kinds of <t>The augmentation defines two kinds of
parameters that an SZTP-client can send to an SZTP-server. The parameters that an SZTP-client can send to an SZTP-server. The
YANG structure defines one collection of parameters that an YANG structure defines one collection of parameters that an
SZTP-server can send to an SZTP-client.</t> SZTP-server can send to an SZTP-client.</t>
<t>In the order of their intended use:</t> <t>In the order of their intended use:</t>
<ul> <ol type="1">
<li>The "csr-support" node is used by the SZTP-client to signal <li>The SZTP-client sends a "csr-support" node, encoded in a first
to the SZTP-server that it supports the ability to generate CSRs. "get-bootstrapping-data" request to the SZTP-server, to indicate
This parameter conveys if the SZTP-client is able to generate a that it supports the ability to generate CSRs.
This input parameter conveys if the SZTP-client is able to generat
e a
new asymmetric key and, if so, which key algorithms it supports, new asymmetric key and, if so, which key algorithms it supports,
as well as conveys what kinds of CSR structures the SZTP-client as well as what kinds of CSR structures the SZTP-client
is able to generate.</li> is able to generate.</li>
<li>The "csr-request" structure is used by the SZTP-server to request <li>The SZTP-server responds with an error, containing the "csr-reques
t"
structure, to request
the SZTP-client to generate a CSR. This structure is used to the SZTP-client to generate a CSR. This structure is used to
select the key algorithm the SZTP-client should use to generate select the key algorithm the SZTP-client should use to generate
a new asymmetric key, if supported, the kind of CSR structure a new asymmetric key (if supported), the kind of CSR structure
the SZTP-client should generate and, optionally, the content for the SZTP-client should generate, and optionally the content for
the CSR itself.</li> the CSR itself.</li>
<li>The various "csr" nodes are used by the SZTP-client to communicate <li>The SZTP-client sends one of the "*-csr" nodes, encoded in a secon
a CSR to the SZTP-server.</li> d
</ul> "get-bootstrapping-data" request to the SZTP-server. This node
<aside> encodes the server-requested CSR.</li>
<t>No data model is defined enabling an SZTP-server to communicate <li>The SZTP-server responds with onboarding information to communicat
e
the signed certificate to the SZTP-client. How to do this is the signed certificate to the SZTP-client. How to do this is
discussed in <xref target="example-usage" format="default"/>.</t> discussed in <xref target="example-usage" format="default"/>.</li>
</aside> </ol>
<t>To further illustrate how the augmentation and structure defined <t>To further illustrate how the augmentation and structure defined
by the "ietf-sztp-csr" module are used, below are two additional by the "ietf-sztp-csr" module are used, below are two additional
tree diagrams showing these nodes placed where they are used.</t> tree diagrams showing these nodes placed where they are used.</t>
<t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates SZTP's <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates SZTP's
"get-bootstrapping-data" RPC with the augmentation in place.</t> "get-bootstrapping-data" RPC with the augmentation in place.</t>
<artwork name="ietf-sztp-csr-api-n-csr-tree.txt" type="" align="left" al t=""><![CDATA[ <sourcecode type="yangtree" name="ietf-sztp-csr-api-n-csr-tree.txt"><![C DATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
module: ietf-sztp-bootstrap-server module: ietf-sztp-bootstrap-server
rpcs: rpcs:
+---x get-bootstrapping-data +---x get-bootstrapping-data
+---w input +---w input
| +---w signed-data-preferred? empty | +---w signed-data-preferred? empty
| +---w hw-model? string | +---w hw-model? string
| +---w os-name? string | +---w os-name? string
skipping to change at line 284 skipping to change at line 233
| | +---w sztp-csr:p10-csr? ct:csr | | +---w sztp-csr:p10-csr? ct:csr
| +--:(sztp-csr:cmc-csr) | +--:(sztp-csr:cmc-csr)
| | +---w sztp-csr:cmc-csr? binary | | +---w sztp-csr:cmc-csr? binary
| +--:(sztp-csr:cmp-csr) | +--:(sztp-csr:cmp-csr)
| +---w sztp-csr:cmp-csr? binary | +---w sztp-csr:cmp-csr? binary
+--ro output +--ro output
+--ro reporting-level? enumeration {onboarding-server}? +--ro reporting-level? enumeration {onboarding-server}?
+--ro conveyed-information cms +--ro conveyed-information cms
+--ro owner-certificate? cms +--ro owner-certificate? cms
+--ro ownership-voucher? cms +--ro ownership-voucher? cms
]]></sourcecode>
]]></artwork>
<t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates RESTCONF's <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates RESTCONF's
"errors" RPC-reply message with the "csr-request" structure in place .</t> "errors" RPC-reply message with the "csr-request" structure in place .</t>
<artwork name="ietf-sztp-csr-errors-n-struct-tree.txt" type="" align="le ft" alt=""><![CDATA[ <sourcecode type="yangtree" name="ietf-sztp-csr-errors-n-struct-tree.txt "><![CDATA[
module: ietf-restconf module: ietf-restconf
+--ro errors +--ro errors
+--ro error* [] +--ro error* []
+--ro error-type enumeration +--ro error-type enumeration
+--ro error-tag string +--ro error-tag string
+--ro error-app-tag? string +--ro error-app-tag? string
+--ro error-path? instance-identifier +--ro error-path? instance-identifier
+--ro error-message? string +--ro error-message? string
+--ro error-info +--ro error-info
+--ro sztp-csr:csr-request +--ro sztp-csr:csr-request
+--ro sztp-csr:key-generation! +--ro sztp-csr:key-generation!
| +--ro sztp-csr:selected-algorithm | +--ro sztp-csr:selected-algorithm
| +--ro sztp-csr:algorithm-identifier binary | +--ro sztp-csr:algorithm-identifier binary
+--ro sztp-csr:csr-generation +--ro sztp-csr:csr-generation
| +--ro sztp-csr:selected-format | +--ro sztp-csr:selected-format
| +--ro sztp-csr:format-identifier identityref | +--ro sztp-csr:format-identifier identityref
+--ro sztp-csr:cert-req-info? ct:csr-info +--ro sztp-csr:cert-req-info? ct:csr-info
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="example-usage" numbered="true" toc="default"> <section anchor="example-usage" numbered="true" toc="default">
<name>Example Usage</name> <name>Example Usage</name>
<aside> <aside>
<t>The examples below are encoded using JSON, but they could <t>NOTE: The examples below are encoded using JSON, but they could
equally well be encoded using XML, as is supported by SZTP.</t> equally well be encoded using XML, as is supported by SZTP.</t>
</aside> </aside>
<t>An SZTP-client implementing this specification would signal <t>An SZTP-client implementing this specification would signal
to the bootstrap server its willingness to generate a CSR by to the bootstrap server its willingness to generate a CSR by
including the "csr-support" node in its "get-bootstrapping-data" including the "csr-support" node in its "get-bootstrapping-data"
RPC. In the example below, the SZTP-client additionally RPC. In the example below, the SZTP-client additionally
indicates that it is able to generate keys and provides indicates that it is able to generate keys and provides
a list of key algorithms it supports, as well as provide a list of key algorithms it supports, as well as provide
a list of certificate formats it supports.</t> a list of certificate formats it supports.</t>
<t keepWithNext="true">REQUEST</t> <t keepWithNext="true">REQUEST</t>
<artwork name="ex-api-gbd-without-csr-rpc.json" type="" align="left" alt =""><![CDATA[ <sourcecode type="json" name="ex-api-gbd-without-csr-rpc.json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1 ng-data HTTP/1.1
HOST: example.com HOST: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-sztp-bootstrap-server:input" : { "ietf-sztp-bootstrap-server:input" : {
"hw-model": "model-x", "hw-model": "model-x",
skipping to change at line 358 skipping to change at line 306
"format-identifier": [ "format-identifier": [
"ietf-ztp-types:p10-csr", "ietf-ztp-types:p10-csr",
"ietf-ztp-types:cmc-csr", "ietf-ztp-types:cmc-csr",
"ietf-ztp-types:cmp-csr" "ietf-ztp-types:cmp-csr"
] ]
} }
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t>Assuming the SZTP-server wishes to prompt the SZTP-client to <t>Assuming the SZTP-server wishes to prompt the SZTP-client to
provide a CSR, then it would respond with an HTTP 400 Bad Request provide a CSR, then it would respond with an HTTP 400 Bad Request
error code. In the example below, the SZTP-server specifies error code. In the example below, the SZTP-server specifies
that it wishes the SZTP-client to generate a key using a specific that it wishes the SZTP-client to generate a key using a specific
algorithm and generate a PKCS#10-based CSR containing specific algorithm and generate a PKCS#10-based CSR containing specific
content.</t> content.</t>
<t keepWithNext="true">RESPONSE</t> <t keepWithNext="true">RESPONSE</t>
<artwork name="ex-api-gbd-without-csr-rpc-reply.json" type="" align="lef t" alt=""><![CDATA[ <sourcecode type="json" name="ex-api-gbd-without-csr-rpc-reply.json"><![ CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Date: Sat, 31 Oct 2021 17:02:40 GMT Date: Sat, 31 Oct 2021 17:02:40 GMT
Server: example-server Server: example-server
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-restconf:errors" : { "ietf-restconf:errors" : {
"error" : [ "error" : [
{ {
"error-type": "application", "error-type": "application",
skipping to change at line 398 skipping to change at line 346
"format-identifier": "ietf-ztp-types:p10-csr" "format-identifier": "ietf-ztp-types:p10-csr"
} }
}, },
"cert-req-info": "BASE64VALUE=" "cert-req-info": "BASE64VALUE="
} }
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
<t>Upon being prompted to provide a CSR, the SZTP-client would <t>Upon being prompted to provide a CSR, the SZTP-client would
POST another "get-bootstrapping-data" request, but this time POST another "get-bootstrapping-data" request but this time
including one of the "csr" nodes to convey its CSR to the including one of the "csr" nodes to convey its CSR to the
SZTP-server:</t> SZTP-server:</t>
<t keepWithNext="true">REQUEST</t> <t keepWithNext="true">REQUEST</t>
<artwork name="ex-api-gbd-with-csr-rpc.json" type="" align="left" alt="" ><![CDATA[ <sourcecode type="json" name="ex-api-gbd-with-csr-rpc.json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\
ng-data HTTP/1.1 ng-data HTTP/1.1
HOST: example.com HOST: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-sztp-bootstrap-server:input" : { "ietf-sztp-bootstrap-server:input" : {
"hw-model": "model-x", "hw-model": "model-x",
"os-name": "vendor-os", "os-name": "vendor-os",
"os-version": "17.3R2.1", "os-version": "17.3R2.1",
"nonce": "extralongbase64encodedvalue=", "nonce": "extralongbase64encodedvalue=",
"ietf-sztp-csr:p10-csr": "BASE64VALUE=" "ietf-sztp-csr:p10-csr": "BASE64VALUE="
} }
} }
]]></artwork> ]]></sourcecode>
<t>At this point, it is expected that the SZTP-server, perhaps <t>At this point, it is expected that the SZTP-server, perhaps
in conjunction with other systems, such as a backend CA or RA, in conjunction with other systems, such as a backend CA or registrat ion authority (RA),
will validate the CSR's origin and proof-of-possession and, will validate the CSR's origin and proof-of-possession and,
assuming the CSR is approved, issue a signed certificate for assuming the CSR is approved, issue a signed certificate for
the bootstrapping device.</t> the bootstrapping device.</t>
<t>The SZTP-server responds with "onboarding-information" (encoded <t>The SZTP-server responds with conveyed information
inside the "conveyed-information" node, shown below) containing (the "conveyed-information" node shown below) that encodes
"onboarding-information" (inside the base64 value) containing
a signed identity certificate for the CSR provided by the a signed identity certificate for the CSR provided by the
SZTP-client:</t> SZTP-client:</t>
<t keepWithNext="true">RESPONSE</t> <t keepWithNext="true">RESPONSE</t>
<artwork name="ex-api-gbd-with-csr-rpc-reply.json" type="" align="left" alt=""><![CDATA[ <sourcecode type="json" name="ex-api-gbd-with-csr-rpc-reply.json"><![CDA TA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Sat, 31 Oct 2021 17:02:40 GMT Date: Sat, 31 Oct 2021 17:02:40 GMT
Server: example-server Server: example-server
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-sztp-bootstrap-server:output" : { "ietf-sztp-bootstrap-server:output" : {
"reporting-level": "verbose", "reporting-level": "verbose",
"conveyed-information": "BASE64VALUE=" "conveyed-information": "BASE64VALUE="
} }
} }
]]></artwork> ]]></sourcecode>
<t>How the signed certificate is conveyed inside the onboarding informat ion <t>How the signed certificate is conveyed inside the onboarding informat ion
is outside the scope of this document. Some implementations may cho ose is outside the scope of this document. Some implementations may cho ose
to convey it inside a script (e.g., SZTP's "pre-configuration-script "), to convey it inside a script (e.g., SZTP's "pre-configuration-script "),
while other implementations may choose to convey it inside the SZTP while other implementations may choose to convey it inside the SZTP
"configuration" node. SZTP onboarding information is described in "configuration" node. SZTP onboarding information is described in
<relref section="2.2" target="RFC8572"/>.</t> <relref section="2.2" target="RFC8572"/>.</t>
<t>Below are two examples of conveying the signed certificate inside <t>Below are two examples of conveying the signed certificate inside
the "configuration" node. Both examples assume that the SZTP-client the "configuration" node. Both examples assume that the SZTP-client
understands the "ietf-keystore" module defined in understands the "ietf-keystore" module defined in
<xref target="I-D.ietf-netconf-keystore" format="default"/>.</t> <xref target="RFC9642" format="default"/>.</t>
<t>This first example illustrates the case where the signed certificate is <t>This first example illustrates the case where the signed certificate is
for the same asymmetric key used by the SZTP-client's manufacturer-g enerated for the same asymmetric key used by the SZTP-client's manufacturer-g enerated
identity certificate (e.g., an IDevID, from <xref target="Std-802.1A R-2018" format="default"/>). identity certificate (e.g., an Initial Device Identifier (IDevID) fr om <xref target="Std-802.1AR-2018" format="default"/>).
As such, the configuration needs to associate the newly signed certi ficate As such, the configuration needs to associate the newly signed certi ficate
with the existing asymmetric key:</t> with the existing asymmetric key:</t>
<artwork name="ex-keystore-ldevid-same-key.json" type="" align="left" al t=""><![CDATA[ <sourcecode type="json" name="ex-keystore-ldevid-same-key.json"><![CDATA [
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-keystore:keystore": { "ietf-keystore:keystore": {
"asymmetric-keys": { "asymmetric-keys": {
"asymmetric-key": [ "asymmetric-key": [
{ {
"name": "Manufacturer-Generated Hidden Key", "name": "Manufacturer-Generated Hidden Key",
"public-key-format": "ietf-crypto-types:subject-public-key\ "public-key-format": "ietf-crypto-types:subject-public-key\
-info-format", -info-format",
skipping to change at line 490 skipping to change at line 439
"name": "Newly-Generated LDevID Cert", "name": "Newly-Generated LDevID Cert",
"cert-data": "BASE64VALUE=" "cert-data": "BASE64VALUE="
} }
] ]
} }
} }
] ]
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t>This second example illustrates the case where the signed certificate is <t>This second example illustrates the case where the signed certificate is
for a newly generated asymmetric key. As such, the configuration ne eds for a newly generated asymmetric key. As such, the configuration ne eds
to associate the newly signed certificate with the newly generated to associate the newly signed certificate with the newly generated
asymmetric key:</t> asymmetric key:</t>
<artwork name="ex-keystore-ldevid-new-key.json" type="" align="left" alt =""><![CDATA[ <sourcecode type="json" name="ex-keystore-ldevid-new-key.json"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
{ {
"ietf-keystore:keystore": { "ietf-keystore:keystore": {
"asymmetric-keys": { "asymmetric-keys": {
"asymmetric-key": [ "asymmetric-key": [
{ {
"name": "Manufacturer-Generated Hidden Key", "name": "Manufacturer-Generated Hidden Key",
"public-key-format": "ietf-crypto-types:subject-public-key\ "public-key-format": "ietf-crypto-types:subject-public-key\
-info-format", -info-format",
skipping to change at line 536 skipping to change at line 485
"name": "Newly-Generated LDevID Cert", "name": "Newly-Generated LDevID Cert",
"cert-data": "BASE64VALUE=" "cert-data": "BASE64VALUE="
} }
] ]
} }
} }
] ]
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t>In addition to configuring the signed certificate, it is often <t>In addition to configuring the signed certificate, it is often
necessary to also configure the Issuer's signing certificate necessary to also configure the issuer's signing certificate
so that the device (i.e., STZP-client) can authenticate so that the device (i.e., STZP-client) can authenticate
certificates presented by peer devices signed by the same certificates presented by peer devices signed by the same
issuer as its own. While outside the scope of this document, issuer as its own. While outside the scope of this document,
one way to do this would be to use the "ietf-truststore" module one way to do this would be to use the "ietf-truststore" module
defined in <xref target="I-D.ietf-netconf-trust-anchors" format="def ault"/>.</t> defined in <xref target="RFC9641" format="default"/>.</t>
</section> </section>
<!-- Example Usage -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Module</name> <name>YANG Module</name>
<t>This module augments an RPC defined in <xref target="RFC8572" format= "default"/>. The <t>This module augments an RPC defined in <xref target="RFC8572" format= "default"/>. The
module uses a data types and groupings defined in <xref target="RFC8 module uses data types and groupings defined in <xref target="RFC857
572" format="default"/>, 2" format="default"/>,
<xref target="RFC8791" format="default"/>, and <xref target="I-D.iet <xref target="RFC8791" format="default"/>, and <xref target="RFC9640
f-netconf-crypto-types" format="default"/>. " format="default"/>.
The module also has an informative reference to <xref target="Std-80 The module also has an informative reference to <xref target="Std-802.1A
2.1AR-2018" format="default"/>.</t> R-2018" format="default"/>.</t>
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-sztp-csr@2022-03-0 <sourcecode type="yang" name="ietf-sztp-csr@2022-03-02.yang" markers="tru
2.yang"</t> e"><![CDATA[
<artwork name="ietf-sztp-csr@2022-03-02.yang" type="" align="left" alt="
"><![CDATA[
module ietf-sztp-csr { module ietf-sztp-csr {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";
prefix sztp-csr; prefix sztp-csr;
import ietf-sztp-bootstrap-server { import ietf-sztp-bootstrap-server {
prefix sztp-svr; prefix sztp-svr;
reference reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)"; "RFC 8572: Secure Zero Touch Provisioning (SZTP)";
} }
import ietf-yang-structure-ext { import ietf-yang-structure-ext {
prefix sx; prefix sx;
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
} }
import ietf-ztp-types { import ietf-ztp-types {
prefix zt; prefix zt;
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC 9646: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero-Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
skipping to change at line 598 skipping to change at line 545
Sean Turner <mailto:sean@sn3rd.com>"; Sean Turner <mailto:sean@sn3rd.com>";
description description
"This module augments the 'get-bootstrapping-data' RPC, "This module augments the 'get-bootstrapping-data' RPC,
defined in the 'ietf-sztp-bootstrap-server' module from defined in the 'ietf-sztp-bootstrap-server' module from
SZTP (RFC 8572), enabling the SZTP-client to obtain a SZTP (RFC 8572), enabling the SZTP-client to obtain a
signed identity certificate (e.g., an LDevID from IEEE signed identity certificate (e.g., an LDevID from IEEE
802.1AR) as part of the SZTP onboarding information 802.1AR) as part of the SZTP onboarding information
response. response.
Copyright (c) 2022 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9646
(https://www.rfc-editor.org/info/rfc9646); see the
RFC itself for full legal notices.";
revision 2022-03-02 { revision 2022-03-02 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC 9646: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero-Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" {
description description
"This augmentation adds the 'csr-support' and 'csr' nodes to "This augmentation adds the 'csr-support' and 'csr' nodes to
the SZTP (RFC 8572) 'get-bootstrapping-data' request message, the SZTP (RFC 8572) 'get-bootstrapping-data' request message,
enabling the SZTP-client to obtain an identity certificate enabling the SZTP-client to obtain an identity certificate
(e.g., an LDevID from IEEE 802.1AR) as part of the onboarding (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding
information response provided by the SZTP-server. information response provided by the SZTP-server.
The 'csr-support' node enables the SZTP-client to indicate The 'csr-support' node enables the SZTP-client to indicate
that it supports generating certificate signing requests that it supports generating certificate signing requests
(CSRs), and to provide details around the CSRs it is able (CSRs) and to provide details around the CSRs it is able
to generate. to generate.
The 'csr' node enables the SZTP-client to relay a CSR to The 'csr' node enables the SZTP-client to relay a CSR to
the SZTP-server."; the SZTP-server.";
reference reference
"IEEE 802.1AR: IEEE Standard for Local and metropolitan "IEEE 802.1AR: IEEE Standard for Local and Metropolitan
area networks - Secure Device Identity Area Networks - Secure Device Identity
RFC 8572: Secure Zero Touch Provisioning (SZTP)"; RFC 8572: Secure Zero Touch Provisioning (SZTP)";
choice msg-type { choice msg-type {
description description
"Messages are mutually exclusive."; "Messages are mutually exclusive.";
case csr-support { case csr-support {
description description
"Indicates how the SZTP-client supports generating CSRs. "Indicates how the SZTP-client supports generating CSRs.
If present and a SZTP-server wishes to request the If present and a SZTP-server wishes to request the
SZTP-client generate a CSR, the SZTP-server MUST SZTP-client generate a CSR, the SZTP-server MUST
respond with HTTP code 400 Bad Request with an respond with an HTTP 400 Bad Request error code with an
'ietf-restconf:errors' message having the 'error-tag' 'ietf-restconf:errors' message having the 'error-tag'
value 'missing-attribute' and the 'error-info' node value 'missing-attribute' and the 'error-info' node
containing the 'csr-request' structure described containing the 'csr-request' structure described
in this module."; in this module.";
uses zt:csr-support-grouping; uses zt:csr-support-grouping;
} }
case csr { case csr {
description description
"Provides the CSR generated by the SZTP-client. "Provides the CSR generated by the SZTP-client.
When present, the SZTP-server SHOULD respond with When present, the SZTP-server SHOULD respond with
an SZTP onboarding information message containing an SZTP onboarding information message containing
a signed certificate for the conveyed CSR. The a signed certificate for the conveyed CSR. The
SZTP-server MAY alternatively respond with another SZTP-server MAY alternatively respond with another
HTTP error containing another 'csr-request', in HTTP error containing another 'csr-request'; in
which case the SZTP-client MUST delete any key which case, the SZTP-client MUST delete any key
generated for the previously generated CSR."; generated for the previously generated CSR.";
uses zt:csr-grouping; uses zt:csr-grouping;
} }
} }
} }
sx:structure csr-request { sx:structure csr-request {
description description
"A YANG data structure, per RFC 8791, that specifies "A YANG data structure, per RFC 8791, that specifies
details for the CSR that the ZTP-client is to generate."; details for the CSR that the ZTP-client is to generate.";
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
uses zt:csr-request-grouping; uses zt:csr-request-grouping;
} }
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
<!-- YANG Module -->
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>The "ietf-ztp-types" Module</name> <name>The "ietf-ztp-types" Module</name>
<t>This section defines a YANG 1.1 <xref target="RFC7950" format="default" /> module <t>This section defines a YANG 1.1 <xref target="RFC7950" format="default" /> module
that defines three YANG groupings, one each for messages sent that defines three YANG groupings, one for each message sent
between a ZTP-client and ZTP-server. This module is defined between a ZTP-client and ZTP-server. This module is defined
independently of the "ietf-sztp-csr" module so that it's independently of the "ietf-sztp-csr" module so that its
groupings may be used by bootstrapping protocols other than groupings may be used by bootstrapping protocols other than
SZTP <xref target="RFC8572" format="default"/>.</t> SZTP <xref target="RFC8572" format="default"/>.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates <t>The following tree diagram <xref target="RFC8340" format="default"/> illustrates
the three groupings defined in the "ietf-ztp-types" module.</t> the three groupings defined in the "ietf-ztp-types" module.</t>
<artwork name="ietf-ztp-types-tree.txt" type="" align="left" alt=""><![C DATA[ <sourcecode type="yangtree" name="ietf-ztp-types-tree.txt"><![CDATA[
module: ietf-ztp-types module: ietf-ztp-types
grouping csr-support-grouping grouping csr-support-grouping
+-- csr-support +-- csr-support
+-- key-generation! +-- key-generation!
| +-- supported-algorithms | +-- supported-algorithms
| +-- algorithm-identifier* binary | +-- algorithm-identifier* binary
+-- csr-generation +-- csr-generation
+-- supported-formats +-- supported-formats
+-- format-identifier* identityref +-- format-identifier* identityref
skipping to change at line 735 skipping to change at line 680
| +-- format-identifier identityref | +-- format-identifier identityref
+-- cert-req-info? ct:csr-info +-- cert-req-info? ct:csr-info
grouping csr-grouping grouping csr-grouping
+-- (csr-type) +-- (csr-type)
+--:(p10-csr) +--:(p10-csr)
| +-- p10-csr? ct:csr | +-- p10-csr? ct:csr
+--:(cmc-csr) +--:(cmc-csr)
| +-- cmc-csr? binary | +-- cmc-csr? binary
+--:(cmp-csr) +--:(cmp-csr)
+-- cmp-csr? binary +-- cmp-csr? binary
]]></artwork> ]]></sourcecode>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Module</name> <name>YANG Module</name>
<t>This module uses a data types and groupings <xref target="RFC8791" fo <t>This module uses data types and groupings defined in <xref target="RF
rmat="default"/> C8791" format="default"/>
and <xref target="I-D.ietf-netconf-crypto-types" format="default"/>. and <xref target="RFC9640" format="default"/>. The module has
The module has
additional normative references to <xref target="RFC2986" format="de fault"/>, additional normative references to <xref target="RFC2986" format="de fault"/>,
<xref target="RFC4210" format="default"/>, <xref target="RFC5272" fo rmat="default"/>, and <xref target="RFC4210" format="default"/>, <xref target="RFC5272" fo rmat="default"/>, and
<xref target="ITU.X690.2015" format="default"/>, and an informative reference <xref target="ITU.X690.2021" format="default"/> and an informative r eference
to <xref target="Std-802.1AR-2018" format="default"/>.</t> to <xref target="Std-802.1AR-2018" format="default"/>.</t>
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-ztp-types@2022-03-
02.yang"</t> <sourcecode name="ietf-ztp-types@2022-03-02.yang" type="yang" markers="t
<artwork name="ietf-ztp-types@2022-03-02.yang" type="" align="left" alt= rue"><![CDATA[
""><![CDATA[
module ietf-ztp-types { module ietf-ztp-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";
prefix zt; prefix zt;
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"RFC AAAA: YANG Data Types and Groupings for Cryptography"; "RFC 9640: YANG Data Types and Groupings for Cryptography";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list <mailto:netconf@ietf.org>
Authors: Kent Watsen <mailto:kent+ietf@watsen.net> Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
Russ Housley <mailto:housley@vigilsec.com> Russ Housley <mailto:housley@vigilsec.com>
Sean Turner <mailto:sean@sn3rd.com>"; Sean Turner <mailto:sean@sn3rd.com>";
description description
"This module defines three groupings that enable "This module defines three groupings that enable
bootstrapping devices to 1) indicate if and how they bootstrapping devices to 1) indicate if and how they
support generating CSRs, 2) obtain a request to support generating CSRs, 2) obtain a request to
generate a CSR, and 3) communicate the requested CSR. generate a CSR, and 3) communicate the requested CSR.
Copyright (c) 2022 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9646
(https://www.rfc-editor.org/info/rfc9646); see the
RFC itself for full legal notices.";
revision 2022-03-02 { revision 2022-03-02 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC XXXX: Conveying a Certificate Signing Request (CSR) "RFC 9646: Conveying a Certificate Signing Request (CSR)
in a Secure Zero Touch Provisioning (SZTP) in a Secure Zero-Touch Provisioning (SZTP)
Bootstrapping Request"; Bootstrapping Request";
} }
identity certificate-request-format { identity certificate-request-format {
description description
"A base identity for the request formats supported "A base identity for the request formats supported
by the ZTP-client. by the ZTP-client.
Additional derived identities MAY be defined by Additional derived identities MAY be defined by
future efforts."; future efforts.";
skipping to change at line 830 skipping to change at line 775
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7"; Specification Version 1.7";
} }
identity cmp-csr { identity cmp-csr {
base certificate-request-format; base certificate-request-format;
description description
"Indicates that the ZTP-client supports generating "Indicates that the ZTP-client supports generating
requests using a profiled version of the PKIMessage requests using a profiled version of the PKIMessage
that MUST contain a PKIHeader followed by a PKIBody that MUST contain a PKIHeader followed by a PKIBody
containing only the ir, cr, kur, or p10cr structure containing only the ir, cr, kur, or p10cr structures
defined in RFC 4210."; defined in RFC 4210.";
reference reference
"RFC 4210: Internet X.509 Public Key Infrastructure "RFC 4210: Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)"; Certificate Management Protocol (CMP)";
} }
identity cmc-csr { identity cmc-csr {
base certificate-request-format; base certificate-request-format;
description description
"Indicates that the ZTP-client supports generating "Indicates that the ZTP-client supports generating
skipping to change at line 854 skipping to change at line 799
"RFC 5272: Certificate Management over CMS (CMC)"; "RFC 5272: Certificate Management over CMS (CMC)";
} }
// Protocol-accessible nodes // Protocol-accessible nodes
grouping csr-support-grouping { grouping csr-support-grouping {
description description
"A grouping enabling use by other efforts."; "A grouping enabling use by other efforts.";
container csr-support { container csr-support {
description description
"Enables a ZTP-client to indicate that it supports "Enables a ZTP-client to indicate that it supports
generating certificate signing requests (CSRs) and generating certificate signing requests (CSRs) and
provides details about the CSRs it is able to provides details about the CSRs it is able to
generate."; generate.";
container key-generation { container key-generation {
presence presence "Indicates that the ZTP-client is capable of
"Indicates that the ZTP-client is capable of generating a new asymmetric key pair.
generating a new asymmetric key pair.
If this node is not present, the ZTP-server MAY If this node is not present, the ZTP-server MAY
request a CSR using the asymmetric key associated request a CSR using the asymmetric key associated
with the device's existing identity certificate with the device's existing identity certificate
(e.g., an IDevID from IEEE 802.1AR)."; (e.g., an IDevID from IEEE 802.1AR).";
description description
"Specifies details for the ZTP-client's ability to "Specifies details for the ZTP-client's ability to
generate a new asymmetric key pair."; generate a new asymmetric key pair.";
container supported-algorithms { container supported-algorithms {
description description
"A list of public key algorithms supported by the "A list of public key algorithms supported by the
ZTP-client for generating a new asymmetric key."; ZTP-client for generating a new asymmetric key.";
leaf-list algorithm-identifier { leaf-list algorithm-identifier {
type binary; type binary;
min-elements 1; min-elements 1;
description description
"An AlgorithmIdentifier, as defined in RFC 2986, "An AlgorithmIdentifier, as defined in RFC 2986,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7 Specification Version 1.7
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER)";
} }
} }
} }
container csr-generation { container csr-generation {
description description
"Specifies details for the ZTP-client's ability to "Specifies details for the ZTP-client's ability to
generate a certificate signing requests."; generate certificate signing requests.";
container supported-formats { container supported-formats {
description description
"A list of certificate request formats supported "A list of certificate request formats supported
by the ZTP-client for generating a new key."; by the ZTP-client for generating a new key.";
leaf-list format-identifier { leaf-list format-identifier {
type identityref { type identityref {
base zt:certificate-request-format; base zt:certificate-request-format;
} }
min-elements 1; min-elements 1;
description description
skipping to change at line 918 skipping to change at line 862
} }
} }
} }
} }
} }
grouping csr-request-grouping { grouping csr-request-grouping {
description description
"A grouping enabling use by other efforts."; "A grouping enabling use by other efforts.";
container key-generation { container key-generation {
presence presence "Provided by a ZTP-server to indicate that it wishes
"Provided by a ZTP-server to indicate that it wishes the ZTP-client to generate a new asymmetric key.
the ZTP-client to generate a new asymmetric key.
This statement is present so the mandatory descendant This statement is present so the mandatory
nodes do not imply that this node must be configured."; descendant nodes do not imply that this node must
be configured.";
description description
"The key generation parameters selected by the ZTP-server. "The key generation parameters selected by the ZTP-server.
This leaf MUST only appear if the ZTP-client's This leaf MUST only appear if the ZTP-client's
'csr-support' included the 'key-generation' node."; 'csr-support' included the 'key-generation' node.";
container selected-algorithm { container selected-algorithm {
description description
"The key algorithm selected by the ZTP-server. The "The key algorithm selected by the ZTP-server. The
algorithm MUST be one of the algorithms specified by algorithm MUST be one of the algorithms specified by
the 'supported-algorithms' node in the ZTP-client's the 'supported-algorithms' node in the ZTP-client's
message containing the 'csr-support' structure."; message containing the 'csr-support' structure.";
leaf algorithm-identifier { leaf algorithm-identifier {
type binary; type binary;
mandatory true; mandatory true;
description description
"An AlgorithmIdentifier, as defined in RFC 2986, "An AlgorithmIdentifier, as defined in RFC 2986,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7 Specification Version 1.7
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER)";
} }
} }
} }
container csr-generation { container csr-generation {
description description
"Specifies details for the CSR that the ZTP-client "Specifies details for the CSR that the ZTP-client
is to generate."; is to generate.";
container selected-format { container selected-format {
description description
"The CSR format selected by the ZTP-server. The "The CSR format selected by the ZTP-server. The
format MUST be one of the formats specified by format MUST be one of the formats specified by
the 'supported-formats' node in the ZTP-client's the 'supported-formats' node in the ZTP-client's
request message."; request message.";
leaf format-identifier { leaf format-identifier {
type identityref { type identityref {
base zt:certificate-request-format; base zt:certificate-request-format;
} }
mandatory true; mandatory true;
description description
"A certificate request format to be used by the "A certificate request format to be used by the
ZTP-client."; ZTP-client.";
} }
} }
} }
leaf cert-req-info { leaf cert-req-info {
type ct:csr-info; type ct:csr-info;
description description
"A CertificationRequestInfo structure, as defined in "A CertificationRequestInfo structure, as defined in
RFC 2986, and modeled via a 'typedef' statement by RFC 2986, and modeled via a 'typedef' statement by
RFC AAAA. RFC 9640.
Enables the ZTP-server to provide a fully-populated Enables the ZTP-server to provide a fully populated
CertificationRequestInfo structure that the ZTP-client CertificationRequestInfo structure that the ZTP-client
only needs to sign in order to generate the complete only needs to sign in order to generate the complete
'CertificationRequest' structure to send to ZTP-server 'CertificationRequest' structure to send to the ZTP-server
in its next 'get-bootstrapping-data' request message. in its next 'get-bootstrapping-data' request message.
When provided, the ZTP-client MUST use this structure When provided, the ZTP-client MUST use this structure
to generate its CSR; failure to do so will result in a to generate its CSR; failure to do so will result in a
400 Bad Request response containing another 'csr-request' 400 Bad Request response containing another 'csr-request'
structure. structure.
When not provided, the ZTP-client SHOULD generate a CSR When not provided, the ZTP-client SHOULD generate a CSR
using the same structure defined in its existing identity using the same structure defined in its existing identity
certificate (e.g., an IDevID from IEEE 802.1AR). certificate (e.g., an IDevID from IEEE 802.1AR).
If the 'AlgorithmIdentifier' field contained inside the If the 'AlgorithmIdentifier' field contained inside the
certificate 'SubjectPublicKeyInfo' field does not match certificate 'SubjectPublicKeyInfo' field does not match
the algorithm identified by the 'selected-algorithm' node, the algorithm identified by the 'selected-algorithm' node,
then the client MUST reject the certificate and raise an then the client MUST reject the certificate and raise an
error."; error.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax Specification PKCS #10: Certification Request Syntax Specification
RFC AAAA: Version 1.7
RFC 9640:
YANG Data Types and Groupings for Cryptography"; YANG Data Types and Groupings for Cryptography";
} }
} }
grouping csr-grouping { grouping csr-grouping {
description description
"Enables a ZTP-client to convey a certificate signing "Enables a ZTP-client to convey a certificate signing
request, using the encoding format selected by a request, using the encoding format selected by a
ZTP-server's 'csr-request' response to the ZTP-client's ZTP-server's 'csr-request' response to the ZTP-client's
previously sent request containing the 'csr-support' previously sent request containing the 'csr-support'
node."; node.";
choice csr-type { choice csr-type {
mandatory true; mandatory true;
description description
"A choice amongst certificate signing request formats. "A choice amongst certificate signing request formats.
Additional formats MAY be augmented into this 'choice' Additional formats MAY be augmented into this 'choice'
statement by future efforts."; statement by future efforts.";
case p10-csr { case p10-csr {
leaf p10-csr { leaf p10-csr {
type ct:csr; type ct:p10-csr;
description description
"A CertificationRequest structure, per RFC 2986. "A CertificationRequest structure, per RFC 2986.
Encoding details are defined in the 'ct:csr' Encoding details are defined in the 'ct:csr'
typedef defined in RFC AAAA. typedef defined in RFC 9640.
A raw P10 does not support origin authentication in A raw P10 does not support origin authentication in
the CSR structure. External origin authentication the CSR structure. External origin authentication
may be provided via the ZTP-client's authentication may be provided via the ZTP-client's authentication
to the ZTP-server at the transport layer (e.g., TLS)."; to the ZTP-server at the transport layer (e.g., TLS).";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Specification Version 1.7
RFC AAAA: YANG Data Types and Groupings for RFC 9640: YANG Data Types and Groupings for
Cryptography"; Cryptography";
} }
} }
case cmc-csr { case cmc-csr {
leaf cmc-csr { leaf cmc-csr {
type binary; type binary;
description description
"A profiled version of the 'Full PKI Request' "A profiled version of the 'Full PKI Request'
message defined in RFC 5272, encoded using ASN.1 message defined in RFC 5272, encoded using ASN.1
distinguished encoding rules (DER), as specified Distinguished Encoding Rules (DER), as specified
in ITU-T X.690. in ITU-T X.690.
For asymmetric key-based origin authentication of a For asymmetric-key-based origin authentication of a
CSR based on the initial device identity certificate's CSR based on the initial device identity certificate's
private key for the associated identity certificate's private key for the associated identity certificate's
public key, the PKIData contains one reqSequence public key, the PKIData contains one reqSequence
element and no cmsSequence or otherMsgSequence element and no cmsSequence or otherMsgSequence
elements. The reqSequence is the TaggedRequest elements. The reqSequence is the TaggedRequest,
and it is the tcr CHOICE branch. The tcr is the and it is the tcr CHOICE branch. The tcr is the
TaggedCertificationRequest and it is the bodyPartId TaggedCertificationRequest, and it is the bodyPartID
and the certificateRequest elements. The and the certificateRequest elements. The
certificateRequest is signed with the initial device certificateRequest is signed with the initial device
identity certificate's private key. The initial device identity certificate's private key. The initial device
identity certificate and optionally its certificate identity certificate, and optionally its certificate
chain is included in the SignedData certificates that chain is included in the SignedData certificates that
encapsulates the PKIData. encapsulate the PKIData.
For asymmetric key-based origin authentication based on For asymmetric-key-based origin authentication based on
the initial device identity certificate's private key the initial device identity certificate's private key
that signs the encapsulated CSR signed by the local that signs the encapsulated CSR signed by the local
device identity certificate's private key, the device identity certificate's private key, the
PKIData contains one cmsSequence element and no PKIData contains one cmsSequence element and no
reqSequence or otherMsgSequence reqSequence or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo,
and it includes a bodyPartID element and a contentInfo. and it includes a bodyPartID element and a contentInfo.
The contentInfo is a SignedData encapsulating a PKIData The contentInfo is a SignedData encapsulating a PKIData
with one reqSequence element and no cmsSequence or with one reqSequence element and no cmsSequence or
otherMsgSequence elements. The reqSequence is the otherMsgSequence elements. The reqSequence is the
TaggedRequest and it is the tcr CHOICE. The tcr is the TaggedRequest, and it is the tcr CHOICE. The tcr is the
TaggedCertificationRequest and it is the bodyPartId and TaggedCertificationRequest, and it is the bodyPartID and
the certificateRequest elements. PKIData contains one the certificateRequest elements. PKIData contains one
cmsSequence element and no controlSequence, reqSequence, cmsSequence element and no controlSequence, reqSequence,
or otherMsgSequence elements. The certificateRequest or otherMsgSequence elements. The certificateRequest
is signed with the local device identity certificate's is signed with the local device identity certificate's
private key. The initial device identity certificate private key. The initial device identity certificate
and optionally its certificate chain is included in the and optionally its certificate chain is included in
SignedData certificates that encapsulates the PKIData. the SignedData certificates that encapsulate the
PKIData.
For shared secret-based origin authentication of a For shared-secret-based origin authentication of a
CSR signed by the local device identity certificate's CSR signed by the local device identity certificate's
private key, the PKIData contains one cmsSequence private key, the PKIData contains one cmsSequence
element and no reqSequence or otherMsgSequence element and no reqSequence or otherMsgSequence
elements. The cmsSequence is the TaggedContentInfo elements. The cmsSequence is the TaggedContentInfo,
and it includes a bodyPartID element and a contentInfo. and it includes a bodyPartID element and a contentInfo.
The contentInfo is an AuthenticatedData encapsulating The contentInfo is an AuthenticatedData encapsulating
a PKIData with one reqSequence element and no a PKIData with one reqSequence element and no
cmsSequences or otherMsgSequence elements. The cmsSequences or otherMsgSequence elements. The
reqSequence is the TaggedRequest and it is the tcr reqSequence is the TaggedRequest, and it is the tcr
CHOICE. The tcr is the TaggedCertificationRequest CHOICE. The tcr is the TaggedCertificationRequest,
and it is the bodyPartId and the certificateRequest and it is the bodyPartID and the certificateRequest
elements. The certificateRequest is signed with the elements. The certificateRequest is signed with the
local device identity certificate's private key. The local device identity certificate's private key. The
initial device identity certificate and optionally its initial device identity certificate and optionally its
certificate chain is included in the SignedData certificate chain is included in the SignedData
certificates that encapsulates the PKIData."; certificates that encapsulate the PKIData.";
reference reference
"RFC 5272: Certificate Management over CMS (CMC) "RFC 5272: Certificate Management over CMS (CMC)
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER)";
} }
} }
case cmp-csr { case cmp-csr {
leaf cmp-csr { leaf cmp-csr {
type binary; type binary;
description description
"A PKIMessage structure, as defined in RFC 4210, "A PKIMessage structure, as defined in RFC 4210,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 Distinguished Encoding Rules
(DER), as specified in ITU-T X.690. (DER), as specified in ITU-T X.690.
For asymmetric key-based origin authentication of a For asymmetric-key-based origin authentication of a
CSR based on the initial device identity certificate's CSR based on the initial device identity certificate's
private key for the associated initial device identity private key for the associated initial device identity
certificate's public key, PKIMessages contains one certificate's public key, PKIMessages contain one
PKIMessage with the header and body elements, no PKIMessage with the header and body elements, do not
protection element, and SHOULD contain the extraCerts contain a protection element, and SHOULD contain the
element. The header element contains the pvno, sender, extraCerts element. The header element contains the
and recipient elements. The pvno contains cmp2000, and pvno, sender, and recipient elements. The pvno contains
the sender contains the subject of the initial device cmp2000, and the sender contains the subject of the
identity certificate. The body element contains an ir, initial device identity certificate. The body element
cr, kur, or p10cr CHOICE of type CertificationRequest. contains an ir, cr, kur, or p10cr CHOICE of type
It is signed with the initial device identity CertificationRequest. It is signed with the initial
certificate's private key. The extraCerts element device identity certificate's private key. The
contains the initial device identity certificate, extraCerts element contains the initial device identity
optionally followed by its certificate chain excluding certificate, optionally followed by its certificate
the trust anchor. chain excluding the trust anchor.
For asymmetric key-based origin authentication based For asymmetric-key-based origin authentication based
on the initial device identity certificate's private on the initial device identity certificate's private
key that signs the encapsulated CSR signed by the local key that signs the encapsulated CSR signed by the local
device identity certificate's private key, PKIMessages device identity certificate's private key, PKIMessages
contains one PKIMessage with the header, body, and contain one PKIMessage with the header, body, and
protection elements, and SHOULD contain the extraCerts protection elements and SHOULD contain the extraCerts
element. The header element contains the pvno, sender, element. The header element contains the pvno, sender,
recipient, protectionAlg, and optionally senderKID recipient, protectionAlg, and optionally senderKID
elements. The pvno contains cmp2000, the sender elements. The pvno contains cmp2000, the sender
contains the subject of the initial device identity contains the subject of the initial device identity
certificate, the protectionAlg contains the certificate, the protectionAlg contains the
AlgorithmIdentifier of the used signature algorithm, AlgorithmIdentifier of the used signature algorithm,
and the senderKID contains the subject key identifier and the senderKID contains the subject key identifier
of the initial device identity certificate. The body of the initial device identity certificate. The body
element contains an ir, cr, kur, or p10cr CHOICE of element contains an ir, cr, kur, or p10cr CHOICE of
type CertificationRequest. It is signed with the local type CertificationRequest. It is signed with the local
device identity certificate's private key. The device identity certificate's private key. The
protection element contains the digital signature protection element contains the digital signature
generated with the initial device identity generated with the initial device identity
certificate's private key. The extraCerts element certificate's private key. The extraCerts element
contains the initial device identity certificate, contains the initial device identity certificate,
optionally followed by its certificate chain excluding optionally followed by its certificate chain excluding
the trust anchor. the trust anchor.
For shared secret-based origin authentication of a For shared-secret-based origin authentication of a
CSR signed by the local device identity certificate's CSR signed by the local device identity certificate's
private key, PKIMessages contains one PKIMessage with private key, PKIMessages contain one PKIMessage with
the header, body, and protection element, and no the header, body, and protection element and no
extraCerts element. The header element contains the extraCerts element. The header element contains the
pvno, sender, recipient, protectionAlg, and senderKID pvno, sender, recipient, protectionAlg, and senderKID
elements. The pvno contains cmp2000, the protectionAlg elements. The pvno contains cmp2000, the protectionAlg
contains the AlgorithmIdentifier of the used MAC contains the AlgorithmIdentifier of the used Message
algorithm, and the senderKID contains a reference the Authentication Code (MAC) algorithm, and the senderKID
recipient can use to identify the shared secret. The contains a reference the recipient can use to identify
body element contains an ir, cr, kur, or p10cr CHOICE the shared secret. The body element contains an ir, cr,
of type CertificationRequest. It is signed with the kur, or p10cr CHOICE of type CertificationRequest. It
local device identity certificate's private key. The is signed with the local device identity certificate's
protection element contains the MAC value generated private key. The protection element contains the MAC
with the shared secret."; value generated with the shared secret.";
reference reference
"RFC 4210: "RFC 4210:
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP) Certificate Management Protocol (CMP)
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)."; Encoding Rules (DER)";
} }
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
<!-- YANG Module -->
</section> </section>
<section anchor="sec-con" numbered="true" toc="default"> <section anchor="sec-con" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document builds on top of the solution presented in <t>This document builds on top of the solution presented in
<xref target="RFC8572" format="default"/> and therefore all the Securi <xref target="RFC8572" format="default"/>, and therefore all the secur
ty ity
Considerations discussed in RFC 8572 apply here as well.</t> considerations discussed in <xref target="RFC8572"/> apply here as well.</
t>
<t>For the various CSR formats, when using PKCS#10, the security considera tions <t>For the various CSR formats, when using PKCS#10, the security considera tions
in <xref target="RFC2986" format="default"/> apply, when using CMP, th in <xref target="RFC2986" format="default"/> apply; when using CMP, th
e e
security considerations in <xref target="RFC4210" format="default"/> a security considerations in <xref target="RFC4210" format="default"/> a
pply pply;
and, when using CMC, the security considerations in and when using CMC, the security considerations in
<xref target="RFC5272" format="default"/> apply.</t> <xref target="RFC5272" format="default"/> apply.</t>
<t>For the various authentication mechanisms, when using <t>For the various authentication mechanisms, when using
TLS-level authentication, the security considerations in TLS-level authentication, the security considerations in
<xref target="RFC8446" format="default"/> apply and, when using HTTP-l evel <xref target="RFC8446" format="default"/> apply, and when using HTTP-l evel
authentication, the security considerations in authentication, the security considerations in
<xref target="RFC7235" format="default"/> apply.</t> <xref target="RFC9110" format="default"/> apply.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>SZTP-Client Considerations</name> <name>SZTP-Client Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Ensuring the Integrity of Asymmetric Private Keys</name> <name>Ensuring the Integrity of Asymmetric Private Keys</name>
<t>The private key the SZTP-client uses for the dynamically-generated <t>The private key the SZTP-client uses for the dynamically generated
identity certificate MUST be protected from inadvertent disclosure identity certificate <bcp14>MUST</bcp14> be protected from inadver
tent disclosure
in order to prevent identity fraud.</t> in order to prevent identity fraud.</t>
<t>The security of this private key is essential in order to <t>The security of this private key is essential in order to
ensure the associated identity certificate can be used to ensure the associated identity certificate can be used to
authenticate the device it is issued to.</t> authenticate the device it is issued to.</t>
<t>It is RECOMMENDED that devices are manufactured with an HSM <t>It is <bcp14>RECOMMENDED</bcp14> that devices are manufactured with
(hardware security module), such as a TPM (trusted platform a
module), to generate and contain the private key within hardware security module (HSM), such as a trusted platform
module (TPM), to generate and contain the private key within
the security perimeter of the HSM. In such cases, the private the security perimeter of the HSM. In such cases, the private
key, and its associated certificates, MAY have long validity key and its associated certificates <bcp14>MAY</bcp14> have long v alidity
periods.</t> periods.</t>
<t>In cases where the SZTP-client does not possess an HSM, or <t>In cases where the SZTP-client does not possess an HSM or
is unable to use an HSM to protect the private key, it is is unable to use an HSM to protect the private key, it is
RECOMMENDED to periodically reset the private key (and <bcp14>RECOMMENDED</bcp14> to periodically reset the private key ( and
associated identity certificates) in order to minimize the associated identity certificates) in order to minimize the
lifetime of unprotected private keys. For instance, an NMS lifetime of unprotected private keys. For instance, a Network Man agement System (NMS)
controller/orchestrator application could periodically prompt controller/orchestrator application could periodically prompt
the SZTP-client to generate a new private key and provide a the SZTP-client to generate a new private key and provide a
certificate signing request (CSR) or, alternatively, push certificate signing request (CSR) or, alternatively, push
both the key and an identity certificate to the SZTP-client both the key and an identity certificate to the SZTP-client
using, e.g., a PKCS #12 message <xref target="RFC7292" format="def ault"/>. In another using, e.g., a PKCS#12 message <xref target="RFC7292" format="defa ult"/>. In another
example, the SZTP-client could be configured to periodically example, the SZTP-client could be configured to periodically
reset the configuration to its factory default, thus causing reset the configuration to its factory default, thus causing
removal of the private key and associated identity certificates removal of the private key and associated identity certificates
and re-execution of the SZTP protocol.</t> and re-execution of the SZTP protocol.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Reuse of a Manufacturer-generated Private Key</name> <name>Reuse of a Manufacturer-Generated Private Key</name>
<t>It is RECOMMENDED that a new private key is generated for each <t>It is <bcp14>RECOMMENDED</bcp14> that a new private key is generate
d for each
CSR described in this document.</t> CSR described in this document.</t>
<t>Implementations must randomly generate nonces and private keys. <t>Implementations must randomly generate nonces and private keys.
The use of inadequate pseudo-random number generators (PRNGs) to The use of inadequate pseudorandom number generators (PRNGs) to
generate cryptographic keys can result in little or no security. generate cryptographic keys can result in little or no security.
An attacker may find it much easier to reproduce the PRNG environm ent An attacker may find it much easier to reproduce the PRNG environm ent
that produced the keys, searching the resulting small set of that produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole possibilities, rather than brute force searching the whole
key space. As an example of predictable random numbers see key space. As an example of predictable random numbers, see
CVE-2008-0166 <xref target="CVE-2008-0166" format="default"/>, and some consequences CVE-2008-0166 <xref target="CVE-2008-0166" format="default"/>, and some consequences
of low-entropy random numbers are discussed in Mining Your Ps and Qs of low-entropy random numbers are discussed in "Mining Your Ps and Qs"
<xref target="MiningPsQs" format="default"/>. The generation of q uality random <xref target="MiningPsQs" format="default"/>. The generation of q uality random
numbers is difficult. <xref target="ISO.20543-2019" format="defaul t"/>, numbers is difficult. <xref target="ISO.20543-2019" format="defaul t"/>,
<xref target="NIST.SP.800-90Ar1" format="default"/>, BSI AIS 31 <x ref target="AIS31" format="default"/>, <xref target="NIST.SP.800-90Ar1" format="default"/>, BSI AIS 31 <x ref target="AIS31" format="default"/>,
BCP 106 <xref target="RFC4086" format="default"/>, and others offe r valuable BCP 106 <xref target="RFC4086" format="default"/>, and others offe r valuable
guidance in this area.</t> guidance in this area.</t>
<t>This private key SHOULD be protected as well as the built-in <t>This private key <bcp14>SHOULD</bcp14> be protected as well as the built-in
private key associated with the SZTP-client's initial device ident ity private key associated with the SZTP-client's initial device ident ity
certificate (e.g., the IDevID, from <xref target="Std-802.1AR-2018 " format="default"/>).</t> certificate (e.g., the IDevID from <xref target="Std-802.1AR-2018" format="default"/>).</t>
<t>In cases where it is not possible to generate a new private key <t>In cases where it is not possible to generate a new private key
that is protected as well as the built-in private key, it is that is protected as well as the built-in private key, it is
RECOMMENDED to reuse the built-in private key rather than <bcp14>RECOMMENDED</bcp14> to reuse the built-in private key rathe r than
generate a new private key that is not as well protected.</t> generate a new private key that is not as well protected.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Replay Attack Protection</name> <name>Replay Attack Protection</name>
<t>This RFC enables an SZTP-client to announce an ability to <t>This RFC enables an SZTP-client to announce an ability to
generate a new key to use for its CSR.</t> generate a new key to use for its CSR.</t>
<t>When the SZTP-server responds with a request for the SZTP-client <t>When the SZTP-server responds with a request for the SZTP-client
to generate a new key, it is essential that the SZTP-client actual ly to generate a new key, it is essential that the SZTP-client actual ly
generates a new key.</t> generates a new key.</t>
<t>Generating a new key each time enables the random bytes used <t>Generating a new key each time enables the random bytes used
skipping to change at line 1298 skipping to change at line 1242
SZTP-client that the response has not been replayed; however, SZTP-client that the response has not been replayed; however,
the worst case result is a lost certificate that is associated the worst case result is a lost certificate that is associated
to the private key known only to the SZTP-client. Protection to the private key known only to the SZTP-client. Protection
of the private-key information is vital to public-key of the private-key information is vital to public-key
cryptography. Disclosure of the private-key material to cryptography. Disclosure of the private-key material to
another entity can lead to masquerades.</t> another entity can lead to masquerades.</t>
</section> </section>
<section anchor="untrusted" numbered="true" toc="default"> <section anchor="untrusted" numbered="true" toc="default">
<name>Connecting to an Untrusted Bootstrap Server</name> <name>Connecting to an Untrusted Bootstrap Server</name>
<t><xref target="RFC8572" format="default"/> allows SZTP-clients to co nnect <t><xref target="RFC8572" format="default"/> allows SZTP-clients to co nnect
to untrusted SZTP-servers, by blindly authenticating the to untrusted SZTP-servers by blindly authenticating the
SZTP-server's TLS end-entity certificate.</t> SZTP-server's TLS end-entity certificate.</t>
<t>As is discussed in <relref section="9.5" target="RFC8572"/>, <t>As is discussed in <relref section="9.5" target="RFC8572"/>,
in such cases the SZTP-client MUST assert that the in such cases, the SZTP-client <bcp14>MUST</bcp14> assert that the
bootstrapping data returned is signed, if the SZTP-client bootstrapping data returned is signed if the SZTP-client
is to trust it.</t> is to trust it.</t>
<t>However, the HTTP error message used in this document <t>However, the HTTP error message used in this document
cannot be signed data, as described in RFC 8572.</t> cannot be signed data, as described in <xref target="RFC8572"/>.</ t>
<t>Therefore, the solution presented in this document <t>Therefore, the solution presented in this document
cannot be used when the SZTP-client connects to an cannot be used when the SZTP-client connects to an
untrusted SZTP-server.</t> untrusted SZTP-server.</t>
<t>Consistent with the recommendation presented in <t>Consistent with the recommendation presented in
<relref section="9.6" target="RFC8572"/>, SZTP-clients <relref section="9.6" target="RFC8572"/>, SZTP-clients
SHOULD NOT pass the "csr-support" input parameter <bcp14>SHOULD NOT</bcp14> pass the "csr-support" input parameter
to an untrusted SZTP-server. SZTP-clients SHOULD to an untrusted SZTP-server. SZTP-clients <bcp14>SHOULD</bcp14>
pass instead the "signed-data-preferred" input instead pass the "signed-data-preferred" input
parameter, as discussed in <relref section="B" target="RFC8572"/>. </t> parameter, as discussed in <relref section="B" target="RFC8572"/>. </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Selecting the Best Origin Authentication Mechanism</name> <name>Selecting the Best Origin Authentication Mechanism</name>
<t>The origin of the CSR must be verified before a <t>The origin of the CSR must be verified before a
certificate is issued.</t> certificate is issued.</t>
<t>When generating a new key, it is important that the <t>When generating a new key, it is important that the
SZTP-client be able to provide additional proof that it SZTP-client be able to provide additional proof that it
was the entity that generated the key.</t> was the entity that generated the key.</t>
<t>The CMP and CMC certificate request formats defined in this <t>The CMP and CMC certificate request formats defined in this
document support origin authentication. A raw document support origin authentication. A raw
PKCS#10 CSR does not support origin authentication.</t> PKCS#10 CSR does not support origin authentication.</t>
<t>The CMP and CMC request formats support origin <t>The CMP and CMC request formats support origin
authentication using both PKI and shared secret.</t> authentication using both PKI and a shared secret.</t>
<t>Typically, only one possible origin authentication <t>Typically, only one possible origin authentication
mechanism can possibly be used but, in the case that the mechanism can possibly be used, but in the case that the
SZTP-client authenticates itself using both TLS-level SZTP-client authenticates itself using both TLS-level
(e.g., IDevID) and HTTP-level credentials (e.g., Basic), (e.g., IDevID) and HTTP-level credentials (e.g., Basic),
as is allowed by <relref section="5.3" target="RFC8572"/>, as is allowed by <relref section="5.3" target="RFC8572"/>,
then the SZTP-client may need to choose between the two then the SZTP-client may need to choose between the two
options.</t> options.</t>
<t>In the case that the SZTP-client must choose between an <t>In the case that the SZTP-client must choose between an
asymmetric key option versus a shared secret for origin asymmetric key option versus a shared secret for origin
authentication, it is RECOMMENDED that the SZTP-client authentication, it is <bcp14>RECOMMENDED</bcp14> that the SZTP-cli ent
choose using the asymmetric key.</t> choose using the asymmetric key.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Clearing the Private Key and Associated Certificate</name> <name>Clearing the Private Key and Associated Certificate</name>
<t>Unlike a manufacturer-generated identity certificate (e.g., IDevID) , <t>Unlike a manufacturer-generated identity certificate (e.g., IDevID) ,
the deployment-generated identity certificate (e.g., LDevID) and the deployment-generated identity certificate (e.g., LDevID) and
the associated private key (assuming a new private key was generat ed the associated private key (assuming a new private key was generat ed
for the purpose), are considered user data and SHOULD be cleared for the purpose) are considered user data and <bcp14>SHOULD</bcp14 > be cleared
whenever the SZTP-client is reset to its factory default state, whenever the SZTP-client is reset to its factory default state,
such as by the "factory-reset" RPC defined in such as by the "factory-reset" RPC defined in
<xref target="RFC8808" format="default"/>.</t> <xref target="RFC8808" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>SZTP-Server Considerations</name> <name>SZTP-Server Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Verifying Proof of Possession</name> <name>Verifying Proof-of-Possession</name>
<t>Regardless if using a new asymmetric key or the bootstrapping <t>Regardless, if using a new asymmetric key or the bootstrapping
device's manufacturer-generated key (e.g., the IDevID key), the device's manufacturer-generated key (e.g., the IDevID key), the
public key is placed in the CSR and the CSR is signed by that public key is placed in the CSR and the CSR is signed by that
private key. Proof-of-possession of the private key is verified private key. Proof-of-possession of the private key is verified
by ensuring the signature over the CSR using the public key by ensuring the signature over the CSR using the public key
placed in the CSR.</t> placed in the CSR.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Verifying Proof of Origin</name> <name>Verifying Proof-of-Origin</name>
<t>When the bootstrapping device's manufacturer-generated <t>When the bootstrapping device's manufacturer-generated
private key (e.g., the IDevID key) is reused for the CSR, private key (e.g., the IDevID key) is reused for the CSR,
proof-of-origin is verified by validating the IDevID-issuer cert proof-of-origin is verified by validating the IDevID-issuer cert
and ensuring that the CSR uses the same key pair.</t> and ensuring that the CSR uses the same key pair.</t>
<t>When the bootstrapping device's manufacturer-generated private key <t>When the bootstrapping device's manufacturer-generated private key
(e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, pro of-of-origin is (e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, pro of-of-origin is
verified by validating the IDevID certification path and ensuring that verified by validating the IDevID certification path and ensuring that
the CSR uses the same key pair.</t> the CSR uses the same key pair.</t>
<t>When a fresh asymmetric key is used with the CMP or CMC formats, th e <t>When a fresh asymmetric key is used with the CMP or CMC formats, th e
authentication is part of the protocols, which could employ either authentication is part of the protocols, which could employ either
the manufacturer-generated private key or a shared secret. In add ition, the manufacturer-generated private key or a shared secret. In add ition,
CMP and CMC support processing by a RA before the request is passe d CMP and CMC support processing by an RA before the request is pass ed
to the CA, which allows for more robust handling of errors.</t> to the CA, which allows for more robust handling of errors.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Supporting SZTP-Clients that don't trust the SZTP-Server</name> <name>Supporting SZTP-Clients That Don't Trust the SZTP-Server</name>
<t><xref target="RFC8572" format="default"/> allows SZTP-clients to co nnect <t><xref target="RFC8572" format="default"/> allows SZTP-clients to co nnect
to untrusted SZTP-servers, by blindly authenticating the to untrusted SZTP-servers by blindly authenticating the
SZTP-server's TLS end-entity certificate.</t> SZTP-server's TLS end-entity certificate.</t>
<t>As is recommended in <xref target="untrusted" format="default"/> in <t>As is recommended in <xref target="untrusted" format="default"/> of
this this
document, in such cases, SZTP-clients SHOULD pass the document, in such cases, SZTP-clients <bcp14>SHOULD</bcp14> pass t
he
"signed-data-preferred" input parameter.</t> "signed-data-preferred" input parameter.</t>
<t>The reciprocal of this statement is that SZTP-servers, <t>The reciprocal of this statement is that SZTP-servers,
wanting to support SZTP-clients that don't trust them, wanting to support SZTP-clients that don't trust them,
SHOULD support the "signed-data-preferred" input parameter, <bcp14>SHOULD</bcp14> support the "signed-data-preferred" input pa rameter,
as discussed in <relref section="B" target="RFC8572"/>.</t> as discussed in <relref section="B" target="RFC8572"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations for the "ietf-sztp-csr" YANG Module</name> <name>Security Considerations for the "ietf-sztp-csr" YANG Module</name>
<t>The recommended format for documenting the Security <t>The recommended format for documenting the security
Considerations for YANG modules is described in <relref section="3.7 considerations for YANG modules is described in <relref section="3.7
" target="RFC8407"/>. However, this module " target="RFC8407"/>. However, this module
only augments two input parameters only augments two input parameters
into the "get-bootstrapping-data" RPC in <xref target="RFC8572" form at="default"/>, and therefore only needs to point into the "get-bootstrapping-data" RPC in <xref target="RFC8572" form at="default"/> and therefore only needs to point
to the relevant Security Considerations sections in to the relevant Security Considerations sections in
that RFC.</t> that RFC.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Security considerations for the "get-bootstrapping-data" RPC <li>Security considerations for the "get-bootstrapping-data" RPC
are described in <relref section="9.16" target="RFC8572"/>.</li> are described in <relref section="9.16" target="RFC8572"/>.</li>
<li>Security considerations for the "input" parameters passed inside t he <li>Security considerations for the "input" parameters passed inside t he
"get-bootstrapping-data" RPC are described in <relref section="9.6 " target="RFC8572"/>.</li> "get-bootstrapping-data" RPC are described in <relref section="9.6 " target="RFC8572"/>.</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations for the "ietf-ztp-types" YANG Module</name > <name>Security Considerations for the "ietf-ztp-types" YANG Module</name >
<t>The recommended format for documenting the Security <t>The recommended format for documenting the security
Considerations for YANG modules is described in <relref section="3.7 considerations for YANG modules is described in <relref section="3.7" ta
" target="RFC8407"/>. However, this module rget="RFC8407"/>. However, this module
does not define any protocol-accessible nodes (it only does not define any protocol-accessible nodes (it only
defines "identity" and "grouping" statements) and therefore defines "identity" and "grouping" statements), and therefore
there are no Security considerations to report.</t> there are no security considerations to report.</t>
</section> </section>
</section> </section>
<!-- end Security Considerations -->
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>The "IETF XML" Registry</name> <name>The IETF XML Registry</name>
<t>This document registers two URIs in the "ns" subregistry of <t>IANA has registered two URIs in the "ns" registry of
the IETF XML Registry <xref target="RFC3688" format="default"/> main the "IETF XML Registry" <xref target="RFC3688" format="default"/> ma
tained at intained at
<eref target="https://www.iana.org/assignments/xml-registry/xml-regi <eref target="https://www.iana.org/assignments/xml-registry/" bracke
stry.xhtml#ns"/>. ts="angle"/>.
Following the format in <xref target="RFC3688" format="default"/>, t </t>
he following <dl newline="false" spacing="compact">
registrations are requested:</t> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-sztp-csr</dd>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dt>Registrant Contact:</dt> <dd>The NETCONF WG of the IETF.</dd>
URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr <dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
Registrant Contact: The NETCONF WG of the IETF. </dl>
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types <dl newline="false" spacing="compact">
Registrant Contact: The NETCONF WG of the IETF. <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-ztp-types</dd>
XML: N/A, the requested URI is an XML namespace. <dt>Registrant Contact:</dt> <dd>The NETCONF WG of the IETF.</dd>
]]></artwork> <dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>The "YANG Module Names" Registry</name> <name>The YANG Module Names Registry</name>
<t>This document registers two YANG modules in the YANG Module <t>IANA has registered two YANG modules in the "YANG Module
Names registry <xref target="RFC6020" format="default"/> maintained Names" registry <xref target="RFC6020" format="default"/> maintained
at at
<eref target="https://www.iana.org/assignments/yang-parameters/yang- <eref target="https://www.iana.org/assignments/yang-parameters/" bra
parameters.xhtml"/>. ckets="angle"/>.</t>
Following the format defined in <xref target="RFC6020" format="defau <dl newline="false" spacing="compact">
lt"/>, the below <dt>Name:</dt> <dd>ietf-sztp-csr</dd>
registrations are requested:</t> <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-sztp-csr</dd>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dt>Prefix:</dt> <dd>sztp-csr</dd>
name: ietf-sztp-csr <dt>Reference:</dt> <dd>RFC 9646</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr </dl>
prefix: sztp-csr <dl newline="false" spacing="compact">
reference: RFC XXXX <dt>Name:</dt> <dd>ietf-ztp-types</dd>
<dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-ztp-types</dd>
name: ietf-ztp-types <dt>Prefix:</dt> <dd>ztp-types</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types <dt>Reference:</dt> <dd>RFC 9646</dd>
prefix: ztp-types </dl>
reference: RFC XXXX
]]></artwork>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
19.xml"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.
<title>Key words for use in RFCs to Indicate Requirement Levels</tit xml"/>
le> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.
<seriesInfo name="DOI" value="10.17487/RFC2119"/> xml"/>
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4210.
<seriesInfo name="BCP" value="14"/> xml"/>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5272.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.
<date year="1997" month="March"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.
<t>In many standards track documents several words are used to sig xml"/>
nify the requirements in the specification. These words are often capitalized. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.
This document defines these words as they should be interpreted in IETF document xml"/>
s. This document specifies an Internet Best Current Practices for the Internet <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
Community, and requests discussion and suggestions for improvements.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
</front> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
<reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2 xml"/>
986" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.29 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8572.
86.xml"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8791.
<title>PKCS #10: Certification Request Syntax Specification Version xml"/>
1.7</title>
<seriesInfo name="DOI" value="10.17487/RFC2986"/> <reference anchor='RFC9640' target='https://www.rfc-editor.org/info/rfc9640'>
<seriesInfo name="RFC" value="2986"/> <front>
<author initials="M." surname="Nystrom" fullname="M. Nystrom"> <title>YANG Data Types and Groupings for Cryptography</title>
<organization/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
</author> <organization>Watsen Networks</organization>
<author initials="B." surname="Kaliski" fullname="B. Kaliski"> </author>
<organization/> <date month="October" year="2024"/>
</author> </front>
<date year="2000" month="November"/> <seriesInfo name="RFC" value="9640"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC9640"/>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA </reference>
Laboratories' Public-Key Cryptography Standards (PKCS) series, and change contro
l is retained within the PKCS process. The body of this document, except for th <reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-
e security considerations section, is taken directly from the PKCS #9 v2.0 or th X.690/">
e PKCS #10 v1.7 document. This memo provides information for the Internet commu
nity.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
688" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.36
88.xml">
<front>
<title>The IETF XML Registry</title>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="BCP" value="81"/>
<author initials="M." surname="Mealling" fullname="M. Mealling">
<organization/>
</author>
<date year="2004" month="January"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF st
andards which use Extensible Markup Language (XML) related items such as Namespa
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew
ork (RDF) Schemas.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc4
210" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.42
10.xml">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate Manageme
nt Protocol (CMP)</title>
<seriesInfo name="DOI" value="10.17487/RFC4210"/>
<seriesInfo name="RFC" value="4210"/>
<author initials="C." surname="Adams" fullname="C. Adams">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="T." surname="Kause" fullname="T. Kause">
<organization/>
</author>
<author initials="T." surname="Mononen" fullname="T. Mononen">
<organization/>
</author>
<date year="2005" month="September"/>
<abstract>
<t>This document describes the Internet X.509 Public Key Infrastru
cture (PKI) Certificate Management Protocol (CMP). Protocol messages are define
d for X.509v3 certificate creation and management. CMP provides on-line interac
tions between PKI components, including an exchange between a Certification Auth
ority (CA) and a client system. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5272" target="https://www.rfc-editor.org/info/rfc5
272" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.52
72.xml">
<front>
<title>Certificate Management over CMS (CMC)</title>
<seriesInfo name="DOI" value="10.17487/RFC5272"/>
<seriesInfo name="RFC" value="5272"/>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author>
<author initials="M." surname="Myers" fullname="M. Myers">
<organization/>
</author>
<date year="2008" month="June"/>
<abstract>
<t>This document defines the base syntax for CMC, a Certificate Ma
nagement protocol using the Cryptographic Message Syntax (CMS). This protocol ad
dresses two immediate needs within the Internet Public Key Infrastructure (PKI)
community:</t>
<t>1. The need for an interface to public key certification produ
cts and services based on CMS and PKCS #10 (Public Key Cryptography Standard), a
nd</t>
<t>2. The need for a PKI enrollment protocol for encryption only
keys due to algorithm or hardware design.</t>
<t>CMC also requires the use of the transport document and the req
uirements usage document along with this document for a full definition. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.60
20.xml">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
<seriesInfo name="RFC" value="6020"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author>
<date year="2010" month="October"/>
<abstract>
<t>YANG is a data modeling language used to model configuration an
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7235" target="https://www.rfc-editor.org/info/rfc7
235" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
35.xml">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title
>
<seriesInfo name="DOI" value="10.17487/RFC7235"/>
<seriesInfo name="RFC" value="7235"/>
<author initials="R." surname="Fielding" fullname="R. Fielding" role
="editor">
<organization/>
</author>
<author initials="J." surname="Reschke" fullname="J. Reschke" role="
editor">
<organization/>
</author>
<date year="2014" month="June"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on- level protocol for distributed, collaborative, hypermedia information system
s. This document defines the HTTP Authentication framework.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.79
50.xml">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
<seriesInfo name="RFC" value="7950"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author>
<date year="2016" month="August"/>
<abstract>
<t>YANG is a data modeling language used to model configuration da
ta, state data, Remote Procedure Calls, and notifications for network management
protocols. This document describes the syntax and semantics of version 1.1 of
the YANG language. YANG version 1.1 is a maintenance release of the YANG langua
ge, addressing ambiguities and defects in the original specification. There are
a small number of backward incompatibilities from YANG version 1. This documen
t also specifies the YANG mappings to the Network Configuration Protocol (NETCON
F).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.80
40.xml">
<front>
<title>RESTCONF Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
<seriesInfo name="RFC" value="8040"/>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<date year="2017" month="January"/>
<abstract>
<t>This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the datastore c
oncepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
</reference>
<reference anchor="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">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<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>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
<seriesInfo name="RFC" value="8446"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8
572" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.85
72.xml">
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>
<seriesInfo name="DOI" value="10.17487/RFC8572"/>
<seriesInfo name="RFC" value="8572"/>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization/>
</author>
<author initials="M." surname="Abrahamsson" fullname="M. Abrahamsson
">
<organization/>
</author>
<date year="2019" month="April"/>
<abstract>
<t>This document presents a technique to securely provision a netw
orking device when it is booting in a factory-default state. Variations in the
solution enable it to be used on both public and private networks. The provisio
ning steps are able to update the boot image, commit an initial configuration, a
nd execute arbitrary scripts to address auxiliary needs. The updated device is
subsequently able to establish secure connections with other systems. For insta
nce, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connec
tions with deployment-specific network management systems.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8791" target="https://www.rfc-editor.org/info/rfc8
791" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.87
91.xml">
<front>
<title>YANG Data Structure Extensions</title>
<seriesInfo name="DOI" value="10.17487/RFC8791"/>
<seriesInfo name="RFC" value="8791"/>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<author initials="M." surname="Björklund" fullname="M. Björklund">
<organization/>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<date year="2020" month="June"/>
<abstract>
<t>This document describes YANG mechanisms for defining abstract d
ata structures with YANG.</t>
</abstract>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-netconf-crypto-types.xml"/>
<!-- THE FOLLOWING LINE DOESN'T RESOLVE FOR SOME REASON:
<?rfc include="_reference.ITU.X690.2015.xml"?> -->
<!-- THE FOLLOWING IS COPIED FROM RFC 8366 -->
<reference anchor="ITU.X690.2015" target="https://www.itu.int/rec/T-REC-
X.690/">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic <title>Information technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguish ed Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguish ed
Encoding Rules (DER)</title> Encoding Rules (DER)</title>
<seriesInfo name="ITU-T Recommendation X.690," value="ISO/IEC 8825-1 <seriesInfo name="ITU-T Recommendation" value="X.690"/>
"/> <seriesInfo name="ISO/IEC" value="8825-1"/>
<author> <author>
<organization>International Telecommunication Union</organization> <organization>ITU</organization>
</author> </author>
<date month="August" year="2015"/> <date month="February" year="2021"/>
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="Std-802.1AR-2018" target="https://standards.ieee.org/
standard/802_1AR-2018.html"> <reference anchor="Std-802.1AR-2018" target="https://standards.ieee.org/
ieee/802.1AR/6995/">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks - Secu <title>IEEE Standard for Local and Metropolitan Area Networks - Secu
re Device Identity</title> re Device Identity</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group <author>
"> <organization>IEEE</organization>
<organization>IEEE SA-Standards Board</organization>
</author> </author>
<date day="14" month="June" year="2018"/> <date month="August" year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="CVE-2008-0166" target="https://nvd.nist.gov/vuln/deta il/CVE-2008-0166"> <reference anchor="CVE-2008-0166" target="https://nvd.nist.gov/vuln/deta il/CVE-2008-0166">
<front> <front>
<title>National Vulnerability Database - CVE-2008-0166</title> <title>National Vulnerability Database - CVE-2008-0166 Detail</title >
<author> <author>
<organization>National Institute of Science and Technology (NIST)< /organization> <organization>National Institute of Science and Technology (NIST)< /organization>
</author> </author>
<date day="13" month="May" year="2008"/> <date month="May" year="2008"/>
</front> </front>
</reference> </reference>
<reference anchor="MiningPsQs" target="https://www.usenix.org/conference /usenixsecurity12/technical-sessions/presentation/heninger"> <reference anchor="MiningPsQs" target="https://www.usenix.org/conference /usenixsecurity12/technical-sessions/presentation/heninger">
<front> <front>
<title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in N etwork Devices</title> <title>Mining Your Ps and Qs: Detection of Widespread Weak Keys in N etwork Devices</title>
<author> <author fullname="Nadia Heninger" initials="N." surname="Heninger">
<organization>Security'12: Proceedings of the 21st USENIX conferen
ce on Security symposium</organization>
</author>
<author fullname="Nadia Heninger">
<organization>UC San Diego</organization> <organization>UC San Diego</organization>
</author> </author>
<author fullname="Zakir Durumeric"> <author fullname="Zakir Durumeric" initials="Z." surname="Durumeric" >
<organization>University of Michigan</organization> <organization>University of Michigan</organization>
</author> </author>
<author fullname="Eric Wustrow"> <author fullname="Eric Wustrow" initials="E." surname="Wustrow">
<organization>University of Michigan</organization> <organization>University of Michigan</organization>
</author> </author>
<author fullname="J. Alex Halderman"> <author fullname="J. Alex Halderman" initials="J." surname="Halderma n">
<organization>University of Michigan</organization> <organization>University of Michigan</organization>
</author> </author>
<date month="August" year="2012"/> <date month="August" year="2012"/>
</front> </front>
<refcontent>Security'12: Proceedings of the 21st USENIX Conference on S ecurity Symposium</refcontent>
</reference> </reference>
<reference anchor="ISO.20543-2019"> <reference anchor="ISO.20543-2019">
<front> <front>
<title>Information technology -- Security techniques -- Test and ana lysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408</ title> <title>Information technology -- Security techniques -- Test and ana lysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408</ title>
<seriesInfo name="ISO" value="Draft Standard 20543-2019"/>
<author> <author>
<organization>International Organization for Standardization (ISO) </organization> <organization>International Organization for Standardization (ISO) </organization>
</author> </author>
<date month="October" year="2019"/> <date month="October" year="2019"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="20543:2019"/>
</reference> </reference>
<reference anchor="NIST.SP.800-90Ar1" target="https://nvlpubs.nist.gov/n istpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf"> <reference anchor="NIST.SP.800-90Ar1" target="https://nvlpubs.nist.gov/n istpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf">
<front> <front>
<title>Recommendation for Random Number Generation Using Determinist ic Random Bit Generators</title> <title>Recommendation for Random Number Generation Using Determinist ic Random Bit Generators</title>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/> <author initials="E" surname="Barker" fullname="Elaine B. Barker">
<seriesInfo name="NIST" value="NIST SP 800-90Ar1"/>
<author initials="Elaine B." surname="Barker" fullname="Elaine B. Ba
rker">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author initials="John M." surname="Kelsey" fullname="John M. Kelsey "> <author initials="J" surname="Kelsey" fullname="John M. Kelsey">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<date year="2015" month="June"/> <date year="2015" month="June"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/>
<seriesInfo name="NIST SP" value="800-90Ar1"/>
</reference> </reference>
<reference anchor="AIS31" target="https://www.bsi.bund.de/SharedDocs/Dow nloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_r andom_number_generators_e.pdf"> <reference anchor="AIS31" target="https://www.bsi.bund.de/SharedDocs/Dow nloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_r andom_number_generators_e.pdf">
<front> <front>
<title>A proposal for: Functionality classes for random number gener <title>A proposal for: Functionality classes for random number gener
ators, version 2.0</title> ators - Version 2.0</title>
<author>
<organization>Bundesamt für Sicherheit in der Informationstechnik
(BSI)</organization>
</author>
<author initials="W" surname="Killmann" fullname="Wolfgang Killmann" > <author initials="W" surname="Killmann" fullname="Wolfgang Killmann" >
<organization>T-Systems GEI GmbH</organization> <organization>T-Systems GEI GmbH</organization>
</author> </author>
<author initials="W." surname="Schindler" fullname="Werner Schindler "> <author initials="W." surname="Schindler" fullname="Werner Schindler ">
<organization>Bundesamt für Sicherheit in der Informationstechnik (BSI)</organization> <organization>Bundesamt für Sicherheit in der Informationstechnik (BSI)</organization>
<!-- <organization>Federal Office for Information Securit y (BSI)</organization> -->
</author> </author>
<date day="18" month="09" year="2011"/> <date month="September" year="2011"/>
</front>
</reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.40
86.xml">
<front>
<title>Randomness Requirements for Security</title>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="BCP" value="106"/>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization/>
</author>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization/>
</author>
<author initials="S." surname="Crocker" fullname="S. Crocker">
<organization/>
</author>
<date year="2005" month="June"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is d
ependent on generating secret quantities for passwords, cryptographic keys, and
similar quantities. The use of pseudo-random processes to generate secret quant
ities can result in pseudo-security. A sophisticated attacker may find it easier
to reproduce the environment that produced the secret quantities and to search
the resulting small set of possibilities than to locate the quantities in the wh
ole of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in
using poor entropy sources or traditional pseudo-random number generation techni
ques for generating such quantities. It recommends the use of truly random hard
ware techniques and shows that the existing hardware on many systems can be used
for this purpose. It provides suggestions to ameliorate the problem when a hard
ware solution is not available, and it gives examples of how large such quantiti
es need to be for some applications. This document specifies an Internet Best C
urrent Practices for the Internet Community, and requests discussion and suggest
ions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7292" target="https://www.rfc-editor.org/info/rfc7
292" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.72
92.xml">
<front>
<title>PKCS #12: Personal Information Exchange Syntax v1.1</title>
<seriesInfo name="DOI" value="10.17487/RFC7292"/>
<seriesInfo name="RFC" value="7292"/>
<author initials="K." surname="Moriarty" fullname="K. Moriarty" role
="editor">
<organization/>
</author>
<author initials="M." surname="Nystrom" fullname="M. Nystrom">
<organization/>
</author>
<author initials="S." surname="Parkinson" fullname="S. Parkinson">
<organization/>
</author>
<author initials="A." surname="Rusch" fullname="A. Rusch">
<organization/>
</author>
<author initials="M." surname="Scott" fullname="M. Scott">
<organization/>
</author>
<date year="2014" month="July"/>
<abstract>
<t>PKCS #12 v1.1 describes a transfer syntax for personal identity
information, including private keys, certificates, miscellaneous secrets, and e
xtensions. Machines, applications, browsers, Internet kiosks, and so on, that s
upport this standard will allow a user to import, export, and exercise a single
set of personal identity information. This standard supports direct transfer of
personal information under several privacy and integrity modes.</t>
<t>This document represents a republication of PKCS #12 v1.1 from
RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.83
40.xml">
<front>
<title>YANG Tree Diagrams</title>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="BCP" value="215"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger" role="ed
itor">
<organization/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for
this definition. This syntax may be updated from time to time based on the evol
ution of the YANG language.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8
407" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
07.xml">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<seriesInfo name="DOI" value="10.17487/RFC8407"/>
<seriesInfo name="RFC" value="8407"/>
<seriesInfo name="BCP" value="216"/>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/>
</author>
<date year="2018" month="October"/>
<abstract>
<t>This memo provides guidelines for authors and reviewers of spec
ifications containing YANG modules. Recommendations and procedures are defined,
which are intended to increase interoperability and usability of Network Config
uration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YA
NG modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8808" target="https://www.rfc-editor.org/info/rfc8
808" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.88
08.xml">
<front>
<title>A YANG Data Model for Factory Default Settings</title>
<seriesInfo name="DOI" value="10.17487/RFC8808"/>
<seriesInfo name="RFC" value="8808"/>
<author initials="Q." surname="Wu" fullname="Q. Wu">
<organization/>
</author>
<author initials="B." surname="Lengyel" fullname="B. Lengyel">
<organization/>
</author>
<author initials="Y." surname="Niu" fullname="Y. Niu">
<organization/>
</author>
<date year="2020" month="August"/>
<abstract>
<t>This document defines a YANG data model with the "factory-reset
" RPC to allow clients to reset a server back to its factory default condition.
It also defines an optional "factory-default" datastore to allow clients to read
the factory default configuration for the device.</t>
<t>The YANG data model in this document conforms to the Network Ma
nagement Datastore Architecture (NMDA) defined in RFC 8342.</t>
</abstract>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-netconf-keystore.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference. xml"/>
I-D.ietf-netconf-trust-anchors.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7292.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8407.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8792.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8808.
xml"/>
<reference anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc96
41">
<front>
<title>A YANG Data Model for a Truststore</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Watsen Networks</organization>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9641"/>
<seriesInfo name="DOI" value="10.17487/RFC9641"/>
</reference>
<reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9
642">
<front>
<title>A YANG Data Model for a Keystore</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Watsen Networks</organization>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9642"/>
<seriesInfo name="DOI" value="10.17487/RFC9642"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" toc="default"> <section numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank for following for lively <t>The authors would like to thank for following for lively
discussions on list and in the halls (ordered by first name): discussions on list and in the halls (ordered by first name):
Benjamin Kaduk, <contact fullname="Benjamin Kaduk"/>,
David von Oheimb, <contact fullname="Dan Romascanu"/>,
Dan Romascanu, <contact fullname="David von Oheimb"/>,
Eric Vyncke, <contact fullname="Éric Vyncke"/>,
Hendrik Brockhaus, <contact fullname="Guy Fedorkow"/>,
Guy Fedorkow, <contact fullname="Hendrik Brockhaus"/>,
Joe Clarke, <contact fullname="Joe Clarke"/>,
Meral Shirazipour, <contact fullname="Meral Shirazipour"/>,
Murray Kucherawy, <contact fullname="Murray Kucherawy"/>,
Rich Salz, <contact fullname="Rich Salz"/>,
Rob Wilton, <contact fullname="Rob Wilton"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Qin Wu, <contact fullname="Qin Wu"/>,
Yaron Sheffer, <contact fullname="Yaron Sheffer"/>,
and Zaheduzzaman Sarkar. and <contact fullname="Zaheduzzaman Sarkar"/>.
</t> </t>
</section> </section>
<section numbered="false" toc="default"> <section numbered="false" toc="default">
<name>Contributors</name> <name>Contributors</name>
<t>Special thanks go to David von Oheimb and Hendrik Brockhaus <t>Special thanks go to <contact fullname="David von Oheimb"/> and <contac t fullname="Hendrik Brockhaus"/>
for helping with the descriptions for the "cmc-csr" and "cmp-csr" for helping with the descriptions for the "cmc-csr" and "cmp-csr"
nodes.</t> nodes.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 196 change blocks. 
943 lines changed or deleted 490 lines changed or added

This html diff was produced by rfcdiff 1.48.