rfc9641.original.xml   rfc9641.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
<?rfc sortrefs="yes" ?> submissionType="IETF" ipr="trust200902" docName="draft-ietf-netconf-trust-anchor
<?rfc compact="yes"?> s-28" number="9641" updates="" obsoletes="" tocInclude="true" symRefs="true" sor
<?rfc subcompact="no"?> tRefs="true" version="3" xml:lang="en">
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?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"
submissionType="IETF" ipr="trust200902" docName="draft-ietf-netconf-trust-anchor
s-28" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title>A YANG Data Model for a Truststore</title> <title abbrev="A YANG Data Model for a Truststore">A YANG Data Model for a
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-trust-anchors-28 Truststore</title>
"/> <seriesInfo name="RFC" value="9641"/>
<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>
<date/> <date year="2024" month="October"/>
<area>Operations</area> <area>OPS</area>
<workgroup>NETCONF Working Group</workgroup> <workgroup>netconf</workgroup>
<keyword>IETF</keyword>
<abstract> <abstract>
<t>This document presents a YANG module for configuring <t>This document presents a YANG module for configuring
bags of certificates and bags of public keys that can be bags of certificates and bags of public keys that can be
referenced by other data models for trust. Notifications referenced by other data models for trust. Notifications
are sent when certificates are about to expire.</t> are sent when certificates are about to expire.</t>
</abstract> </abstract>
<note>
<name>Editorial Note (To be removed by RFC Editor)</name>
<t>This draft contains 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>AAAA</tt> --&gt; the assigned RFC value for draft-ietf-netconf-cry
pto-types</li>
<li>
<tt>BBBB</tt> --&gt; the assigned RFC value for this draft</li>
</ul>
<t>Artwork in this document contains placeholder values for the date
of publication of this draft. Please apply the following replacement:
</t>
<ul spacing="normal">
<li>
<tt>2024-03-16</tt> --&gt; the publication date of this draft</li>
</ul>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/>
contains
the text "one or more YANG modules" and, later, "modules". This text
is sourced
from a file in a context where it is unknown how many modules a draft
defines.
The text is not wrong as is, but it may be improved by stating more di
rectly how
many modules are defined.</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/>
contains
a self-reference to this draft, along with a corresponding reference i
n
the Appendix. Please replace the self-reference in this section with
"This RFC"
(or similar) and remove the self-reference in the "Normative/Informati
ve References"
section, whichever it is in.</t>
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined i
n RFC 8792.
However, nicer-to-the-eye is when the '\\' line-folding mode is used.
The AD suggested
suggested putting a request here for the RFC Editor to help convert "u
gly" '\' folded
examples to use the '\\' folding mode. "Help convert" may be interpre
ted as, identify
what looks ugly and ask the authors to make the adjustment.</t>
<t>The following Appendix section is to be removed prior to publication:
</t>
<ul spacing="normal">
<li>
<xref target="change-log"/>. Change Log</li>
</ul>
</note>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>This document presents a YANG 1.1 <xref target="RFC7950"/> module havin g <t>This document presents a YANG 1.1 <xref target="RFC7950"/> module that has
the following characteristics: the following characteristics:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>Provide a central truststore for storing raw public keys and/or cert ificates.</li> <li>Provide a central truststore for storing raw public keys and/or cert ificates.</li>
<li>Provide support for storing named bags of raw public keys and/or nam ed bags <li>Provide support for storing named bags of raw public keys and/or nam ed bags
of certificates.</li> of certificates.</li>
<li>Provide types that can be used to reference raw public keys or certi ficates <li>Provide types that can be used to reference raw public keys or certi ficates
stored in the central truststore.</li> stored in the central truststore.</li>
<li>Provide groupings that enable raw public keys and certificates to be <li>Provide groupings that enable raw public keys and certificates to be
configured inline or as references to truststore instances.</li> configured inline or as references to truststore instances.</li>
<li>Enable the truststore to be instantiated in other data models, in ad dition <li>Enable the truststore to be instantiated in other data models, in ad dition
to or in lieu of the central truststore instance.</li> to or in lieu of the central truststore instance.</li>
</ul> </ul>
<section anchor="collective-effort"> <section anchor="collective-effort">
<name>Relation to other RFCs</name> <name>Relation to Other RFCs</name>
<t>This document presents one or more YANG modules <xref target="RFC7950 <t>This document presents a YANG module <xref target="RFC7950"/>
"/> that is part of a collection of RFCs that work together
that are part of a collection of RFCs that work together to ultimately support the configuration of both the clients
to, ultimately, support the configuration of both the clients and servers of both the Network Configuration Protocol (NETCONF) <xr
and servers of both the NETCONF <xref target="RFC6241"/> and ef target="RFC6241"/> and
RESTCONF <xref target="RFC8040"/> protocols.</t> RESTCONF <xref target="RFC8040"/>.</t>
<t> The dependency relationship between the primary YANG groupings <t> The dependency relationship between the primary YANG groupings
defined in the various RFCs is presented in the below diagram. defined in the various RFCs is presented in the below diagram.
In some cases, a draft may define secondary groupings that In some cases, a document may define secondary groupings that
introduce dependencies not illustrated in the diagram. introduce dependencies not illustrated in the diagram.
The labels in the diagram are a shorthand name for the defining The labels in the diagram are shorthand names for the defining
RFC. The citation reference for shorthand name is provided below RFCs. The citation references for shorthand names are provided belo
w
the diagram.</t> the diagram.</t>
<t>Please note that the arrows in the diagram point from referencer <t>Please note that the arrows in the diagram point from referencer
to referenced. For example, the "crypto-types" RFC does not to referenced. For example, the "crypto-types" RFC does not
have any dependencies, whilst the "keystore" RFC depends on the have any dependencies, whilst the "keystore" RFC depends on the
"crypto-types" RFC.</t> "crypto-types" RFC.</t>
<artwork><![CDATA[ <artwork><![CDATA[
crypto-types crypto-types
^ ^ ^ ^
/ \ / \
/ \ / \
skipping to change at line 146 skipping to change at line 93
| | | +-----+ +---------+ | | | | +-----+ +---------+ |
| | | | | | | | | | | |
| +-----------|--------|--------------+ | | | +-----------|--------|--------------+ | |
| | | | | | | | | | | |
+-----------+ | | | | | +-----------+ | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
netconf-client-server restconf-client-server netconf-client-server restconf-client-server
]]></artwork> ]]></artwork>
<!-- RFC Editor: is there anyway to flush-left the table in PDF/HTML vie <table align="left">
ws? -->
<table>
<name>Label in Diagram to RFC Mapping</name> <name>Label in Diagram to RFC Mapping</name>
<tbody> <tbody>
<tr> <tr>
<th>Label in Diagram</th> <th>Label in Diagram</th>
<th>Originating RFC</th> <th>Reference</th>
</tr> </tr>
<tr> <tr>
<td>crypto-types</td> <td>crypto-types</td>
<td> <td>
<xref target="I-D.ietf-netconf-crypto-types"/></td> <xref target="RFC9640"/></td>
</tr> </tr>
<tr> <tr>
<td>truststore</td> <td>truststore</td>
<td> <td>
<xref target="I-D.ietf-netconf-trust-anchors"/></td> RFC 9641</td>
</tr> </tr>
<tr> <tr>
<td>keystore</td> <td>keystore</td>
<td> <td>
<xref target="I-D.ietf-netconf-keystore"/></td> <xref target="RFC9642"/></td>
</tr> </tr>
<tr> <tr>
<td>tcp-client-server</td> <td>tcp-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-tcp-client-server"/></td> <xref target="RFC9643"/></td>
</tr> </tr>
<tr> <tr>
<td>ssh-client-server</td> <td>ssh-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-ssh-client-server"/></td> <xref target="RFC9644"/></td>
</tr> </tr>
<tr> <tr>
<td>tls-client-server</td> <td>tls-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-tls-client-server"/></td> <xref target="RFC9645"/></td>
</tr> </tr>
<tr> <tr>
<td>http-client-server</td> <td>http-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-http-client-server"/></td> <xref target="I-D.ietf-netconf-http-client-server"/></td>
</tr> </tr>
<tr> <tr>
<td>netconf-client-server</td> <td>netconf-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-netconf-client-server"/></td> <xref target="I-D.ietf-netconf-netconf-client-server"/></td>
skipping to change at line 204 skipping to change at line 150
<tr> <tr>
<td>restconf-client-server</td> <td>restconf-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-restconf-client-server"/></td> <xref target="I-D.ietf-netconf-restconf-client-server"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section>
<name>Specification Language</name> <name>Specification 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"/> <xref target="RFC8174"/ NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
> 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> <section>
<name>Adherence to the NMDA</name> <name>Adherence to the NMDA</name>
<t>This document is compliant with the Network Management Datastore Arch itecture <t>This document is compliant with the Network Management Datastore Arch itecture
(NMDA) <xref target="RFC8342"/>. For instance, trust anchors instal led (NMDA) <xref target="RFC8342"/>. For instance, trust anchors instal led
during manufacturing (e.g., for trusted well-known services), are ex pected during manufacturing (e.g., for trusted, well-known services) are ex pected
to appear in &lt;operational&gt; (see <xref target="built-ins"/>).</ t> to appear in &lt;operational&gt; (see <xref target="built-ins"/>).</ t>
</section> </section>
<section> <section>
<name>Conventions</name> <name>Conventions</name>
<t>Various examples in this document use "BASE64VALUE=" as a <t>Various examples in this document use "BASE64VALUE=" as a
placeholder value for binary data that has been base64 placeholder value for binary data that has been base64
encoded (see Section 4 in <xref target="RFC4648"/>). This encoded (see <xref target="RFC7950" sectionFormat="of" section="9.8"
placeholder value is used because real base64 encoded structures />). This
placeholder value is used because real base64-encoded structures
are often many lines long and hence distracting to the example are often many lines long and hence distracting to the example
being presented.</t> being presented.</t>
<t>This document uses the adjective "central" to the word "truststore" <t> Various examples in this document use the XML
to refer to the top-level instance of the "truststore-grouping", whe <xref target="W3C.REC-xml-20081126"/> encoding. Other encodings, such as JSON
n <xref target="RFC8259"/>,
could alternatively be used.</t>
<t>Various examples in this document contain long lines that may be folde
d,
as described in <xref target="RFC8792"/>.</t>
<t>This document uses the adjective "central" with the word "truststore"
to refer to the top-level instance of the "truststore-grouping" grou
ping when
the "central-truststore-supported" feature is enabled. Please be the "central-truststore-supported" feature is enabled. Please be
aware that consuming YANG modules MAY instantiate the "truststore-gr ouping" aware that consuming YANG modules <bcp14>MAY</bcp14> instantiate the "truststore-grouping" grouping
in other locations. All such other instances are not the "central" in other locations. All such other instances are not the "central"
instance.</t> instance.</t>
</section> </section>
</section> </section>
<section> <section>
<name>The "ietf-truststore" Module</name> <name>The "ietf-truststore" Module</name>
<t>This section defines a YANG 1.1 <xref target="RFC7950"/> module called <t>This section defines a YANG 1.1 <xref target="RFC7950"/> module called
"ietf-truststore". A high-level overview of the module is provided in "ietf-truststore". A high-level overview of the module is provided in
<xref target="truststore-verview"/>. Examples illustrating the module' s use <xref target="truststore-verview"/>. Examples illustrating the module' s use
are provided in <xref target="truststore-examples">Examples</xref>. Th e YANG are provided in <xref target="truststore-examples"/> ("Example Usage") . The YANG
module itself is defined in <xref target="truststore-yang-module"/>.</ t> module itself is defined in <xref target="truststore-yang-module"/>.</ t>
<section anchor="truststore-verview"> <section anchor="truststore-verview">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>This section provides an overview of the "ietf-truststore" module <t>This section provides an overview of the "ietf-truststore" module
in terms of its features, typedefs, groupings, and protocol-accessib le in terms of its features, typedefs, groupings, and protocol-accessib le
nodes.</t> nodes.</t>
<section anchor="features" toc="exclude"> <section anchor="features" toc="exclude">
<name>Features</name> <name>Features</name>
<t>The following diagram lists all the "feature" statements <t>The following diagram lists all the "feature" statements
defined in the "ietf-truststore" module:</t> defined in the "ietf-truststore" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Features: Features:
+-- central-truststore-supported +-- central-truststore-supported
+-- inline-definitions-supported +-- inline-definitions-supported
+-- certificates +-- certificates
+-- public-keys +-- public-keys
]]></artwork> ]]></sourcecode>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section> </section>
<section anchor="typedefs" toc="exclude"> <section anchor="typedefs" toc="exclude">
<name>Typedefs</name> <name>Typedefs</name>
<t>The following diagram lists the "typedef" statements defined in <t>The following diagram lists the "typedef" statements defined in
the "ietf-truststore" module:</t> the "ietf-truststore" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Typedefs: Typedefs:
leafref leafref
+-- central-certificate-bag-ref +-- central-certificate-bag-ref
+-- central-certificate-ref +-- central-certificate-ref
+-- central-public-key-bag-ref +-- central-public-key-bag-ref
+-- central-public-key-ref +-- central-public-key-ref
]]></artwork> ]]></sourcecode>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>All the typedefs defined in the "ietf-truststore" module <li>All the typedefs defined in the "ietf-truststore" module
extend the base "leafref" type defined in <xref target="RFC7950" />.</li> extend the base "leafref" type defined in <xref target="RFC7950" />.</li>
<li>The leafrefs refer to certificates, public keys, and bags <li>The leafrefs refer to certificates, public keys, and bags
in the central truststore, when this module is implemented.</li> in the central truststore when this module is implemented.</li>
<li>These typedefs are provided as an aid to consuming <li>These typedefs are provided to aid consuming
modules that import the "ietf-truststore" module.</li> modules that import the "ietf-truststore" module.</li>
</ul> </ul>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Groupings</name> <name>Groupings</name>
<t>The "ietf-truststore" module defines the following "grouping" state ments:</t> <t>The "ietf-truststore" module defines the following "grouping" state ments:</t>
<ul spacing="compact"> <ul spacing="normal">
<li>central-certificate-ref-grouping</li> <li>central-certificate-ref-grouping</li>
<li>central-public-key-ref-grouping</li> <li>central-public-key-ref-grouping</li>
<li>inline-or-truststore-certs-grouping</li> <li>inline-or-truststore-certs-grouping</li>
<li>inline-or-truststore-public-keys-grouping</li> <li>inline-or-truststore-public-keys-grouping</li>
<li>truststore-grouping</li> <li>truststore-grouping</li>
</ul> </ul>
<t>Each of these groupings are presented in the following subsections. </t> <t>Each of these groupings are presented in the following subsections. </t>
<section anchor="central-certificate-ref-grouping"> <section anchor="central-certificate-ref-grouping">
<name>The "central-certificate-ref-grouping" Grouping</name> <name>The "central-certificate-ref-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"central-certificate-ref-grouping" grouping:</t> "central-certificate-ref-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping central-certificate-ref-grouping: grouping central-certificate-ref-grouping:
+-- certificate-bag? ts:central-certificate-bag-ref +-- certificate-bag? ts:central-certificate-bag-ref
| {central-truststore-supported,certificates}? | {central-truststore-supported,certificates}?
+-- certificate? ts:central-certificate-ref +-- certificate? ts:central-certificate-ref
{central-truststore-supported,certificates}? {central-truststore-supported,certificates}?
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "central-certificate-ref-grouping" grouping is provided <li>The "central-certificate-ref-grouping" grouping is provided
solely as convenience to consuming modules that wish to solely as a convenience to consuming modules that wish to
enable the configuration of a reference to a certificate enable the configuration of a reference to a certificate
in a certificate-bag in the truststore.</li> in a certificate-bag in the truststore.</li>
<li>The "certificate-bag" leaf uses the "central-certificate-bag-r ef" <li>The "certificate-bag" leaf uses the "central-certificate-bag-r ef"
typedef defined in <xref target="typedefs"/>.</li> typedef defined in <xref target="typedefs"/>.</li>
<li>The "certificate" leaf uses the "central-certificate-ref" <li>The "certificate" leaf uses the "central-certificate-ref"
typedef defined in <xref target="typedefs"/>.</li> typedef defined in <xref target="typedefs"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="central-public-key-ref-grouping"> <section anchor="central-public-key-ref-grouping">
<name>The "central-public-key-ref-grouping" Grouping</name> <name>The "central-public-key-ref-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"central-public-key-ref-grouping" grouping:</t> "central-public-key-ref-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping central-public-key-ref-grouping: grouping central-public-key-ref-grouping:
+-- public-key-bag? ts:central-public-key-bag-ref +-- public-key-bag? ts:central-public-key-bag-ref
| {central-truststore-supported,public-keys}? | {central-truststore-supported,public-keys}?
+-- public-key? ts:central-public-key-ref +-- public-key? ts:central-public-key-ref
{central-truststore-supported,public-keys}? {central-truststore-supported,public-keys}?
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "central-public-key-ref-grouping" grouping is provided <li>The "central-public-key-ref-grouping" grouping is provided
solely as convenience to consuming modules that wish to solely as a convenience to consuming modules that wish to
enable the configuration of a reference to a public-key enable the configuration of a reference to a public-key
in a public-key-bag in the truststore.</li> in a public-key-bag in the truststore.</li>
<li>The "public-key-bag" leaf uses the "public-key-bag-ref" <li>The "public-key-bag" leaf uses the "central-public-key-bag-ref
"
typedef defined in <xref target="typedefs"/>.</li> typedef defined in <xref target="typedefs"/>.</li>
<li>The "public-key" leaf uses the "public-key-ref" <li>The "public-key" leaf uses the "central-public-key-ref"
typedef defined in <xref target="typedefs"/>.</li> typedef defined in <xref target="typedefs"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="inline-or-truststore-certs-grouping"> <section anchor="inline-or-truststore-certs-grouping">
<name>The "inline-or-truststore-certs-grouping" Grouping</name> <name>The "inline-or-truststore-certs-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"inline-or-truststore-certs-grouping" grouping:</t> "inline-or-truststore-certs-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping inline-or-truststore-certs-grouping: grouping inline-or-truststore-certs-grouping:
+-- (inline-or-truststore) +-- (inline-or-truststore)
+--:(inline) {inline-definitions-supported}? +--:(inline) {inline-definitions-supported}?
| +-- inline-definition | +-- inline-definition
| +-- certificate* [name] | +-- certificate* [name]
| +-- name? string | +-- name string
| +---u ct:trust-anchor-cert-grouping | +---u ct:trust-anchor-cert-grouping
+--:(central-truststore) +--:(central-truststore)
{central-truststore-supported,certificates}? {central-truststore-supported,certificates}?
+-- central-truststore-reference? +-- central-truststore-reference?
ts:central-certificate-bag-ref ts:central-certificate-bag-ref
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "inline-or-truststore-certs-grouping" grouping is provided <li>The "inline-or-truststore-certs-grouping" grouping is provided
solely as convenience to consuming modules that wish to offer solely as a convenience to consuming modules that wish to offe r
an option whether a bag of certificates can be defined inline an option whether a bag of certificates can be defined inline
or as a reference to a bag in the truststore.</li> or as a reference to a bag in the truststore.</li>
<li>A "choice" statement is used to expose the various options. <li>A "choice" statement is used to expose the various options.
Each option is enabled by a "feature" statement. Additional Each option is enabled by a "feature" statement. Additional
"case" statements MAY be augmented in if, e.g., there is a "case" statements <bcp14>MAY</bcp14> be augmented in if, e.g., there is a
need to reference a bag in an alternate location.</li> need to reference a bag in an alternate location.</li>
<li>For the "inline-definition" option, the "certificate" node <li>For the "inline-definition" option, the "certificate" node
uses the "trust-anchor-cert-grouping" grouping discussed in uses the "trust-anchor-cert-grouping" grouping discussed in
<xref section="2.1.4.7" target="I-D.ietf-netconf-crypto-types" <xref section="2.1.4.8" sectionFormat="of" target="RFC9640"/>.</li
/>.</li> >
<li>For the "central-truststore" option, the "central-truststore-r <li>For the "central-truststore" option, the "central-truststore-r
eference" is an eference" node is an
instance of the "certificate-bag-ref" discussed in <xref targe instance of the "central-certificate-bag-ref" discussed in <xr
t="typedefs"/>.</li> ef target="typedefs"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="inline-or-truststore-public-keys-grouping"> <section anchor="inline-or-truststore-public-keys-grouping">
<name>The "inline-or-truststore-public-keys-grouping" Grouping</name > <name>The "inline-or-truststore-public-keys-grouping" Grouping</name >
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"inline-or-truststore-public-keys-grouping" grouping:</t> "inline-or-truststore-public-keys-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping inline-or-truststore-public-keys-grouping: grouping inline-or-truststore-public-keys-grouping:
+-- (inline-or-truststore) +-- (inline-or-truststore)
+--:(inline) {inline-definitions-supported}? +--:(inline) {inline-definitions-supported}?
| +-- inline-definition | +-- inline-definition
| +-- public-key* [name] | +-- public-key* [name]
| +-- name? string | +-- name string
| +---u ct:public-key-grouping | +---u ct:public-key-grouping
+--:(central-truststore) +--:(central-truststore)
{central-truststore-supported,public-keys}? {central-truststore-supported,public-keys}?
+-- central-truststore-reference? +-- central-truststore-reference?
ts:central-public-key-bag-ref ts:central-public-key-bag-ref
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "inline-or-truststore-public-keys-grouping" grouping is pr ovided <li>The "inline-or-truststore-public-keys-grouping" grouping is pr ovided
solely as convenience to consuming modules that wish to offer solely as a convenience to consuming modules that wish to offe r
an option whether a bag of public keys can be defined inline an option whether a bag of public keys can be defined inline
or as a reference to a bag in the truststore.</li> or as a reference to a bag in the truststore.</li>
<li>A "choice" statement is used to expose the various options. <li>A "choice" statement is used to expose the various options.
Each option is enabled by a "feature" statement. Additional Each option is enabled by a "feature" statement. Additional
"case" statements MAY be augmented in if, e.g., there is a "case" statements <bcp14>MAY</bcp14> be augmented in if, e.g., there is a
need to reference a bag in an alternate location.</li> need to reference a bag in an alternate location.</li>
<li>For the "inline-definition" option, the "public-key" node uses the <li>For the "inline-definition" option, the "public-key" node uses the
"public-key-grouping" grouping discussed in <xref section="2.1 .4.4" target="I-D.ietf-netconf-crypto-types"/>.</li> "public-key-grouping" grouping discussed in <xref section="2.1 .4.4" sectionFormat="of" target="RFC9640"/>.</li>
<li>For the "central-truststore" option, the "central-truststore-r eference" is an <li>For the "central-truststore" option, the "central-truststore-r eference" is an
instance of the "certificate-bag-ref" discussed in <xref targe t="typedefs"/>.</li> instance of the "certificate-bag-ref" discussed in <xref targe t="typedefs"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="truststore-grouping"> <section anchor="truststore-grouping">
<name>The "truststore-grouping" Grouping</name> <name>The "truststore-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>The following tree diagram <xref target="RFC8340"/> illustrates t he
"truststore-grouping" grouping:</t> "truststore-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping truststore-grouping: grouping truststore-grouping:
+-- certificate-bags {certificates}? +-- certificate-bags {certificates}?
| +-- certificate-bag* [name] | +-- certificate-bag* [name]
| +-- name? string | +-- name string
| +-- description? string | +-- description? string
| +-- certificate* [name] | +-- certificate* [name]
| +-- name? string | +-- name string
| +---u ct:trust-anchor-cert-grouping | +---u ct:trust-anchor-cert-grouping
+-- public-key-bags {public-keys}? +-- public-key-bags {public-keys}?
+-- public-key-bag* [name] +-- public-key-bag* [name]
+-- name? string +-- name string
+-- description? string +-- description? string
+-- public-key* [name] +-- public-key* [name]
+-- name? string +-- name string
+---u ct:public-key-grouping +---u ct:public-key-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "truststore-grouping" grouping defines a truststore instan ce <li>The "truststore-grouping" grouping defines a truststore instan ce
as being composed of certificates and/or public keys, both of which as being composed of certificates and/or public keys, both of which
are enabled by "feature" statements. The structure supporting are enabled by "feature" statements. The structures supportin
certificates and public keys is essentially the same, having a g
n certificates and public keys are essentially the same, having
an
outer list of "bags" containing an inner list of objects outer list of "bags" containing an inner list of objects
(certificates or public keys). The bags enable trust anchors (i.e., certificates or public keys). The bags enable trust an chors
serving a common purpose to be grouped and referenced together .</li> serving a common purpose to be grouped and referenced together .</li>
<li>For certificates, each certificate is defined by the <li>For certificates, each certificate is defined by the
"trust-anchor-cert-grouping" grouping <xref section="2.1.4.7" "trust-anchor-cert-grouping" grouping (<xref section="2.1.4.8"
target="I-D.ietf-netconf-crypto-types"/>. The "cert-data" sectionFormat="of" target="RFC9640"/>). The "cert-data"
node is a CMS structure that can be composed of a chain of one node is a Cryptographic Message Syntax (CMS) structure that ca
or n be composed of a chain of one or
more certificates. Additionally, the "certificate-expiration" more certificates. Additionally, the "certificate-expiration"
notification enables the server to alert clients when certific ates notification enables the server to alert clients when certific ates
are nearing or have already expired.</li> are nearing expiration or have already expired.</li>
<li>For public keys, each public key is defined by the <li>For public keys, each public key is defined by the
"public-key-grouping" grouping <xref section="2.1.4.4" target= "I-D.ietf-netconf-crypto-types"/>. The "public-key" "public-key-grouping" grouping (<xref section="2.1.4.4" sectio nFormat="of" target="RFC9640"/>). The "public-key"
node can be one of any number of structures specified by the node can be one of any number of structures specified by the
"public-key-format" identity node.</li> "public-key-format" identity node.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="proto-access-nodes" toc="exclude"> <section anchor="proto-access-nodes" toc="exclude">
<name>Protocol-accessible Nodes</name> <name>Protocol-Accessible Nodes</name>
<t>The following tree diagram <xref target="RFC8340"/> lists all the <t>The following tree diagram <xref target="RFC8340"/> lists all the
protocol-accessible nodes defined in the "ietf-truststore" module, without protocol-accessible nodes defined in the "ietf-truststore" module without
expanding the "grouping" statements:</t> expanding the "grouping" statements:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-truststore module: ietf-truststore
+--rw truststore {central-truststore-supported}? +--rw truststore {central-truststore-supported}?
+---u truststore-grouping +---u truststore-grouping
]]></artwork> ]]></sourcecode>
<t>The following tree diagram <xref target="RFC8340"/> lists all the <t>The following tree diagram <xref target="RFC8340"/> lists all the
protocol-accessible nodes defined in the "ietf-truststore" module, with protocol-accessible nodes defined in the "ietf-truststore" module with
all "grouping" statements expanded, enabling the truststore's full all "grouping" statements expanded, enabling the truststore's full
structure to be seen:</t> structure to be seen:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-truststore module: ietf-truststore
+--rw truststore {central-truststore-supported}? +--rw truststore {central-truststore-supported}?
+--rw certificate-bags {certificates}? +--rw certificate-bags {certificates}?
| +--rw certificate-bag* [name] | +--rw certificate-bag* [name]
| +--rw name string | +--rw name string
| +--rw description? string | +--rw description? string
| +--rw certificate* [name] | +--rw certificate* [name]
| +--rw name string | +--rw name string
| +--rw cert-data trust-anchor-cert-cms | +--rw cert-data trust-anchor-cert-cms
| +---n certificate-expiration | +---n certificate-expiration
| {certificate-expiration-notification}? | {certificate-expiration-notification}?
| +-- expiration-date yang:date-and-time | +-- expiration-date yang:date-and-time
+--rw public-key-bags {public-keys}? +--rw public-key-bags {public-keys}?
+--rw public-key-bag* [name] +--rw public-key-bag* [name]
+--rw name string +--rw name string
+--rw description? string +--rw description? string
+--rw public-key* [name] +--rw public-key* [name]
+--rw name string +--rw name string
+--rw public-key-format identityref +--rw public-key-format identityref
+--rw public-key binary +--rw public-key binary
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>Protocol-accessible nodes are those nodes that are accessible <li>Protocol-accessible nodes are those nodes that are accessible
when the module is "implemented", as described in <xref section= "5.6.5" target="RFC7950"/>.</li> when the module is "implemented", as described in <xref section= "5.6.5" sectionFormat="of" target="RFC7950"/>.</li>
<li>The protocol-accessible nodes for the "ietf-truststore" module <li>The protocol-accessible nodes for the "ietf-truststore" module
are an instance of the "truststore-grouping" grouping discussed in are instances of the "truststore-grouping" grouping discussed in
<xref target="truststore-grouping"/>.</li> <xref target="truststore-grouping"/>.</li>
<li>The top-level node "truststore" is additionally constrained <li>The top-level "truststore" node is additionally constrained
by the feature "central-truststore-supported".</li> by the "central-truststore-supported" feature.</li>
<li>The "truststore-grouping" grouping is discussed in <li>The "truststore-grouping" grouping is discussed in
<xref target="truststore-grouping"/>.</li> <xref target="truststore-grouping"/>.</li>
<li>The reason for why the "truststore-grouping" exists separate <li>The reason for why the "truststore-grouping" grouping exists sep arate
from the protocol-accessible nodes definition is to enable from the protocol-accessible nodes definition is to enable
instances of the truststore to be instantiated in other instances of the truststore to be instantiated in other
locations, as may be needed or desired by some modules.</li> locations, as may be needed or desired by some modules.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="truststore-examples"> <section anchor="truststore-examples">
<name>Example Usage</name> <name>Example Usage</name>
<t>The examples in this section are encoded using XML, such as might <t>The examples in this section are encoded using XML, such as might
be the case when using the NETCONF protocol. Other encodings MAY be the case when using the NETCONF protocol. Other encodings <bcp14> MAY</bcp14>
be used, such as JSON when using the RESTCONF protocol.</t> be used, such as JSON when using the RESTCONF protocol.</t>
<section anchor="ts-inst" toc="exclude"> <section anchor="ts-inst" toc="exclude">
<name>A Truststore Instance</name> <name>A Truststore Instance</name>
<t>This section presents an example illustrating trust anchors <t>This section presents an example illustrating trust anchors
in &lt;intended&gt;, as per <xref target="proto-access-nodes"/>. in &lt;intended&gt;, as per <xref target="proto-access-nodes"/>.
Please see <xref target="built-ins"/> for an example illustrating Please see <xref target="built-ins"/> for an example illustrating
built-in values in &lt;operational&gt;.</t> built-in values in &lt;operational&gt;.</t>
<t>The example contained in this section defines eight bags of trust <t>The example contained in this section defines eight bags of trust
anchors. There are four certificate-based bags and four public anchors. There are four certificate-based bags and four public-ke
key based bags. The following diagram provides an overview of the y-based
bags. The following diagram provides an overview of the
contents in the example:</t> contents in the example:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Certificate Bags Certificate Bags
+-- Trust anchor certs for authenticating a set of remote servers +-- Trust anchor certs for authenticating a set of remote servers
+-- End entity certs for authenticating a set of remote servers +-- End entity certs for authenticating a set of remote servers
+-- Trust anchor certs for authenticating a set of remote clients +-- Trust anchor certs for authenticating a set of remote clients
+-- End entity certs for authenticating a set of remote clients +-- End entity certs for authenticating a set of remote clients
Public Key Bags Public Key Bags
+-- SSH keys to authenticate a set of remote SSH server +-- SSH keys to authenticate a set of remote SSH servers
+-- SSH keys to authenticate a set of remote SSH clients +-- SSH keys to authenticate a set of remote SSH clients
+-- Raw public keys to authenticate a set of remote SSH server +-- Raw public keys to authenticate a set of remote SSH servers
+-- Raw public keys to authenticate a set of remote SSH clients +-- Raw public keys to authenticate a set of remote SSH clients
]]></artwork> ]]></sourcecode>
<t>Following is the full example:</t> <sourcecode type="xml"><![CDATA[
<artwork><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<truststore <truststore
xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore" xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<!-- A bag of Certificate Bags --> <!-- A bag of Certificate Bags -->
<certificate-bags> <certificate-bags>
<!-- Trust Anchor Certs for Authenticating Servers --> <!-- Trust Anchor Certs for Authenticating Servers -->
<certificate-bag> <certificate-bag>
<name>trusted-server-ca-certs</name> <name>trusted-server-ca-certs</name>
<description> <description>
Trust anchors (i.e. CA certs) used to authenticate server Trust anchors (i.e., CA certs) used to authenticate server
certificates. A server certificate is authenticated if its certificates. A server certificate is authenticated if its
end-entity certificate has a chain of trust to one of these end-entity certificate has a chain of trust to one of these
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>Server Cert Issuer #1</name> <name>Server Cert Issuer #1</name>
<cert-data>BASE64VALUE=</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Server Cert Issuer #2</name> <name>Server Cert Issuer #2</name>
skipping to change at line 589 skipping to change at line 537
<certificate> <certificate>
<name>My Application #2</name> <name>My Application #2</name>
<cert-data>BASE64VALUE=</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
<!-- Trust Anchor Certs for Authenticating Clients --> <!-- Trust Anchor Certs for Authenticating Clients -->
<certificate-bag> <certificate-bag>
<name>trusted-client-ca-certs</name> <name>trusted-client-ca-certs</name>
<description> <description>
Trust anchors (i.e. CA certs) used to authenticate client Trust anchors (i.e., CA certs) used to authenticate client
certificates. A client certificate is authenticated if its certificates. A client certificate is authenticated if its
end-entity certificate has a chain of trust to one of these end-entity certificate has a chain of trust to one of these
certificates. certificates.
</description> </description>
<certificate> <certificate>
<name>Client Identity Issuer #1</name> <name>Client Identity Issuer #1</name>
<cert-data>BASE64VALUE=</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Client Identity Issuer #2</name> <name>Client Identity Issuer #2</name>
skipping to change at line 709 skipping to change at line 657
</public-key> </public-key>
<public-key> <public-key>
<name>Raw Public Key #2</name> <name>Raw Public Key #2</name>
<public-key-format>ct:subject-public-key-info-format</public\ <public-key-format>ct:subject-public-key-info-format</public\
-key-format> -key-format>
<public-key>BASE64VALUE=</public-key> <public-key>BASE64VALUE=</public-key>
</public-key> </public-key>
</public-key-bag> </public-key-bag>
</public-key-bags> </public-key-bags>
</truststore> </truststore>
]]></artwork> ]]></sourcecode>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>A Certificate Expiration Notification</name> <name>A Certificate Expiration Notification</name>
<t>The following example illustrates the "certificate-expiration" <t>The following example illustrates the "certificate-expiration"
notification (per <xref section="2.1.4.6" target="I-D.ietf-netconf notification (per <xref section="2.1.4.7" sectionFormat="of" targe
-crypto-types"/>) t="RFC9640"/>)
for a certificate configured in the truststore in <xref target="ts for a certificate configured in the truststore described in <xref targ
-inst"/>.</t> et="ts-inst"/>.</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2018-05-25T00:01:00Z</eventTime> <eventTime>2018-05-25T00:01:00Z</eventTime>
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"> <truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
<certificate-bags> <certificate-bags>
<certificate-bag> <certificate-bag>
<name>trusted-client-ee-certs</name> <name>trusted-client-ee-certs</name>
<certificate> <certificate>
<name>George Jetson</name> <name>George Jetson</name>
<certificate-expiration> <certificate-expiration>
<expiration-date>2024-01-05T14:18:53-05:00</expiration-d\ <expiration-date>2024-01-05T14:18:53-05:00</expiration-d\
ate> ate>
</certificate-expiration> </certificate-expiration>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
</certificate-bags> </certificate-bags>
</truststore> </truststore>
</notification> </notification>
]]></sourcecode>
]]></artwork>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>The "Local or Truststore" Groupings</name> <name>The "Inline or Truststore" Groupings</name>
<t>This section illustrates the various "inline-or-truststore" groupin gs <t>This section illustrates the various "inline-or-truststore" groupin gs
defined in the "ietf-truststore" module, specifically the defined in the "ietf-truststore" module, specifically the
"inline-or-truststore-certs-grouping" "inline-or-truststore-certs-grouping"
(<xref target="inline-or-truststore-certs-grouping"/>) and (<xref target="inline-or-truststore-certs-grouping"/>) and
"inline-or-truststore-public-keys-grouping" "inline-or-truststore-public-keys-grouping"
(<xref target="inline-or-truststore-public-keys-grouping"/>) (<xref target="inline-or-truststore-public-keys-grouping"/>)
groupings.</t> groupings.</t>
<t>These examples assume the existence of an example module called "ex -truststore-usage" <t>These examples assume the existence of an example module called "ex -truststore-usage"
having the namespace "https://example.com/ns/example-truststore-us that has the namespace "https://example.com/ns/example-truststore-
age".</t> usage".</t>
<t>The ex-truststore-usage module is first presented using tree diagra <t>The "ex-truststore-usage" module is first presented using tree diag
ms rams
<xref target="RFC8340"/>, followed by an instance example illustra ting <xref target="RFC8340"/>, followed by an instance example illustra ting
all the "inline-or-truststore" groupings in use, followed by the Y ANG all the "inline-or-truststore" groupings in use, followed by the Y ANG
module itself.</t> module itself.</t>
<t>The following tree diagram illustrates "ex-truststore-usage" withou t <t>The following tree diagram illustrates the "ex-truststore-usage" mo dule without
expanding the "grouping" statements:</t> expanding the "grouping" statements:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ex-truststore-usage module: ex-truststore-usage
+--rw truststore-usage +--rw truststore-usage
+--rw cert* [name] +--rw cert* [name]
| +--rw name string | +--rw name string
| +---u ts:inline-or-truststore-certs-grouping | +---u ts:inline-or-truststore-certs-grouping
+--rw public-key* [name] +--rw public-key* [name]
+--rw name string +--rw name string
+---u ts:inline-or-truststore-public-keys-grouping +---u ts:inline-or-truststore-public-keys-grouping
]]></artwork> ]]></sourcecode>
<t>The following tree diagram illustrates the "ex-truststore-usage" <t>The following tree diagram illustrates the "ex-truststore-usage"
module, with all "grouping" statements expanded, enabling the module with all "grouping" statements expanded, enabling the
truststore's full structure to be seen:</t> truststore's full structure to be seen:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ex-truststore-usage module: ex-truststore-usage
+--rw truststore-usage +--rw truststore-usage
+--rw cert* [name] +--rw cert* [name]
| +--rw name string | +--rw name string
| +--rw (inline-or-truststore) | +--rw (inline-or-truststore)
| +--:(inline) {inline-definitions-supported}? | +--:(inline) {inline-definitions-supported}?
| | +--rw inline-definition | | +--rw inline-definition
| | +--rw certificate* [name] | | +--rw certificate* [name]
| | +--rw name string | | +--rw name string
| | +--rw cert-data | | +--rw cert-data
skipping to change at line 802 skipping to change at line 749
+--:(inline) {inline-definitions-supported}? +--:(inline) {inline-definitions-supported}?
| +--rw inline-definition | +--rw inline-definition
| +--rw public-key* [name] | +--rw public-key* [name]
| +--rw name string | +--rw name string
| +--rw public-key-format identityref | +--rw public-key-format identityref
| +--rw public-key binary | +--rw public-key binary
+--:(central-truststore) +--:(central-truststore)
{central-truststore-supported,public-keys}? {central-truststore-supported,public-keys}?
+--rw central-truststore-reference? +--rw central-truststore-reference?
ts:central-public-key-bag-ref ts:central-public-key-bag-ref
]]></artwork> ]]></sourcecode>
<t>The following example provides two equivalent instances of <t>The following example provides two equivalent instances of
each grouping, the first being a reference to a truststore each grouping, the first being a reference to a truststore
and the second being defined inline. The instance having and the second being defined inline. The instance having
a reference to a truststore is consistent with the truststore a reference to a truststore is consistent with the truststore
defined in <xref target="ts-inst"/>. The two instances are defined in <xref target="ts-inst"/>. The two instances are
equivalent, as the inlined instance example contains equivalent, as the inlined instance example contains
the same values defined by the truststore instance referenced the same values defined by the truststore instance referenced
by its sibling example.</t> by its sibling example.</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<truststore-usage <truststore-usage
xmlns="https://example.com/ns/example-truststore-usage" xmlns="https://example.com/ns/example-truststore-usage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<!-- The following two equivalent examples illustrate --> <!-- The following two equivalent examples illustrate -->
<!-- the "inline-or-truststore-certs-grouping" grouping: --> <!-- the "inline-or-truststore-certs-grouping" grouping: -->
<cert> <cert>
<name>example 1a</name> <name>example 1a</name>
<central-truststore-reference>trusted-client-ca-certs</central-t\ <central-truststore-reference>trusted-client-ca-certs</central-t\
ruststore-reference> ruststore-reference>
</cert> </cert>
<cert> <cert>
<name>example 1b</name> <name>example 1b</name>
<inline-definition> <inline-definition>
<name>my-trusted-client-ca-certs</name>
<certificate> <certificate>
<name>Client Identity Issuer #1</name> <name>Client Identity Issuer #1</name>
<cert>BASE64VALUE=</cert> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Client Identity Issuer #2</name> <name>Client Identity Issuer #2</name>
<cert>BASE64VALUE=</cert> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</inline-definition> </inline-definition>
</cert> </cert>
<!-- The following two equivalent examples illustrate the --> <!-- The following two equivalent examples illustrate the -->
<!-- "inline-or-truststore-public-keys-grouping" grouping: --> <!-- "inline-or-truststore-public-keys-grouping" grouping: -->
<public-key> <public-key>
<name>example 2a</name> <name>example 2a</name>
<central-truststore-reference>trusted-ssh-public-keys</central-t\ <central-truststore-reference>trusted-ssh-public-keys</central-t\
ruststore-reference> ruststore-reference>
</public-key> </public-key>
<public-key> <public-key>
<name>example 2b</name> <name>example 2b</name>
<inline-definition> <inline-definition>
<name>trusted-ssh-public-keys</name>
<public-key> <public-key>
<name>corp-fw1</name> <name>corp-fw1</name>
<public-key-format> <public-key-format>ct:ssh-public-key-format</public-key-form\
ct:ssh-public-key-format at>
</public-key-format>
<public-key>BASE64VALUE=</public-key> <public-key>BASE64VALUE=</public-key>
</public-key> </public-key>
<public-key> <public-key>
<name>corp-fw2</name> <name>corp-fw2</name>
<public-key-format> <public-key-format>ct:ssh-public-key-format</public-key-form\
ct:ssh-public-key-format at>
</public-key-format>
<public-key>BASE64VALUE=</public-key> <public-key>BASE64VALUE=</public-key>
</public-key> </public-key>
</inline-definition> </inline-definition>
</public-key> </public-key>
</truststore-usage> </truststore-usage>
]]></artwork> ]]></sourcecode>
<t>Following is the "ex-truststore-usage" module's YANG definition:</t > <t>Following is the "ex-truststore-usage" module's YANG definition:</t >
<artwork><![CDATA[ <sourcecode type="yang"><![CDATA[
module ex-truststore-usage { module ex-truststore-usage {
yang-version 1.1; yang-version 1.1;
namespace "https://example.com/ns/example-truststore-usage"; namespace "https://example.com/ns/example-truststore-usage";
prefix etu; prefix etu;
import ietf-truststore { import ietf-truststore {
prefix ts; prefix ts;
reference reference
"RFC BBBB: A YANG Data Model for a Truststore"; "RFC 9641: A YANG Data Model for a Truststore";
} }
organization organization
"Example Corporation"; "Example Corporation";
contact contact
"Author: YANG Designer <mailto:yang.designer@example.com>"; "Author: YANG Designer <mailto:yang.designer@example.com>";
description description
"This example module illustrates notable groupings defined "This example module illustrates notable groupings defined
in the 'ietf-truststore' module."; in the 'ietf-truststore' module.";
revision 2024-03-16 { revision 2024-03-16 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC BBBB: A YANG Data Model for a Truststore"; "RFC 9641: A YANG Data Model for a Truststore";
} }
container truststore-usage { container truststore-usage {
description description
"An illustration of the various truststore groupings."; "An illustration of the various truststore groupings.";
list cert { list cert {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
description description
skipping to change at line 933 skipping to change at line 876
description description
"An arbitrary name for this cert."; "An arbitrary name for this cert.";
} }
uses ts:inline-or-truststore-public-keys-grouping; uses ts:inline-or-truststore-public-keys-grouping;
description description
"A public key that may be configured locally or be "A public key that may be configured locally or be
a reference to a public key in the truststore."; a reference to a public key in the truststore.";
} }
} }
} }
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="truststore-yang-module"> <section anchor="truststore-yang-module">
<name>YANG Module</name> <name>YANG Module</name>
<t>This YANG module imports modules from <xref target="RFC8341"/> <t>This YANG module imports modules from <xref target="RFC8341"/>
and <xref target="I-D.ietf-netconf-crypto-types"/>.</t> and <xref target="RFC9640"/>.</t>
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-truststore@2024-03
-16.yang"</t> <sourcecode type="yang" name="ietf-truststore@2024-03-16.yang" markers="
<artwork><![CDATA[ true"><![CDATA[
module ietf-truststore { module ietf-truststore {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; namespace "urn:ietf:params:xml:ns:yang:ietf-truststore";
prefix ts; prefix ts;
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control Model"; "RFC 8341: Network Configuration Access Control Model";
} }
skipping to change at line 952 skipping to change at line 895
module ietf-truststore { module ietf-truststore {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-truststore"; namespace "urn:ietf:params:xml:ns:yang:ietf-truststore";
prefix ts; prefix ts;
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control Model"; "RFC 8341: Network Configuration Access Control Model";
} }
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>
Author : Kent Watsen <kent+ietf@watsen.net>"; Author: Kent Watsen <kent+ietf@watsen.net>";
description description
"This module defines a 'truststore' to centralize management "This module defines a 'truststore' to centralize management
of trust anchors including certificates and public keys. of trust anchors, including certificates and public keys.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2024 IETF Trust and the persons identified Copyright (c) 2024 IETF Trust and the persons identified
as authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC BBBB This version of this YANG module is part of RFC 9641
(https://www.rfc-editor.org/info/rfcBBBB); see the RFC (https://www.rfc-editor.org/info/rfc9641); see the RFC
itself for full legal notices. itself for full legal notices.";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2024-03-16 { revision 2024-03-16 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC BBBB: A YANG Data Model for a Truststore"; "RFC 9641: A YANG Data Model for a Truststore";
} }
/****************/ /****************/
/* Features */ /* Features */
/****************/ /****************/
feature central-truststore-supported { feature central-truststore-supported {
description description
"The 'central-truststore-supported' feature indicates that "The 'central-truststore-supported' feature indicates that
the server supports the truststore (i.e., implements the the server supports the truststore (i.e., implements the
'ietf-truststore' module)."; 'ietf-truststore' module).";
} }
feature inline-definitions-supported { feature inline-definitions-supported {
description description
"The 'inline-definitions-supported' feature indicates that "The 'inline-definitions-supported' feature indicates that
the server supports locally-defined trust anchors."; the server supports locally defined trust anchors.";
} }
feature certificates { feature certificates {
description description
"The 'certificates' feature indicates that the server "The 'certificates' feature indicates that the server
implements the /truststore/certificate-bags subtree."; implements the /truststore/certificate-bags subtree.";
} }
feature public-keys { feature public-keys {
description description
skipping to change at line 1050 skipping to change at line 990
} }
typedef central-certificate-ref { typedef central-certificate-ref {
type leafref { type leafref {
path "/ts:truststore/ts:certificate-bags/ts:certificate-bag" path "/ts:truststore/ts:certificate-bags/ts:certificate-bag"
+ "[ts:name = current()/../certificate-bag]/" + "[ts:name = current()/../certificate-bag]/"
+ "ts:certificate/ts:name"; + "ts:certificate/ts:name";
} }
description description
"This typedef defines a reference to a specific certificate "This typedef defines a reference to a specific certificate
in a certificate bag in the central truststore. This typedef in a certificate bag in the central truststore. This typedef
requires that there exist a sibling 'leaf' node called requires that there exist a sibling 'leaf' node called
'certificate-bag' that SHOULD have the typedef 'certificate-bag' that SHOULD have the
'central-certificate-bag-ref'."; 'central-certificate-bag-ref' typedef.";
} }
typedef central-public-key-bag-ref { typedef central-public-key-bag-ref {
type leafref { type leafref {
path "/ts:truststore/ts:public-key-bags/" path "/ts:truststore/ts:public-key-bags/"
+ "ts:public-key-bag/ts:name"; + "ts:public-key-bag/ts:name";
} }
description description
"This typedef defines a reference to a public key bag "This typedef defines a reference to a public key bag
in the central truststore."; in the central truststore.";
skipping to change at line 1076 skipping to change at line 1016
typedef central-public-key-ref { typedef central-public-key-ref {
type leafref { type leafref {
path "/ts:truststore/ts:public-key-bags/ts:public-key-bag" path "/ts:truststore/ts:public-key-bags/ts:public-key-bag"
+ "[ts:name = current()/../public-key-bag]/" + "[ts:name = current()/../public-key-bag]/"
+ "ts:public-key/ts:name"; + "ts:public-key/ts:name";
} }
description description
"This typedef defines a reference to a specific public key "This typedef defines a reference to a specific public key
in a public key bag in the truststore. This typedef in a public key bag in the truststore. This typedef
requires that there exist a sibling 'leaf' node called requires that there exist a sibling 'leaf' node called
'public-key-bag' that SHOULD have the typedef 'public-key-bag' SHOULD have the
'central-public-key-bag-ref'."; 'central-public-key-bag-ref' typedef.";
} }
/*****************/ /*****************/
/* Groupings */ /* Groupings */
/*****************/ /*****************/
// *-ref groupings // *-ref groupings
grouping central-certificate-ref-grouping { grouping central-certificate-ref-grouping {
description description
"Grouping for the reference to a certificate in a "Grouping for the reference to a certificate in a
certificate-bag in the central truststore."; certificate-bag in the central truststore.";
leaf certificate-bag { leaf certificate-bag {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "central-truststore-supported"; if-feature "central-truststore-supported";
if-feature "certificates"; if-feature "certificates";
type ts:central-certificate-bag-ref; type ts:central-certificate-bag-ref;
must "../certificate"; must '../certificate';
description description
"Reference to a certificate-bag in the truststore."; "Reference to a certificate-bag in the truststore.";
} }
leaf certificate { leaf certificate {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "central-truststore-supported"; if-feature "central-truststore-supported";
if-feature "certificates"; if-feature "certificates";
type ts:central-certificate-ref; type ts:central-certificate-ref;
must "../certificate-bag"; must '../certificate-bag';
description description
"Reference to a specific certificate in the "Reference to a specific certificate in the
referenced certificate-bag."; referenced certificate-bag.";
} }
} }
grouping central-public-key-ref-grouping { grouping central-public-key-ref-grouping {
description description
"Grouping for the reference to a public key in a "Grouping for the reference to a public key in a
public-key-bag in the central truststore."; public-key-bag in the central truststore.";
leaf public-key-bag { leaf public-key-bag {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "central-truststore-supported"; if-feature "central-truststore-supported";
if-feature "public-keys"; if-feature "public-keys";
type ts:central-public-key-bag-ref; type ts:central-public-key-bag-ref;
description description
"Reference of a public key bag in the truststore including "Reference of a public key bag in the truststore, including
the certificate to authenticate the TLS client."; the certificate to authenticate the TLS client.";
} }
leaf public-key { leaf public-key {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "central-truststore-supported"; if-feature "central-truststore-supported";
if-feature "public-keys"; if-feature "public-keys";
type ts:central-public-key-ref; type ts:central-public-key-ref;
description description
"Reference to a specific public key in the "Reference to a specific public key in the
referenced public-key-bag."; referenced public-key-bag.";
} }
} }
// inline-or-truststore-* groupings // inline-or-truststore-* groupings
grouping inline-or-truststore-certs-grouping { grouping inline-or-truststore-certs-grouping {
description description
"A grouping for the configuration of a list of certificates. "A grouping for the configuration of a list of certificates.
The list of certificate may be defined inline or as a The list of certificates may be defined inline or as a
reference to a certificate bag in the central truststore. reference to a certificate bag in the central truststore.
Servers that wish to define alternate truststore locations Servers that wish to define alternate truststore locations
MUST augment in custom 'case' statements enabling MUST augment in custom 'case' statements, enabling
references to those alternate truststore locations."; references to those alternate truststore locations.";
choice inline-or-truststore { choice inline-or-truststore {
nacm:default-deny-write; nacm:default-deny-write;
mandatory true; mandatory true;
description description
"A choice between an inlined definition and a definition "A choice between an inlined definition and a definition
that exists in the truststore."; that exists in the truststore.";
case inline { case inline {
if-feature "inline-definitions-supported"; if-feature "inline-definitions-supported";
container inline-definition { container inline-definition {
skipping to change at line 1191 skipping to change at line 1130
description description
"A reference to a certificate bag that exists in the "A reference to a certificate bag that exists in the
central truststore."; central truststore.";
} }
} }
} }
} }
grouping inline-or-truststore-public-keys-grouping { grouping inline-or-truststore-public-keys-grouping {
description description
"A grouping that allows the public keys to be either "A grouping that allows the public keys to either be
configured locally, within the using data model, or be a configured locally, within the data model being used, or be a
reference to a public key bag stored in the truststore. reference to a public key bag stored in the truststore.
Servers that wish to define alternate truststore locations Servers that wish to define alternate truststore locations
SHOULD augment in custom 'case' statements enabling SHOULD augment in custom 'case' statement, enabling
references to those alternate truststore locations."; references to those alternate truststore locations.";
choice inline-or-truststore { choice inline-or-truststore {
nacm:default-deny-write; nacm:default-deny-write;
mandatory true; mandatory true;
description description
"A choice between an inlined definition and a definition "A choice between an inlined definition and a definition
that exists in the truststore."; that exists in the truststore.";
case inline { case inline {
if-feature "inline-definitions-supported"; if-feature "inline-definitions-supported";
container inline-definition { container inline-definition {
skipping to change at line 1295 skipping to change at line 1234
container public-key-bags { container public-key-bags {
nacm:default-deny-write; nacm:default-deny-write;
if-feature "public-keys"; if-feature "public-keys";
description description
"A collection of public key bags."; "A collection of public key bags.";
list public-key-bag { list public-key-bag {
key "name"; key "name";
description description
"A bag of public keys. Each bag of keys SHOULD be for "A bag of public keys. Each bag of keys SHOULD be for
a specific purpose. For instance, one bag could be used a specific purpose. For instance, one bag could be used
authenticate a specific set of servers, while another to authenticate a specific set of servers, while another
could be used to authenticate a specific set of clients."; could be used to authenticate a specific set of clients.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for this bag of public keys."; "An arbitrary name for this bag of public keys.";
} }
leaf description { leaf description {
type string; type string;
description description
"A description for this bag public keys. The "A description for this bag of public keys. The
intended purpose for the bag MUST be described."; intended purpose for the bag MUST be described.";
} }
list public-key { list public-key {
key "name"; key "name";
description description
"A public key."; "A public key.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for this public key."; "An arbitrary name for this public key.";
} }
uses ct:public-key-grouping; uses ct:public-key-grouping;
} }
} }
} }
} }
/*********************************/ /*********************************/
/* Protocol accessible nodes */ /* Protocol-accessible nodes */
/*********************************/ /*********************************/
container truststore { container truststore {
if-feature central-truststore-supported; if-feature "central-truststore-supported";
nacm:default-deny-write; nacm:default-deny-write;
description description
"The truststore contains bags of certificates and "The truststore contains bags of certificates and
public keys."; public keys.";
uses truststore-grouping; uses truststore-grouping;
} }
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
</section> </section>
<section anchor="built-ins"> <section anchor="built-ins">
<name>Support for Built-in Trust Anchors</name> <name>Support for Built-In Trust Anchors</name>
<t>In some implementations, a server may define some built-in trust anchor s. <t>In some implementations, a server may define some built-in trust anchor s.
For instance, there may be built-in trust anchors enabling the server to For instance, there may be built-in trust anchors enabling the server to
securely connect to well-known services (e.g., an SZTP <xref target="R securely connect to well-known services (e.g., a Secure Zero-Touch Pro
FC8572"/> visioning (SZTP) <xref target="RFC8572"/>
bootstrap server) or public CA certificates to connect to arbitrary We bootstrap server) or public Certification Authority (CA) certificates
b to connect to arbitrary web
services using public PKI.</t> services using PKI.</t>
<t>Built-in trust anchors are expected to be set by a vendor-specific proc ess. <t>Built-in trust anchors are expected to be set by a vendor-specific proc ess.
Any ability for operators to set and/or modify built-in trust anchors is outside the Any ability for operators to set and/or modify built-in trust anchors is outside the
scope of this document.</t> scope of this document.</t>
<t>The primary characteristic of the built-in trust anchors is that they a re <t>The primary characteristic of the built-in trust anchors is that they a re
provided by the server, as opposed to configuration. As such, they ar e present in provided by the server, as opposed to configuration. As such, they ar e present in
&lt;operational&gt; (<xref section="5.3" target="RFC8342"/>), and &lt; system&gt; &lt;operational&gt; (<xref section="5.3" sectionFormat="of" target="RF C8342"/>) and &lt;system&gt;
<xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t> <xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t>
<t>The example below illustrates what the truststore in &lt;operational&gt ; <t>The example below illustrates what the truststore in &lt;operational&gt ;
might look like for a server in its factory default state. Note that the might look like for a server in its factory default state. Note that the
built-in trust anchor bags have the "or:origin" annotation value "or:s built-in trust anchor bags have the "or:origin" annotation value "or:syste
ystem".</t> m".</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
<truststore <truststore
xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore" xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types" xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended"> or:origin="or:intended">
<certificate-bags> <certificate-bags>
<certificate-bag or:origin="or:system"> <certificate-bag or:origin="or:system">
<name>Built-In Manufacturer Trust Anchor Certificates</name> <name>Built-In Manufacturer Trust Anchor Certificates</name>
<description> <description>
skipping to change at line 1401 skipping to change at line 1339
<cert-data>BASE64VALUE=</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
<certificate> <certificate>
<name>Public Root CA Cert 3</name> <name>Public Root CA Cert 3</name>
<cert-data>BASE64VALUE=</cert-data> <cert-data>BASE64VALUE=</cert-data>
</certificate> </certificate>
</certificate-bag> </certificate-bag>
</certificate-bags> </certificate-bags>
</truststore> </truststore>
]]></artwork> ]]></sourcecode>
<!--
<t>Built-in bags of trust anchors and/or specific trust anchors, that ar
e
referenced by configuration (e.g., a "leafref"), MUST be present in a
datastore in order for the datastore to be valid.</t>
<t>Built-in bags and/or their trust anchors MAY be copied into other par
ts
of the configuration but, by doing so, they lose their association to
the
built-in entries and any assurances afforded by knowing they are/were
built-in.</t>
<t>The following example illustrates how a single built-in public CA
certificate from the previous example has been propagated to &lt;inten
ded&gt;:</t>
<t>
<figure>
<artwork><![CDATA[
<truststore
xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<certificate-bags>
<certificate-bag>
<name>Built-In Public Trust Anchor Certificates</name>
<description>
Certificates built into the device for authenticating
certificates issued by public certificate authorities,
such as the end-entity certificate for web servers.
Only the subset of the certificates that are referenced
by other configuration nodes need to be copied. For
instance, only "Public Root CA Cert 3" is present here.
No new certificates can be added, nor existing certificate
values changed. Missing certificates have no effect on
"operational" when the configuration is applied.
</description>
<certificate>
<name>Public Root CA Cert 3</name>
<cert-data>BASE64VALUE=</cert-data>
</certificate>
</certificate-bag>
</certificate-bags>
</truststore>
]]></artwork>
</figure>
</t>
-->
</section> </section>
<section> <section>
<name>Security Considerations</name> <name>Security Considerations</name>
<section> <section>
<name>Security of Data at Rest</name> <name>Security of Data at Rest</name>
<t>The YANG module defined in this document defines a mechanism called a <t>The YANG module specified in this document defines a mechanism called a
"truststore" that, by its name, suggests that its contents are prote cted "truststore" that, by its name, suggests that its contents are prote cted
from unauthorized modification.</t> from unauthorized modification.</t>
<t>Security controls for the API (i.e., data in motion) are <t>Security controls for the API (i.e., data in motion) are
discussed in <xref target="sec-mod"/>, but controls for the discussed in <xref target="sec-mod"/>, but controls for the
data at rest (e.g., on disk) cannot be specified by the YANG module. </t> data at rest (e.g., on disk) cannot be specified by the YANG module. </t>
<t>In order to satisfy the expectations of a "truststore", server <t>In order to satisfy the expectations of a "truststore", server
implementations MUST ensure that the truststore contents are protect ed implementations <bcp14>MUST</bcp14> ensure that the truststore conte nts are protected
from unauthorized modifications when at rest.</t> from unauthorized modifications when at rest.</t>
</section> </section>
<section> <section>
<name>Unconstrained Public Key Usage</name> <name>Unconstrained Public Key Usage</name>
<t>This module enables the configuration of public keys without <t>This module enables the configuration of public keys without
constraints on their usage, e.g., what operations the key is constraints on their usage, e.g., what operations the key is
allowed to be used for (encryption, verification, both).</t> allowed to be used for (encryption, verification, or both).</t>
<t>Trust anchors configured via this module are implicitly trusted <t>Trust anchors configured via this module are implicitly trusted
to validate certification paths that may include any name, be to validate certification paths that may include any name, be
used for any purpose, subject to constraints imposed used for any purpose, or be subject to constraints imposed
by an intermediate CA or by context in which the truststore is by an intermediate CA or by context in which the truststore is
used. Implementations are free to use alternative or auxiliary used. Implementations are free to use alternative or auxiliary
structures and validation rules to define constraints that structures and validation rules to define constraints that
limit the applicability of a trust anchor.</t> limit the applicability of a trust anchor.</t>
</section> </section>
<section anchor="sec-mod"> <section anchor="sec-mod">
<name>Considerations for the "ietf-truststore" YANG Module</name> <name>Considerations for the "ietf-truststore" YANG Module</name>
<t>This section follows the template defined in <xref section="3.7.1" ta <t>This section is modeled after the template defined in <xref section="
rget="RFC8407"/>.</t> 3.7.1" sectionFormat="of" target="RFC8407"/>.</t>
<t>The YANG module defined in this document is designed to be accessed v <t>The "ietf-truststore" YANG module defines "grouping" and "container"
ia YANG statements that are designed to be accessed via YANG-based management protocols
based management protocols, such as NETCONF <xref target="RFC6241"/> , such as NETCONF <xref target="RFC6241"/> and
and RESTCONF <xref target="RFC8040"/>. These protocols have mandatory-t
RESTCONF <xref target="RFC8040"/>. Both of these protocols have man o-implement
datory-to-implement secure transport layers (e.g., Secure Shell (SSH) <xref target="RFC4
secure transport layers (e.g., SSH, TLS) with mutual authentication. 252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and man
</t> datory-to-implement mutual authentication.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> prov <t>The Network Configuration Access Control Model (NACM) <xref target="R
ides the means FC8341"/> provides the means
to restrict access for particular users to a pre-configured subset o to restrict access for particular users to a preconfigured subset of all
f all available available
protocol operations and content.</t> protocol operations and content.</t>
<t>Please be aware that this YANG module uses groupings from <t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules review the security considerations for dependent YANG modules
for information as to which nodes may be considered sensitive for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t> or vulnerable in network environments.</t>
<t>Most of the readable data nodes defined in this YANG module <t>Most of the readable data nodes defined in this YANG module
are not considered sensitive or vulnerable in network environments. are not considered sensitive or vulnerable in network environments.
However, the "cert-data" node uses the NACM "default-deny-all" However, the "cert-data" node uses the NACM "default-deny-all"
extension, for reasons described in <xref section="3.9" target="I-D. ietf-netconf-crypto-types"/>.</t> extension for reasons described in <xref section="3.8" sectionFormat ="of" target="RFC9640"/>.</t>
<t>All the writable data nodes defined by this module, both in the <t>All the writable data nodes defined by this module, both in the
"grouping" statements as well as the protocol-accessible "truststore " "grouping" statements as well as the protocol-accessible "truststore "
instance, may be considered sensitive or vulnerable in some network instance, may be considered sensitive or vulnerable in some network
environments. For instance, any modification to a trust anchor or environments. For instance, any modification to a trust anchor or
reference to a trust anchor may dramatically alter the implemented reference to a trust anchor may dramatically alter the implemented
security policy. For this reason, the NACM extension "default-deny- write" security policy. For this reason, the NACM "default-deny-write" ext ension
has been set for all data nodes defined in this module.</t> has been set for all data nodes defined in this module.</t>
<t>This module does not define any "rpc" or "action" statements, and <t>This module does not define any "rpc" or "action" statements, and
thus the security considerations for such is not provided here.</t> thus, the security considerations for such are not provided here.</t >
</section> </section>
</section> </section>
<section> <section>
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section> <section>
<name>The "IETF XML" Registry</name> <name>The IETF XML Registry</name>
<t>This document registers one URI in the "ns" subregistry of <t>IANA has registered the following URI in the "ns" registry defined of
the IETF XML Registry <xref target="RFC3688"/>. Following the the "IETF XML Registry" <xref target="RFC3688"/>.</t>
format in <xref target="RFC3688"/>, the following registration <dl newline="false" spacing="compact">
is requested:</t> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-truststore</dd>
<artwork><![CDATA[ <dt>Registrant Contact:</dt> <dd>The IESG</dd>
URI: urn:ietf:params:xml:ns:yang:ietf-truststore <dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
Registrant Contact: The IESG </dl>
XML: N/A, the requested URI is an XML namespace.
]]></artwork>
</section> </section>
<section> <section>
<name>The "YANG Module Names" Registry</name> <name>The YANG Module Names Registry</name>
<t>This document registers one YANG module in the <t>IANA has registered the following YANG module in the "YANG Module Nam
YANG Module Names registry <xref target="RFC6020"/>. es" registry defined in <xref target="RFC6020"/>.</t>
Following the format in <xref target="RFC6020"/>, the <dl newline="false" spacing="compact">
following registration is requested:</t> <dt>Name:</dt> <dd>ietf-truststore</dd>
<artwork><![CDATA[ <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-truststore</dd>
name: ietf-truststore <dt>Prefix:</dt> <dd>ts</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-truststore <dt>Reference:</dt> <dd>RFC 9641</dd>
prefix: ts </dl>
reference: RFC BBBB
]]></artwork>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netconf-http-client-server"
to="HTTP-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netconf-netconf-client-server"
to="NETCONF-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netconf-restconf-client-server"
to="RESTCONF-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netmod-system-config" to="NETMOD-SYSTEM-C
ONFIG"/>
<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://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include
le> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
<date month="March" year="1997"/> 41.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
<t>In many standards track documents several words are used to sig 50.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
his document defines these words as they should be interpreted in IETF documents 40.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
mmunity, and requests discussion and suggestions for improvements.</t> 74.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
</front> 41.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<seriesInfo name="RFC" value="2119"/> 46.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
</reference> 00.xml"/>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"> <reference anchor="RFC9640" target="https://www.rfc-editor.org/info/rfc9
<front> 640">
<title>The YANG 1.1 Data Modeling Language</title> <front>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= <title>YANG Data Types and Groupings for Cryptography</title>
"Bjorklund"/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<date month="August" year="2016"/> <organization>Watsen Networks</organization>
<abstract> </author>
<t>YANG is a data modeling language used to model configuration da <date month="October" year="2024"/>
ta, state data, Remote Procedure Calls, and notifications for network management </front>
protocols. This document describes the syntax and semantics of version 1.1 of t <seriesInfo name="RFC" value="9640"/>
he YANG language. YANG version 1.1 is a maintenance release of the YANG language <seriesInfo name="DOI" value="10.17487/RFC9640"/>
, addressing ambiguities and defects in the original specification. There are a </reference>
small number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<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 that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8
341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red subset of all available NETCONF or RESTCONF protocol operations and content.
This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-crypto-types.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36
<front> 88.xml"/>
<title>The IETF XML Registry</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
<author fullname="M. Mealling" initials="M." surname="Mealling"/> 20.xml"/>
<date month="January" year="2004"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<abstract> 59.xml"/>
<t>This document describes an IANA maintained registry for IETF st <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
andards which use Extensible Markup Language (XML) related items such as Namespa 40.xml"/>
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
ork (RDF) Schemas.</t> 42.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
</front> 07.xml"/>
<seriesInfo name="BCP" value="81"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
<seriesInfo name="RFC" value="3688"/> 72.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
</reference> 92.xml"/>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
648" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"> <reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9
<front> 642">
<title>The Base16, Base32, and Base64 Data Encodings</title> <front>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <title>A YANG Data Model for a Keystore</title>
<date month="October" year="2006"/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<abstract> <organization>Watsen Networks</organization>
<t>This document describes the commonly used base 64, base 32, and </author>
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da <date month="October" year="2024"/>
ta, use of padding in encoded data, use of non-alphabet characters in encoded da </front>
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA <seriesInfo name="RFC" value="9642"/>
CK]</t> <seriesInfo name="DOI" value="10.17487/RFC9642"/>
</abstract> </reference>
</front>
<seriesInfo name="RFC" value="4648"/> <reference anchor="RFC9643" target="https://www.rfc-editor.org/info/rfc9
<seriesInfo name="DOI" value="10.17487/RFC4648"/> 643">
</reference> <front>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6 <title>YANG Groupings for TCP Clients and TCP Servers</title>
020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<front> <organization>Watsen Networks</organization>
<title>YANG - A Data Modeling Language for the Network Configuration </author>
Protocol (NETCONF)</title> <author initials="M." surname="Scharf" fullname="Michael Scharf">
<author fullname="M. Bjorklund" initials="M." role="editor" surname= <organization>Hochschule Esslingen - University of Applied Sciences
"Bjorklund"/> </organization>
<date month="October" year="2010"/> </author>
<abstract> <date month="October" year="2024"/>
<t>YANG is a data modeling language used to model configuration an </front>
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON <seriesInfo name="RFC" value="9643"/>
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> <seriesInfo name="DOI" value="10.17487/RFC9643"/>
</abstract> </reference>
</front>
<seriesInfo name="RFC" value="6020"/> <reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc9
<seriesInfo name="DOI" value="10.17487/RFC6020"/> 644">
</reference> <front>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 <title>YANG Groupings for SSH Clients and SSH Servers</title>
241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<front> <organization>Watsen Networks</organization>
<title>Network Configuration Protocol (NETCONF)</title> </author>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns <date month="October" year="2024"/>
"/> </front>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= <seriesInfo name="RFC" value="9644"/>
"Bjorklund"/> <seriesInfo name="DOI" value="10.17487/RFC9644"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn </reference>
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B <reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc9
ierman"/> 645">
<date month="June" year="2011"/> <front>
<abstract> <title>YANG Groupings for TLS Clients and TLS Servers</title>
<t>The Network Configuration Protocol (NETCONF) defined in this do <author initials="K." surname="Watsen" fullname="Kent Watsen">
cument provides mechanisms to install, manipulate, and delete the configuration <organization>Watsen Networks</organization>
of network devices. It uses an Extensible Markup Language (XML)-based data encod </author>
ing for the configuration data as well as the protocol messages. The NETCONF pro <date month="October" year="2024"/>
tocol operations are realized as remote procedure calls (RPCs). This document ob </front>
soletes RFC 4741. [STANDARDS-TRACK]</t> <seriesInfo name="RFC" value="9645"/>
</abstract> <seriesInfo name="DOI" value="10.17487/RFC9645"/>
</front> </reference>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
</reference> conf-http-client-server"/>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
<front> conf-netconf-client-server"/>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <xi:include
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restcon
<author fullname="K. Watsen" initials="K." surname="Watsen"/> f-client-server"/>
<date month="January" year="2017"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
<t>This document describes an HTTP-based protocol that provides a mod-system-config.xml"/>
programmatic interface for accessing data defined in YANG, using the datastore c
oncepts defined in the Network Configuration Protocol (NETCONF).</t> <reference anchor="W3C.REC-xml-20081126"
</abstract> target="https://www.w3.org/TR/2008/REC-xml-20081126/">
</front> <front>
<seriesInfo name="RFC" value="8040"/> <title>Extensible Markup Language (XML) 1.0
<seriesInfo name="DOI" value="10.17487/RFC8040"/> (Fifth Edition)</title>
</reference> <author initials="T." surname="Bray" fullname="Tim Bray"/>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8 <author initials="J." surname="Paoli" fullname="Jean Paoli"/>
340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"> <author initials="C.M." surname="Sperberg-McQueen" fullname="C. M.
<front> Sperberg-McQueen"/>
<title>YANG Tree Diagrams</title> <author initials="E." surname="Maler" fullname="Eve Maler"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author initials="F." surname="Yergeau" fullname="François Yergeau"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be <date month="November" year="2008"/>
rger"/> </front>
<date month="March" year="2018"/> <seriesInfo name="World Wide Web Consortium
<abstract> Recommendation" value="REC-xml-20081126"/>
<t>This document captures the current syntax used in YANG module t </reference>
ree diagrams. The purpose of this document is to provide a single location for t </references>
his definition. This syntax may be updated from time to time based on the evolut
ion of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s an architectural framework for datastores based on the experience gained with
the initial simpler model, addressing requirements that were not well supported
in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8
407" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<date month="October" year="2018"/>
<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 Configu
ration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YAN
G modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference>
<reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8
572" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml">
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="I. Farrer" initials="I." surname="Farrer"/>
<author fullname="M. Abrahamsson" initials="M." surname="Abrahamsson
"/>
<date month="April" year="2019"/>
<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 s
olution enable it to be used on both public and private networks. The provisioni
ng steps are able to update the boot image, commit an initial configuration, and
execute arbitrary scripts to address auxiliary needs. The updated device is sub
sequently able to establish secure connections with other systems. For instance,
a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connection
s with deployment-specific network management systems.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8572"/>
<seriesInfo name="DOI" value="10.17487/RFC8572"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-trust-anchors.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-keystore.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-tcp-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-ssh-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-tls-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-http-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-netconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-restconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netmod-system-config.xml"/>
</references>
</references> </references>
<section anchor="change-log">
<name>Change Log</name>
<section>
<name>00 to 01</name>
<ul spacing="normal">
<li>Added features "x509-certificates" and "ssh-host-keys".</li>
<li>Added nacm:default-deny-write to "trust-anchors" container.</li>
</ul>
</section>
<section>
<name>01 to 02</name>
<ul spacing="normal">
<li>Switched "list pinned-certificate" to use the
"trust-anchor-cert-grouping" from crypto-types.
Effectively the same definition as before.</li>
</ul>
</section>
<section>
<name>02 to 03</name>
<ul spacing="normal">
<li>Updated copyright date, boilerplate template, affiliation,
folding algorithm, and reformatted the YANG module.</li>
</ul>
</section>
<section>
<name>03 to 04</name>
<ul spacing="normal">
<li>Added groupings 'inline-or-truststore-certs-grouping'
and 'inline-or-truststore-host-keys-grouping', matching
similar definitions in the keystore draft. Note new
(and incomplete) "truststore" usage!</li>
<li>Related to above, also added features 'truststore-supported'
and 'local-trust-anchors-supported'.</li>
</ul>
</section>
<section>
<name>04 to 05</name>
<ul spacing="normal">
<li>Renamed "trust-anchors" to "truststore"</li>
<li>Removed "pinned." prefix everywhere, to match truststore rename</l
i>
<li>Moved everything under a top-level 'grouping' to enable use in oth
er contexts.</li>
<li>Renamed feature from 'local-trust-anchors-supported' to 'inline-de
finitions-supported' (same name used in keystore)</li>
<li>Removed the "require-instance false" statement from the "*-ref" ty
pedefs.</li>
<li>Added missing "ssh-host-keys" and "x509-certificates" if-feature s
tatements</li>
</ul>
</section>
<section>
<name>05 to 06</name>
<ul spacing="normal">
<li>Editorial changes only.</li>
</ul>
</section>
<section>
<name>06 to 07</name>
<ul spacing="normal">
<li>Added Henk Birkholz as a co-author (thanks Henk!)</li>
<li>Added PSKs and raw public keys to truststore.</li>
</ul>
</section>
<section>
<name>07 to 08</name>
<ul spacing="normal">
<li>Added new "Support for Built-in Trust Anchors" section.</li>
<li>Removed spurious "uses ct:trust-anchor-certs-grouping" line.</li>
<li>Removed PSK from model.</li>
</ul>
</section>
<section>
<name>08 to 09</name>
<ul spacing="normal">
<li>Removed remaining PSK references from text.</li>
<li>Wrapped each top-level list with a container.</li>
<li>Introduced "bag" term.</li>
<li>Merged "SSH Public Keys" and "Raw Public Keys" in a single "Public
Keys" bag.
Consuming downstream modules (i.e., "ietf-[ssh/tls]-[client/serv
er]) refine
the "public-key-format" to be either SSH or TLS specific as need
ed.</li>
</ul>
</section>
<section>
<name>09 to 10</name>
<ul spacing="normal">
<li>Removed "algorithm" node from examples.</li>
<li>Removed the no longer used statements supporting the old "ssh-publ
ic-key" and "raw-public-key" nodes.</li>
<li>Added a "Note to Reviewers" note to first page.</li>
</ul>
</section>
<section>
<name>10 to 11</name>
<ul spacing="normal">
<li>Corrected module prefix registered in the IANA Considerations sect
ion.</li>
<li>Modified 'inline-or-truststore-certs-grouping' to use a list (not
a leaf-list).</li>
<li>Added new example section "The Local or Truststore Groupings".</li
>
<li>Clarified expected behavior for "built-in" certificates in &lt;ope
rational&gt;</li>
<li>Expanded "Data Model Overview section(s) [remove "wall" of tree di
agrams].</li>
<li>Updated the Security Considerations section.</li>
</ul>
</section>
<section>
<name>11 to 12</name>
<ul spacing="normal">
<li>Fixed a copy/paste issue in the "Data at Rest" Security Considerat
ions section.</li>
</ul>
</section>
<section>
<name>12 to 13</name>
<ul spacing="normal">
<li>Fixed issues found by the SecDir review of the "keystore" draft.</
li>
</ul>
</section>
<section>
<name>13 to 14</name>
<ul spacing="normal">
<li>Added an "Unconstrained Public Key Usage" Security Consideration t
o address
concern raised by SecDir.</li>
<li>Addressed comments raised by YANG Doctor.</li>
</ul>
</section>
<section>
<name>14 to 15</name>
<ul spacing="normal">
<li>Added prefixes to 'path' statements per trust-anchors/issues/1</li
>
<li>Renamed feature "truststore-supported" to "central-truststore-supp
orted".</li>
<li>Associated with above, generally moved text to refer to a "central
" truststore.</li>
<li>Removed two unecessary/unwanted "min-elements 1" and associated "p
resence" statements.</li>
<li>Aligned modules with `pyang -f` formatting.</li>
<li>Fixed nits found by YANG Doctor reviews.</li>
</ul>
</section>
<section>
<name>15 to 16</name>
<ul spacing="normal">
<li>Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.</
li>
<li>Minor editorial nits</li>
</ul>
</section>
<section>
<name>16 to 17</name>
<ul spacing="normal">
<li>fixup the 'WG Web' and 'WG List' lines in YANG module(s)</li>
<li>fixup copyright (i.e., s/Simplified/Revised/) in YANG module(s)</l
i>
<li>Added Informative reference to ma-netmod-with-system</li>
</ul>
</section>
<section>
<name>17 to 18</name>
<ul spacing="normal">
<li>Updated Security Considerations section to address comment
received from Carl Wallace.</li>
<li>Fixed examples to not have line-returns around "identity" encoding
s.</li>
<li>Fixed a couple tree diagrams to not create diagrams for "groupings
" too.</li>
<li>Added "if-feature central-truststore-supported" to top-level "trus
tore" container.</li>
</ul>
</section>
<section>
<name>18 to 19</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</li>
</ul>
</section>
<section>
<name>19 to 20</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</li>
</ul>
</section>
<section>
<name>20 to 21</name>
<ul spacing="normal">
<li>Updated (implicitly) per Tom Petch review.</li>
<li>Updated per AD's review.</li>
<li>s/local/inline/ in feature names, grouping names, and node names.<
/li>
<li>Updated ref from 'ma-netmod-with-system' to 'ietf-netmod-system-co
nfig'.</li>
<li>Removed special handling text for built-in certs</li>
<li>Updated section on built-in trust anchors to read almost
the same as the section in the keystore draft.</li>
</ul>
</section>
<section>
<name>21 to 22</name>
<ul spacing="normal">
<li>Mostly addresses AD review comments.</li>
<li>Also added typedefs and groupings similar to those created by Alto
WG.</li>
<li>Added note to Editor to fix line foldings.</li>
<li>Renamed "truststore" to "central truststore" throughout.</li>
<li>Removed "built-in" section text that overlaps with the "system-con
fig" draft.</li>
<li>Added "certificate-ref-grouping" and "public-key-ref-grouping"</li
>
<li>Modified typedef certificate-ref's leafref path to NOT prefix "cer
tificate-bag".</li>
<li>Modified typedef public-key-ref's leafref path to NOT prefix "publ
ic-key-bag".</li>
<li>Added groupings "certificate-ref-grouping" and "public-key-ref-gro
uping".</li>
</ul>
</section>
<section>
<name>22 to 23</name>
<ul spacing="normal">
<li>Addresses Gen-ART review by Dale Worley.</li>
<li>Addresses review by Tom Petch.</li>
</ul>
</section>
<section>
<name>23 to 24</name>
<ul spacing="normal">
<li>Addresses 1st-round of IESG reviews.</li>
</ul>
</section>
<section>
<name>24 to 26</name>
<ul spacing="normal">
<li>Addresses issues found in OpsDir review of the ssh-client-server d
raft.</li>
<li>Renamed Security Considerations section s/Template for/Considerati
ons for/</li>
<li>s/defines/presents/ in a few places.</li>
<li>Add refs to where the 'operational' and 'system' datastores are de
fined.</li>
<li>Improved Security Consideration for 'cert-data' node.</li>
<li>s/should/SHOULD/ is one place</li>
</ul>
</section>
<section>
<name>26 to 28</name>
<ul spacing="normal">
<li>Nothing changed. Only bumped for automation...</li>
</ul>
</section>
</section>
<section numbered="false"> <section numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors especially thank Henk Birkholz for contributing YANG <t>The authors especially thank <contact fullname="Henk Birkholz"/> for co
to the ietf-truststore module supporting raw public keys and PSKs ntributing YANG
to the "ietf-truststore" module supporting raw public keys and PSKs
(pre-shared or pairwise-symmetric keys). While these contributions (pre-shared or pairwise-symmetric keys). While these contributions
were eventually replaced by reusing the existing support for were eventually replaced by reusing the existing support for
asymmetric and symmetric trust anchors, respectively, it was only asymmetric and symmetric trust anchors, respectively, it was only
through Henk's initiative that the WG was able to come to that result. </t> through Henk's initiative that the WG was able to come to that result. </t>
<t>The authors additionally thank the following for helping give shape <t>The authors additionally thank the following for helping give shape
to this work (ordered by first name): to this work (ordered by first name):
Balázs Kovács, <contact fullname="Balázs Kovács"/>,
Carl Wallace, <contact fullname="Carl Wallace"/>,
Eric Voit, <contact fullname="Eric Voit"/>,
Éric Vyncke, <contact fullname="Éric Vyncke"/>,
Francesca Palombini, <contact fullname="Francesca Palombini"/>,
Jensen Zhang, <contact fullname="Jensen Zhang"/>,
Jürgen Schönwälder, <contact fullname="Jürgen Schönwälder"/>,
Lars Eggert, <contact fullname="Lars Eggert"/>,
Liang Xia, <contact fullname="Liang Xia"/>,
Martin Björklund, <contact fullname="Martin Björklund"/>,
Murray Kucherawy, <contact fullname="Murray Kucherawy"/>,
Nick Hancock, <contact fullname="Nick Hancock"/>,
Qin Wu, <contact fullname="Paul Kyzivat"/>,
Rob Wilton, <contact fullname="Qin Wu"/>,
Robert Varga, <contact fullname="Rob Wilton"/>,
Roman Danyliw, <contact fullname="Robert Varga"/>,
Paul Kyzivat, <contact fullname="Roman Danyliw"/>,
and Yoav Nir. and <contact fullname="Yoav Nir"/>.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 156 change blocks. 
937 lines changed or deleted 429 lines changed or added

This html diff was produced by rfcdiff 1.48.