rfc9641.original.xml   rfc9641.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY nbsp "&#160;"> nsus="true" submissionType="IETF" ipr="trust200902" docName="draft-ietf-netconf-
<!ENTITY zwsp "&#8203;"> trust-anchors-28" number="9641" updates="" obsoletes="" tocInclude="true" symRef
<!ENTITY nbhy "&#8209;"> s="true" sortRefs="true" xml:lang="en" prepTime="2024-10-10T13:20:50" indexInclu
<!ENTITY wj "&#8288;"> de="true" scripts="Common,Latin" tocDepth="3">
]> <link href="https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors-
<?rfc toc="yes"?> 28" rel="prev"/>
<?rfc symrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc9641" rel="alternate"/>
<?rfc sortrefs="yes" ?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?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 T
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-trust-anchors-28 ruststore</title>
"/> <seriesInfo name="RFC" value="9641" stream="IETF"/>
<author initials="K." surname="Watsen" fullname="Kent Watsen"> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Watsen Networks</organization> <organization showOnFrontPage="true">Watsen Networks</organization>
<address> <address>
<email>kent+ietf@watsen.net</email> <email>kent+ietf@watsen.net</email>
</address> </address>
</author> </author>
<date/> <date month="10" year="2024"/>
<area>Operations</area> <area>OPS</area>
<workgroup>NETCONF Working Group</workgroup> <workgroup>netconf</workgroup>
<abstract> <keyword>IETF</keyword>
<t>This document presents a YANG module for configuring <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">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> <boilerplate>
<name>Editorial Note (To be removed by RFC Editor)</name> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>This draft contains placeholder values that need to be replaced "exclude" pn="section-boilerplate.1">
with finalized values at the time of publication. This note summarize <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
s >
all of the substitutions that are needed. No other RFC Editor <t indent="0" pn="section-boilerplate.1-1">
instructions are specified elsewhere in this document.</t> This is an Internet Standards Track document.
<t>Artwork in this document contains shorthand references to drafts in </t>
progress. Please apply the following replacements: <t indent="0" pn="section-boilerplate.1-2">
</t> This document is a product of the Internet Engineering Task Force
<ul spacing="normal"> (IETF). It represents the consensus of the IETF community. It has
<li> received public review and has been approved for publication by
<tt>AAAA</tt> --&gt; the assigned RFC value for draft-ietf-netconf-cry the Internet Engineering Steering Group (IESG). Further
pto-types</li> information on Internet Standards is available in Section 2 of
<li> RFC 7841.
<tt>BBBB</tt> --&gt; the assigned RFC value for this draft</li> </t>
</ul> <t indent="0" pn="section-boilerplate.1-3">
<t>Artwork in this document contains placeholder values for the date Information about the current status of this document, any
of publication of this draft. Please apply the following replacement: errata, and how to provide feedback on it may be obtained at
</t> <eref target="https://www.rfc-editor.org/info/rfc9641" brackets="non
<ul spacing="normal"> e"/>.
<li> </t>
<tt>2024-03-16</tt> --&gt; the publication date of this draft</li> </section>
</ul> <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> ude" pn="section-boilerplate.2">
contains <name slugifiedName="name-copyright-notice">Copyright Notice</name>
the text "one or more YANG modules" and, later, "modules". This text <t indent="0" pn="section-boilerplate.2-1">
is sourced Copyright (c) 2024 IETF Trust and the persons identified as the
from a file in a context where it is unknown how many modules a draft document authors. All rights reserved.
defines. </t>
The text is not wrong as is, but it may be improved by stating more di <t indent="0" pn="section-boilerplate.2-2">
rectly how This document is subject to BCP 78 and the IETF Trust's Legal
many modules are defined.</t> Provisions Relating to IETF Documents
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> (<eref target="https://trustee.ietf.org/license-info" brackets="none
contains "/>) in effect on the date of
a self-reference to this draft, along with a corresponding reference i publication of this document. Please review these documents
n carefully, as they describe your rights and restrictions with
the Appendix. Please replace the self-reference in this section with respect to this document. Code Components extracted from this
"This RFC" document must include Revised BSD License text as described in
(or similar) and remove the self-reference in the "Normative/Informati Section 4.e of the Trust Legal Provisions and are provided without
ve References" warranty as described in the Revised BSD License.
section, whichever it is in.</t> </t>
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined i </section>
n RFC 8792. </boilerplate>
However, nicer-to-the-eye is when the '\\' line-folding mode is used. <toc>
The AD suggested <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
suggested putting a request here for the RFC Editor to help convert "u n="section-toc.1">
gly" '\' folded <name slugifiedName="name-table-of-contents">Table of Contents</name>
examples to use the '\\' folding mode. "Help convert" may be interpre <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
ted as, identify c.1-1">
what looks ugly and ask the authors to make the adjustment.</t> <li pn="section-toc.1-1.1">
<t>The following Appendix section is to be removed prior to publication: <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
</t> at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
<ul spacing="normal"> ormat="title" sectionFormat="of" target="name-introduction">Introduction</xref><
<li> /t>
<xref target="change-log"/>. Change Log</li> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
</ul> n-toc.1-1.1.2">
</note> <li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
lation-to-other-rfcs">Relation to Other RFCs</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sp
ecification-language">Specification Language</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><
xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.
3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ad
herence-to-the-nmda">Adherence to the NMDA</xref></t>
</li>
<li pn="section-toc.1-1.1.2.4">
<t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent=
"1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-conventions">Conventio
ns</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-ietf-truststore-module">The "i
etf-truststore" Module</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent=
"2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-data-model-overview">D
ata Model Overview</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent=
"2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-example-usage">Example
Usage</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-yang-module">YANG Modu
le</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-support-for-built-in-trust-">Suppo
rt for Built-In Trust Anchors</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-security-of-data-at-re
st">Security of Data at Rest</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-unconstrained-public-k
ey-us">Unconstrained Public Key Usage</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-considerations-for-the
-ietf">Considerations for the "ietf-truststore" YANG Module</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-ietf-xml-registry"
>The IETF XML Registry</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-yang-module-names-
regis">The YANG Module Names Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-authors-address">Author's Addres
s</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
<name>Introduction</name> <name slugifiedName="name-introduction">Introduction</name>
<t>This document presents a YANG 1.1 <xref target="RFC7950"/> module havin <t indent="0" pn="section-1-1">This document presents a YANG 1.1 <xref tar
g get="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> mod
ule that has
the following characteristics: the following characteristics:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2
<li>Provide a central truststore for storing raw public keys and/or cert ">
ificates.</li> <li pn="section-1-2.1">Provide a central truststore for storing raw publ
<li>Provide support for storing named bags of raw public keys and/or nam ic keys and/or certificates.</li>
ed bags <li pn="section-1-2.2">Provide support for storing named bags of raw pub
lic keys and/or named bags
of certificates.</li> of certificates.</li>
<li>Provide types that can be used to reference raw public keys or certi ficates <li pn="section-1-2.3">Provide types that can be used to reference raw p ublic keys or certificates
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 pn="section-1-2.4">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 pn="section-1-2.5">Enable the truststore to be instantiated in other data models, in addition
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" numbered="true" removeInRFC="false" to
<name>Relation to other RFCs</name> c="include" pn="section-1.1">
<t>This document presents one or more YANG modules <xref target="RFC7950 <name slugifiedName="name-relation-to-other-rfcs">Relation to Other RFCs
"/> </name>
that are part of a collection of RFCs that work together <t indent="0" pn="section-1.1-1">This document presents a YANG module <x
to, ultimately, support the configuration of both the clients ref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950
and servers of both the NETCONF <xref target="RFC6241"/> and "/>
RESTCONF <xref target="RFC8040"/> protocols.</t> that is part of a collection of RFCs that work together
<t> The dependency relationship between the primary YANG groupings to ultimately support the configuration of both the clients
and servers of both the Network Configuration Protocol (NETCONF) <xr
ef target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"
/> and
RESTCONF <xref target="RFC8040" format="default" sectionFormat="of"
derivedContent="RFC8040"/>.</t>
<t indent="0" pn="section-1.1-2"> The dependency relationship between th
e 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 indent="0" pn="section-1.1-3">Please note that the arrows in the diag ram 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 align="left" pn="section-1.1-4">
crypto-types crypto-types
^ ^ ^ ^
/ \ / \
/ \ / \
truststore keystore truststore keystore
^ ^ ^ ^ ^ ^ ^ ^
| +---------+ | | | +---------+ | |
| | | | | | | |
| +------------+ | | +------------+ |
tcp-client-server | / | | tcp-client-server | / | |
skipping to change at line 145 skipping to change at line 207
| | | | | ^ | | | | | ^
| | | +-----+ +---------+ | | | | +-----+ +---------+ |
| | | | | | | | | | | |
| +-----------|--------|--------------+ | | | +-----------|--------|--------------+ | |
| | | | | | | | | | | |
+-----------+ | | | | | +-----------+ | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
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" pn="table-1">
ws? --> <name slugifiedName="name-label-in-diagram-to-rfc-map">Label in Diagra
<table> m to RFC Mapping</name>
<name>Label in Diagram to RFC Mapping</name>
<tbody> <tbody>
<tr> <tr>
<th>Label in Diagram</th> <th align="left" colspan="1" rowspan="1">Label in Diagram</th>
<th>Originating RFC</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
<tr> <tr>
<td>crypto-types</td> <td align="left" colspan="1" rowspan="1">crypto-types</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-crypto-types"/></td> <xref target="RFC9640" format="default" sectionFormat="of" deriv
edContent="RFC9640"/></td>
</tr> </tr>
<tr> <tr>
<td>truststore</td> <td align="left" colspan="1" rowspan="1">truststore</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-trust-anchors"/></td> RFC 9641</td>
</tr> </tr>
<tr> <tr>
<td>keystore</td> <td align="left" colspan="1" rowspan="1">keystore</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-keystore"/></td> <xref target="RFC9642" format="default" sectionFormat="of" deriv
edContent="RFC9642"/></td>
</tr> </tr>
<tr> <tr>
<td>tcp-client-server</td> <td align="left" colspan="1" rowspan="1">tcp-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-tcp-client-server"/></td> <xref target="RFC9643" format="default" sectionFormat="of" deriv
edContent="RFC9643"/></td>
</tr> </tr>
<tr> <tr>
<td>ssh-client-server</td> <td align="left" colspan="1" rowspan="1">ssh-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-ssh-client-server"/></td> <xref target="RFC9644" format="default" sectionFormat="of" deriv
edContent="RFC9644"/></td>
</tr> </tr>
<tr> <tr>
<td>tls-client-server</td> <td align="left" colspan="1" rowspan="1">tls-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-tls-client-server"/></td> <xref target="RFC9645" format="default" sectionFormat="of" deriv
edContent="RFC9645"/></td>
</tr> </tr>
<tr> <tr>
<td>http-client-server</td> <td align="left" colspan="1" rowspan="1">http-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-http-client-server"/></td> <xref target="I-D.ietf-netconf-http-client-server" format="defau
lt" sectionFormat="of" derivedContent="HTTP-CLIENT-SERVER"/></td>
</tr> </tr>
<tr> <tr>
<td>netconf-client-server</td> <td align="left" colspan="1" rowspan="1">netconf-client-server</td
<td> >
<xref target="I-D.ietf-netconf-netconf-client-server"/></td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-netconf-client-server" format="de
fault" sectionFormat="of" derivedContent="NETCONF-CLIENT-SERVER"/></td>
</tr> </tr>
<tr> <tr>
<td>restconf-client-server</td> <td align="left" colspan="1" rowspan="1">restconf-client-server</t
<td> d>
<xref target="I-D.ietf-netconf-restconf-client-server"/></td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-restconf-client-server" format="d
efault" sectionFormat="of" derivedContent="RESTCONF-CLIENT-SERVER"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1.2
<name>Specification Language</name> ">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name slugifiedName="name-specification-language">Specification Language
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", </name>
"MAY", and "OPTIONAL" in this document are to be interpreted as <t indent="0" pn="section-1.2-1">
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/ The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
when, and only when, they appear in all capitals, as shown here.</t> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1.3
<name>Adherence to the NMDA</name> ">
<t>This document is compliant with the Network Management Datastore Arch <name slugifiedName="name-adherence-to-the-nmda">Adherence to the NMDA</
itecture name>
(NMDA) <xref target="RFC8342"/>. For instance, trust anchors instal <t indent="0" pn="section-1.3-1">This document is compliant with the Net
led work Management Datastore Architecture
during manufacturing (e.g., for trusted well-known services), are ex (NMDA) <xref target="RFC8342" format="default" sectionFormat="of" de
pected rivedContent="RFC8342"/>. For instance, trust anchors installed
to appear in &lt;operational&gt; (see <xref target="built-ins"/>).</ during manufacturing (e.g., for trusted, well-known services) are ex
t> pected
to appear in &lt;operational&gt; (see <xref target="built-ins" forma
t="default" sectionFormat="of" derivedContent="Section 3"/>).</t>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1.4
<name>Conventions</name> ">
<t>Various examples in this document use "BASE64VALUE=" as a <name slugifiedName="name-conventions">Conventions</name>
<t indent="0" pn="section-1.4-1">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 format="default" derivedLink="https://rfc-editor.org/rfc/rfc7950#section-9.8" d
erivedContent="RFC7950"/>). 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 indent="0" pn="section-1.4-2"> Various examples in this document use
to refer to the top-level instance of the "truststore-grouping", whe the XML
n <xref target="W3C.REC-xml-20081126" format="default" sectionFormat="of" derive
dContent="W3C.REC-xml-20081126"/> encoding. Other encodings, such as JSON <xref
target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>,
could alternatively be used.</t>
<t indent="0" pn="section-1.4-3">Various examples in this document conta
in long lines that may be folded,
as described in <xref target="RFC8792" format="default" sectionFormat="of" der
ivedContent="RFC8792"/>.</t>
<t indent="0" pn="section-1.4-4">This document uses the adjective "centr
al" 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 numbered="true" removeInRFC="false" toc="include" pn="section-2">
<name>The "ietf-truststore" Module</name> <name slugifiedName="name-the-ietf-truststore-module">The "ietf-truststore
<t>This section defines a YANG 1.1 <xref target="RFC7950"/> module called " Module</name>
<t indent="0" pn="section-2-1">This section defines a YANG 1.1 <xref targe
t="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> modul
e 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' <xref target="truststore-verview" format="default" sectionFormat="of"
s use derivedContent="Section 2.1"/>. Examples illustrating the module's use
are provided in <xref target="truststore-examples">Examples</xref>. Th are provided in <xref target="truststore-examples" format="default" se
e YANG ctionFormat="of" derivedContent="Section 2.2"/> ("Example Usage"). The YANG
module itself is defined in <xref target="truststore-yang-module"/>.</ module itself is defined in <xref target="truststore-yang-module" form
t> at="default" sectionFormat="of" derivedContent="Section 2.3"/>.</t>
<section anchor="truststore-verview"> <section anchor="truststore-verview" numbered="true" removeInRFC="false" t
<name>Data Model Overview</name> oc="include" pn="section-2.1">
<t>This section provides an overview of the "ietf-truststore" module <name slugifiedName="name-data-model-overview">Data Model Overview</name
>
<t indent="0" pn="section-2.1-1">This section provides an overview of th
e "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" numbered="true" removeInRFC="fa
<name>Features</name> lse" pn="section-2.1.1">
<t>The following diagram lists all the "feature" statements <name slugifiedName="name-features">Features</name>
<t indent="0" pn="section-2.1.1-1">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" markers="false" pn="section-2.1.1-2">
Features: Features:
+-- central-truststore-supported +-- central-truststore-supported
+-- inline-definitions-supported +-- inline-definitions-supported
+-- certificates +-- certificates
+-- public-keys +-- public-keys
]]></artwork> </sourcecode>
<!--<aside>--> <t indent="0" pn="section-2.1.1-3">The diagram above uses syntax that
<t>The diagram above uses syntax that is similar to but not is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340" format="default" sectionFormat
<!--</aside>--> ="of" derivedContent="RFC8340"/>.</t>
</section> </section>
<section anchor="typedefs" toc="exclude"> <section anchor="typedefs" toc="exclude" numbered="true" removeInRFC="fa
<name>Typedefs</name> lse" pn="section-2.1.2">
<t>The following diagram lists the "typedef" statements defined in <name slugifiedName="name-typedefs">Typedefs</name>
<t indent="0" pn="section-2.1.2-1">The following diagram lists the "ty
pedef" statements defined in
the "ietf-truststore" module:</t> the "ietf-truststore" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.2-2">
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 indent="0" pn="section-2.1.2-3">The diagram above uses syntax that
<t>The diagram above uses syntax that is similar to but not is similar to but not
defined in <xref target="RFC8340"/>.</t> defined in <xref target="RFC8340" format="default" sectionFormat
<!--</aside>--> ="of" derivedContent="RFC8340"/>.</t>
<t>Comments:</t> <t indent="0" pn="section-2.1.2-4">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<li>All the typedefs defined in the "ietf-truststore" module -2.1.2-5">
extend the base "leafref" type defined in <xref target="RFC7950" <li pn="section-2.1.2-5.1">All the typedefs defined in the "ietf-tru
/>.</li> ststore" module
<li>The leafrefs refer to certificates, public keys, and bags extend the base "leafref" type defined in <xref target="RFC7950"
in the central truststore, when this module is implemented.</li> format="default" sectionFormat="of" derivedContent="RFC7950"/>.</li>
<li>These typedefs are provided as an aid to consuming <li pn="section-2.1.2-5.2">The leafrefs refer to certificates, publi
c keys, and bags
in the central truststore when this module is implemented.</li>
<li pn="section-2.1.2-5.3">These typedefs are provided to aid consum
ing
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" numbered="true" removeInRFC="false" pn="section-2
<name>Groupings</name> .1.3">
<t>The "ietf-truststore" module defines the following "grouping" state <name slugifiedName="name-groupings">Groupings</name>
ments:</t> <t indent="0" pn="section-2.1.3-1">The "ietf-truststore" module define
<ul spacing="compact"> s the following "grouping" statements:</t>
<li>central-certificate-ref-grouping</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>central-public-key-ref-grouping</li> -2.1.3-2">
<li>inline-or-truststore-certs-grouping</li> <li pn="section-2.1.3-2.1">central-certificate-ref-grouping</li>
<li>inline-or-truststore-public-keys-grouping</li> <li pn="section-2.1.3-2.2">central-public-key-ref-grouping</li>
<li>truststore-grouping</li> <li pn="section-2.1.3-2.3">inline-or-truststore-certs-grouping</li>
<li pn="section-2.1.3-2.4">inline-or-truststore-public-keys-grouping
</li>
<li pn="section-2.1.3-2.5">truststore-grouping</li>
</ul> </ul>
<t>Each of these groupings are presented in the following subsections. <t indent="0" pn="section-2.1.3-3">Each of these groupings are present
</t> ed in the following subsections.</t>
<section anchor="central-certificate-ref-grouping"> <section anchor="central-certificate-ref-grouping" numbered="true" rem
<name>The "central-certificate-ref-grouping" Grouping</name> oveInRFC="false" toc="exclude" pn="section-2.1.3.1">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-central-certificate-ref">The "central-
he certificate-ref-grouping" Grouping</name>
<t indent="0" pn="section-2.1.3.1-1">The following tree diagram <xre
f target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/
> illustrates the
"central-certificate-ref-grouping" grouping:</t> "central-certificate-ref-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.3.1-2">
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 indent="0" pn="section-2.1.3.1-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "central-certificate-ref-grouping" grouping is provided on-2.1.3.1-4">
solely as convenience to consuming modules that wish to <li pn="section-2.1.3.1-4.1">The "central-certificate-ref-grouping
" grouping is provided
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 <li pn="section-2.1.3.1-4.2">The "certificate-bag" leaf uses the "
ef" central-certificate-bag-ref"
typedef defined in <xref target="typedefs"/>.</li> typedef defined in <xref target="typedefs" format="default" se
<li>The "certificate" leaf uses the "central-certificate-ref" ctionFormat="of" derivedContent="Section 2.1.2"/>.</li>
typedef defined in <xref target="typedefs"/>.</li> <li pn="section-2.1.3.1-4.3">The "certificate" leaf uses the "cent
ral-certificate-ref"
typedef defined in <xref target="typedefs" format="default" se
ctionFormat="of" derivedContent="Section 2.1.2"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="central-public-key-ref-grouping"> <section anchor="central-public-key-ref-grouping" numbered="true" remo
<name>The "central-public-key-ref-grouping" Grouping</name> veInRFC="false" toc="exclude" pn="section-2.1.3.2">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-central-public-key-ref-">The "central-
he public-key-ref-grouping" Grouping</name>
<t indent="0" pn="section-2.1.3.2-1">The following tree diagram <xre
f target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/
> illustrates the
"central-public-key-ref-grouping" grouping:</t> "central-public-key-ref-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.3.2-2">
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 indent="0" pn="section-2.1.3.2-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "central-public-key-ref-grouping" grouping is provided on-2.1.3.2-4">
solely as convenience to consuming modules that wish to <li pn="section-2.1.3.2-4.1">The "central-public-key-ref-grouping"
grouping is provided
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 pn="section-2.1.3.2-4.2">The "public-key-bag" leaf uses the "c
typedef defined in <xref target="typedefs"/>.</li> entral-public-key-bag-ref"
<li>The "public-key" leaf uses the "public-key-ref" typedef defined in <xref target="typedefs" format="default" se
typedef defined in <xref target="typedefs"/>.</li> ctionFormat="of" derivedContent="Section 2.1.2"/>.</li>
<li pn="section-2.1.3.2-4.3">The "public-key" leaf uses the "centr
al-public-key-ref"
typedef defined in <xref target="typedefs" format="default" se
ctionFormat="of" derivedContent="Section 2.1.2"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="inline-or-truststore-certs-grouping"> <section anchor="inline-or-truststore-certs-grouping" numbered="true"
<name>The "inline-or-truststore-certs-grouping" Grouping</name> removeInRFC="false" toc="exclude" pn="section-2.1.3.3">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-inline-or-truststore-ce">The "inline-o
he r-truststore-certs-grouping" Grouping</name>
<t indent="0" pn="section-2.1.3.3-1">The following tree diagram <xre
f target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/
> illustrates the
"inline-or-truststore-certs-grouping" grouping:</t> "inline-or-truststore-certs-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.3.3-2">
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 indent="0" pn="section-2.1.3.3-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "inline-or-truststore-certs-grouping" grouping is provided on-2.1.3.3-4">
solely as convenience to consuming modules that wish to offer <li pn="section-2.1.3.3-4.1">The "inline-or-truststore-certs-group
ing" grouping is provided
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 pn="section-2.1.3.3-4.2">A "choice" statement is used to expos e 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 pn="section-2.1.3.3-4.3">For the "inline-definition" option, t he "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" format
/>.</li> ="default" derivedLink="https://rfc-editor.org/rfc/rfc9640#section-2.1.4.8" deri
<li>For the "central-truststore" option, the "central-truststore-r vedContent="RFC9640"/>.</li>
eference" is an <li pn="section-2.1.3.3-4.4">For the "central-truststore" option,
instance of the "certificate-bag-ref" discussed in <xref targe the "central-truststore-reference" node is an
t="typedefs"/>.</li> instance of the "central-certificate-bag-ref" discussed in <xr
ef target="typedefs" format="default" sectionFormat="of" derivedContent="Section
2.1.2"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="inline-or-truststore-public-keys-grouping"> <section anchor="inline-or-truststore-public-keys-grouping" numbered="
<name>The "inline-or-truststore-public-keys-grouping" Grouping</name true" removeInRFC="false" toc="exclude" pn="section-2.1.3.4">
> <name slugifiedName="name-the-inline-or-truststore-pu">The "inline-o
<t>The following tree diagram <xref target="RFC8340"/> illustrates t r-truststore-public-keys-grouping" Grouping</name>
he <t indent="0" pn="section-2.1.3.4-1">The following tree diagram <xre
f target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/
> illustrates the
"inline-or-truststore-public-keys-grouping" grouping:</t> "inline-or-truststore-public-keys-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.3.4-2">
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 indent="0" pn="section-2.1.3.4-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "inline-or-truststore-public-keys-grouping" grouping is pr on-2.1.3.4-4">
ovided <li pn="section-2.1.3.4-4.1">The "inline-or-truststore-public-keys
solely as convenience to consuming modules that wish to offer -grouping" grouping is provided
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 pn="section-2.1.3.4-4.2">A "choice" statement is used to expos e 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 <li pn="section-2.1.3.4-4.3">For the "inline-definition" option, t
the he "public-key" node uses the
"public-key-grouping" grouping discussed in <xref section="2.1 "public-key-grouping" grouping discussed in <xref section="2.1
.4.4" target="I-D.ietf-netconf-crypto-types"/>.</li> .4.4" sectionFormat="of" target="RFC9640" format="default" derivedLink="https://
<li>For the "central-truststore" option, the "central-truststore-r rfc-editor.org/rfc/rfc9640#section-2.1.4.4" derivedContent="RFC9640"/>.</li>
eference" is an <li pn="section-2.1.3.4-4.4">For the "central-truststore" option,
instance of the "certificate-bag-ref" discussed in <xref targe the "central-truststore-reference" is an
t="typedefs"/>.</li> instance of the "certificate-bag-ref" discussed in <xref targe
t="typedefs" format="default" sectionFormat="of" derivedContent="Section 2.1.2"/
>.</li>
</ul> </ul>
</section> </section>
<section anchor="truststore-grouping"> <section anchor="truststore-grouping" numbered="true" removeInRFC="fal
<name>The "truststore-grouping" Grouping</name> se" toc="exclude" pn="section-2.1.3.5">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-truststore-grouping-gro">The "truststo
he re-grouping" Grouping</name>
<t indent="0" pn="section-2.1.3.5-1">The following tree diagram <xre
f target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/
> illustrates the
"truststore-grouping" grouping:</t> "truststore-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.3.5-2">
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 indent="0" pn="section-2.1.3.5-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "truststore-grouping" grouping defines a truststore instan on-2.1.3.5-4">
ce <li pn="section-2.1.3.5-4.1">The "truststore-grouping" grouping de
fines a truststore instance
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 pn="section-2.1.3.5-4.2">For certificates, each certificate is
"trust-anchor-cert-grouping" grouping <xref section="2.1.4.7" defined by the
target="I-D.ietf-netconf-crypto-types"/>. The "cert-data" "trust-anchor-cert-grouping" grouping (<xref section="2.1.4.8"
node is a CMS structure that can be composed of a chain of one sectionFormat="of" target="RFC9640" format="default" derivedLink="https://rfc-e
or ditor.org/rfc/rfc9640#section-2.1.4.8" derivedContent="RFC9640"/>). The "cert-d
ata"
node is a Cryptographic Message Syntax (CMS) structure that ca
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 pn="section-2.1.3.5-4.3">For public keys, each public key is d
"public-key-grouping" grouping <xref section="2.1.4.4" target= efined by the
"I-D.ietf-netconf-crypto-types"/>. The "public-key" "public-key-grouping" grouping (<xref section="2.1.4.4" sectio
nFormat="of" target="RFC9640" format="default" derivedLink="https://rfc-editor.o
rg/rfc/rfc9640#section-2.1.4.4" derivedContent="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" numbered="true" remov
<name>Protocol-accessible Nodes</name> eInRFC="false" pn="section-2.1.4">
<t>The following tree diagram <xref target="RFC8340"/> lists all the <name slugifiedName="name-protocol-accessible-nodes">Protocol-Accessib
protocol-accessible nodes defined in the "ietf-truststore" module, le Nodes</name>
without <t indent="0" pn="section-2.1.4-1">The following tree diagram <xref ta
rget="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/> li
sts all the
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" markers="false" pn="section-2.1.4-2">
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 indent="0" pn="section-2.1.4-3">The following tree diagram <xref ta
protocol-accessible nodes defined in the "ietf-truststore" module, rget="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/> li
with sts all the
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" markers="false" pn="section-2.1.4-4">
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 indent="0" pn="section-2.1.4-5">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<li>Protocol-accessible nodes are those nodes that are accessible -2.1.4-6">
when the module is "implemented", as described in <xref section= <li pn="section-2.1.4-6.1">Protocol-accessible nodes are those nodes
"5.6.5" target="RFC7950"/>.</li> that are accessible
<li>The protocol-accessible nodes for the "ietf-truststore" module when the module is "implemented", as described in <xref section=
are an instance of the "truststore-grouping" grouping discussed "5.6.5" sectionFormat="of" target="RFC7950" format="default" derivedLink="https:
in //rfc-editor.org/rfc/rfc7950#section-5.6.5" derivedContent="RFC7950"/>.</li>
<xref target="truststore-grouping"/>.</li> <li pn="section-2.1.4-6.2">The protocol-accessible nodes for the "ie
<li>The top-level node "truststore" is additionally constrained tf-truststore" module
by the feature "central-truststore-supported".</li> are instances of the "truststore-grouping" grouping discussed in
<li>The "truststore-grouping" grouping is discussed in <xref target="truststore-grouping" format="default" sectionForma
<xref target="truststore-grouping"/>.</li> t="of" derivedContent="Section 2.1.3.5"/>.</li>
<li>The reason for why the "truststore-grouping" exists separate <li pn="section-2.1.4-6.3">The top-level "truststore" node is additi
onally constrained
by the "central-truststore-supported" feature.</li>
<li pn="section-2.1.4-6.4">The "truststore-grouping" grouping is dis
cussed in
<xref target="truststore-grouping" format="default" sectionForma
t="of" derivedContent="Section 2.1.3.5"/>.</li>
<li pn="section-2.1.4-6.5">The reason for why the "truststore-groupi
ng" grouping exists separate
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" numbered="true" removeInRFC="false"
<name>Example Usage</name> toc="include" pn="section-2.2">
<t>The examples in this section are encoded using XML, such as might <name slugifiedName="name-example-usage">Example Usage</name>
be the case when using the NETCONF protocol. Other encodings MAY <t indent="0" pn="section-2.2-1">The examples in this section are encode
d using XML, such as might
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" numbered="true" removeInRFC="fal
<name>A Truststore Instance</name> se" pn="section-2.2.1">
<t>This section presents an example illustrating trust anchors <name slugifiedName="name-a-truststore-instance">A Truststore Instance
in &lt;intended&gt;, as per <xref target="proto-access-nodes"/>. </name>
Please see <xref target="built-ins"/> for an example illustrating <t indent="0" pn="section-2.2.1-1">This section presents an example il
lustrating trust anchors
in &lt;intended&gt;, as per <xref target="proto-access-nodes" form
at="default" sectionFormat="of" derivedContent="Section 2.1.4"/>.
Please see <xref target="built-ins" format="default" sectionFormat
="of" derivedContent="Section 3"/> 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 indent="0" pn="section-2.2.1-2">The example contained in this secti
anchors. There are four certificate-based bags and four public on defines eight bags of trust
key based bags. The following diagram provides an overview of the anchors. There are four certificate-based bags and four public-ke
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" markers="false" pn="section-2.2.1-3">
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" markers="false" pn="section-2.2.1-4">
<artwork><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<truststore &lt;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"&gt;
<!-- A bag of Certificate Bags --> &lt;!-- A bag of Certificate Bags --&gt;
<certificate-bags> &lt;certificate-bags&gt;
<!-- Trust Anchor Certs for Authenticating Servers --> &lt;!-- Trust Anchor Certs for Authenticating Servers --&gt;
<certificate-bag> &lt;certificate-bag&gt;
<name>trusted-server-ca-certs</name> &lt;name&gt;trusted-server-ca-certs&lt;/name&gt;
<description> &lt;description&gt;
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> &lt;/description&gt;
<certificate> &lt;certificate&gt;
<name>Server Cert Issuer #1</name> &lt;name&gt;Server Cert Issuer #1&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
<certificate> &lt;certificate&gt;
<name>Server Cert Issuer #2</name> &lt;name&gt;Server Cert Issuer #2&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificate-bag> &lt;/certificate-bag&gt;
<!-- End Entity Certs for Authenticating Servers --> &lt;!-- End Entity Certs for Authenticating Servers --&gt;
<certificate-bag> &lt;certificate-bag&gt;
<name>trusted-server-ee-certs</name> &lt;name&gt;trusted-server-ee-certs&lt;/name&gt;
<description> &lt;description&gt;
Specific end-entity certificates used to authenticate server Specific end-entity certificates used to authenticate server
certificates. A server certificate is authenticated if its certificates. A server certificate is authenticated if its
end-entity certificate is an exact match to one of these end-entity certificate is an exact match to one of these
certificates. certificates.
</description> &lt;/description&gt;
<certificate> &lt;certificate&gt;
<name>My Application #1</name> &lt;name&gt;My Application #1&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
<certificate> &lt;certificate&gt;
<name>My Application #2</name> &lt;name&gt;My Application #2&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificate-bag> &lt;/certificate-bag&gt;
<!-- Trust Anchor Certs for Authenticating Clients --> &lt;!-- Trust Anchor Certs for Authenticating Clients --&gt;
<certificate-bag> &lt;certificate-bag&gt;
<name>trusted-client-ca-certs</name> &lt;name&gt;trusted-client-ca-certs&lt;/name&gt;
<description> &lt;description&gt;
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> &lt;/description&gt;
<certificate> &lt;certificate&gt;
<name>Client Identity Issuer #1</name> &lt;name&gt;Client Identity Issuer #1&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
<certificate> &lt;certificate&gt;
<name>Client Identity Issuer #2</name> &lt;name&gt;Client Identity Issuer #2&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificate-bag> &lt;/certificate-bag&gt;
<!-- End Entity Certs for Authenticating Clients --> &lt;!-- End Entity Certs for Authenticating Clients --&gt;
<certificate-bag> &lt;certificate-bag&gt;
<name>trusted-client-ee-certs</name> &lt;name&gt;trusted-client-ee-certs&lt;/name&gt;
<description> &lt;description&gt;
Specific end-entity certificates used to authenticate client Specific end-entity certificates used to authenticate client
certificates. A client certificate is authenticated if its certificates. A client certificate is authenticated if its
end-entity certificate is an exact match to one of these end-entity certificate is an exact match to one of these
certificates. certificates.
</description> &lt;/description&gt;
<certificate> &lt;certificate&gt;
<name>George Jetson</name> &lt;name&gt;George Jetson&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
<certificate> &lt;certificate&gt;
<name>Fred Flintstone</name> &lt;name&gt;Fred Flintstone&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificate-bag> &lt;/certificate-bag&gt;
</certificate-bags> &lt;/certificate-bags&gt;
<!-- A List of Public Key Bags --> &lt;!-- A List of Public Key Bags --&gt;
<public-key-bags> &lt;public-key-bags&gt;
<!-- Public Keys for Authenticating SSH Servers --> &lt;!-- Public Keys for Authenticating SSH Servers --&gt;
<public-key-bag> &lt;public-key-bag&gt;
<name>trusted-ssh-public-keys</name> &lt;name&gt;trusted-ssh-public-keys&lt;/name&gt;
<description> &lt;description&gt;
Specific SSH public keys used to authenticate SSH server Specific SSH public keys used to authenticate SSH server
public keys. An SSH server public key is authenticated if public keys. An SSH server public key is authenticated if
its public key is an exact match to one of these public keys. its public key is an exact match to one of these public keys.
This list of SSH public keys is analogous to OpenSSH's This list of SSH public keys is analogous to OpenSSH's
"/etc/ssh/ssh_known_hosts" file. "/etc/ssh/ssh_known_hosts" file.
</description> &lt;/description&gt;
<public-key> &lt;public-key&gt;
<name>corp-fw1</name> &lt;name&gt;corp-fw1&lt;/name&gt;
<public-key-format>ct:ssh-public-key-format</public-key-form\ &lt;public-key-format&gt;ct:ssh-public-key-format&lt;/public-key-form\
at> at&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
<public-key> &lt;public-key&gt;
<name>corp-fw2</name> &lt;name&gt;corp-fw2&lt;/name&gt;
<public-key-format>ct:ssh-public-key-format</public-key-form\ &lt;public-key-format&gt;ct:ssh-public-key-format&lt;/public-key-form\
at> at&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
</public-key-bag> &lt;/public-key-bag&gt;
<!-- SSH Public Keys for Authenticating Application A --> &lt;!-- SSH Public Keys for Authenticating Application A --&gt;
<public-key-bag> &lt;public-key-bag&gt;
<name>SSH Public Keys for Application A</name> &lt;name&gt;SSH Public Keys for Application A&lt;/name&gt;
<description> &lt;description&gt;
SSH public keys used to authenticate application A's SSH SSH public keys used to authenticate application A's SSH
public keys. An SSH public key is authenticated if it public keys. An SSH public key is authenticated if it
is an exact match to one of these public keys. is an exact match to one of these public keys.
</description> &lt;/description&gt;
<public-key> &lt;public-key&gt;
<name>Application Instance #1</name> &lt;name&gt;Application Instance #1&lt;/name&gt;
<public-key-format>ct:ssh-public-key-format</public-key-form\ &lt;public-key-format&gt;ct:ssh-public-key-format&lt;/public-key-form\
at> at&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
<public-key> &lt;public-key&gt;
<name>Application Instance #2</name> &lt;name&gt;Application Instance #2&lt;/name&gt;
<public-key-format>ct:ssh-public-key-format</public-key-form\ &lt;public-key-format&gt;ct:ssh-public-key-format&lt;/public-key-form\
at> at&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
</public-key-bag> &lt;/public-key-bag&gt;
<!-- Raw Public Keys for TLS Servers --> &lt;!-- Raw Public Keys for TLS Servers --&gt;
<public-key-bag> &lt;public-key-bag&gt;
<name>Raw Public Keys for TLS Servers</name> &lt;name&gt;Raw Public Keys for TLS Servers&lt;/name&gt;
<public-key> &lt;public-key&gt;
<name>Raw Public Key #1</name> &lt;name&gt;Raw Public Key #1&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public\
-key-format> -key-format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
<public-key> &lt;public-key&gt;
<name>Raw Public Key #2</name> &lt;name&gt;Raw Public Key #2&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public\
-key-format> -key-format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
</public-key-bag> &lt;/public-key-bag&gt;
<!-- Raw Public Keys for TLS Clients --> &lt;!-- Raw Public Keys for TLS Clients --&gt;
<public-key-bag> &lt;public-key-bag&gt;
<name>Raw Public Keys for TLS Clients</name> &lt;name&gt;Raw Public Keys for TLS Clients&lt;/name&gt;
<public-key> &lt;public-key&gt;
<name>Raw Public Key #1</name> &lt;name&gt;Raw Public Key #1&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public\
-key-format> -key-format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
<public-key> &lt;public-key&gt;
<name>Raw Public Key #2</name> &lt;name&gt;Raw Public Key #2&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public\
-key-format> -key-format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key> &lt;/public-key&gt;
</public-key-bag> &lt;/public-key-bag&gt;
</public-key-bags> &lt;/public-key-bags&gt;
</truststore> &lt;/truststore&gt;
]]></artwork> </sourcecode>
</section> </section>
<section toc="exclude"> <section toc="exclude" numbered="true" removeInRFC="false" pn="section-2
<name>A Certificate Expiration Notification</name> .2.2">
<t>The following example illustrates the "certificate-expiration" <name slugifiedName="name-a-certificate-expiration-no">A Certificate E
notification (per <xref section="2.1.4.6" target="I-D.ietf-netconf xpiration Notification</name>
-crypto-types"/>) <t indent="0" pn="section-2.2.2-1">The following example illustrates t
for a certificate configured in the truststore in <xref target="ts he "certificate-expiration"
-inst"/>.</t> notification (per <xref section="2.1.4.7" sectionFormat="of" targe
<artwork><![CDATA[ t="RFC9640" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9640#sec
tion-2.1.4.7" derivedContent="RFC9640"/>)
for a certificate configured in the truststore described in <xref targ
et="ts-inst" format="default" sectionFormat="of" derivedContent="Section 2.2.1"/
>.</t>
<sourcecode type="xml" markers="false" pn="section-2.2.2-2">
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<notification &lt;notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"&gt;
<eventTime>2018-05-25T00:01:00Z</eventTime> &lt;eventTime&gt;2018-05-25T00:01:00Z&lt;/eventTime&gt;
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"> &lt;truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"&gt;
<certificate-bags> &lt;certificate-bags&gt;
<certificate-bag> &lt;certificate-bag&gt;
<name>trusted-client-ee-certs</name> &lt;name&gt;trusted-client-ee-certs&lt;/name&gt;
<certificate> &lt;certificate&gt;
<name>George Jetson</name> &lt;name&gt;George Jetson&lt;/name&gt;
<certificate-expiration> &lt;certificate-expiration&gt;
<expiration-date>2024-01-05T14:18:53-05:00</expiration-d\ &lt;expiration-date&gt;2024-01-05T14:18:53-05:00&lt;/expiration-d\
ate> ate&gt;
</certificate-expiration> &lt;/certificate-expiration&gt;
</certificate> &lt;/certificate&gt;
</certificate-bag> &lt;/certificate-bag&gt;
</certificate-bags> &lt;/certificate-bags&gt;
</truststore> &lt;/truststore&gt;
</notification> &lt;/notification&gt;
</sourcecode>
]]></artwork>
</section> </section>
<section toc="exclude"> <section toc="exclude" numbered="true" removeInRFC="false" pn="section-2
<name>The "Local or Truststore" Groupings</name> .2.3">
<t>This section illustrates the various "inline-or-truststore" groupin <name slugifiedName="name-the-inline-or-truststore-gr">The "Inline or
gs Truststore" Groupings</name>
<t indent="0" pn="section-2.2.3-1">This section illustrates the variou
s "inline-or-truststore" groupings
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" format="defaul t" sectionFormat="of" derivedContent="Section 2.1.3.3"/>) 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" format=" default" sectionFormat="of" derivedContent="Section 2.1.3.4"/>)
groupings.</t> groupings.</t>
<t>These examples assume the existence of an example module called "ex <t indent="0" pn="section-2.2.3-2">These examples assume the existence
-truststore-usage" 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 indent="0" pn="section-2.2.3-3">The "ex-truststore-usage" module is
ms first presented using tree diagrams
<xref target="RFC8340"/>, followed by an instance example illustra <xref target="RFC8340" format="default" sectionFormat="of" derived
ting Content="RFC8340"/>, followed by an instance example illustrating
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 indent="0" pn="section-2.2.3-4">The following tree diagram illustra tes the "ex-truststore-usage" module without
expanding the "grouping" statements:</t> expanding the "grouping" statements:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.2.3-5">
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 indent="0" pn="section-2.2.3-6">The following tree diagram illustra
module, with all "grouping" statements expanded, enabling the tes the "ex-truststore-usage"
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" markers="false" pn="section-2.2.3-7">
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 863
+--:(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 indent="0" pn="section-2.2.3-8">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" format="default" sectionFormat=" of" derivedContent="Section 2.2.1"/>. 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" markers="false" pn="section-2.2.3-9">
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<truststore-usage &lt;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"&gt;
<!-- The following two equivalent examples illustrate --> &lt;!-- The following two equivalent examples illustrate --&gt;
<!-- the "inline-or-truststore-certs-grouping" grouping: --> &lt;!-- the "inline-or-truststore-certs-grouping" grouping: --&gt;
<cert> &lt;cert&gt;
<name>example 1a</name> &lt;name&gt;example 1a&lt;/name&gt;
<central-truststore-reference>trusted-client-ca-certs</central-t\ &lt;central-truststore-reference&gt;trusted-client-ca-certs&lt;/central-t\
ruststore-reference> ruststore-reference&gt;
</cert> &lt;/cert&gt;
<cert> &lt;cert&gt;
<name>example 1b</name> &lt;name&gt;example 1b&lt;/name&gt;
<inline-definition> &lt;inline-definition&gt;
<name>my-trusted-client-ca-certs</name> &lt;certificate&gt;
<certificate> &lt;name&gt;Client Identity Issuer #1&lt;/name&gt;
<name>Client Identity Issuer #1</name> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
<cert>BASE64VALUE=</cert> &lt;/certificate&gt;
</certificate> &lt;certificate&gt;
<certificate> &lt;name&gt;Client Identity Issuer #2&lt;/name&gt;
<name>Client Identity Issuer #2</name> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
<cert>BASE64VALUE=</cert> &lt;/certificate&gt;
</certificate> &lt;/inline-definition&gt;
</inline-definition> &lt;/cert&gt;
</cert>
<!-- The following two equivalent examples illustrate the --> &lt;!-- The following two equivalent examples illustrate the --&gt;
<!-- "inline-or-truststore-public-keys-grouping" grouping: --> &lt;!-- "inline-or-truststore-public-keys-grouping" grouping: --&gt;
<public-key> &lt;public-key&gt;
<name>example 2a</name> &lt;name&gt;example 2a&lt;/name&gt;
<central-truststore-reference>trusted-ssh-public-keys</central-t\ &lt;central-truststore-reference&gt;trusted-ssh-public-keys&lt;/central-t\
ruststore-reference> ruststore-reference&gt;
</public-key> &lt;/public-key&gt;
<public-key> &lt;public-key&gt;
<name>example 2b</name> &lt;name&gt;example 2b&lt;/name&gt;
<inline-definition> &lt;inline-definition&gt;
<name>trusted-ssh-public-keys</name> &lt;public-key&gt;
<public-key> &lt;name&gt;corp-fw1&lt;/name&gt;
<name>corp-fw1</name> &lt;public-key-format&gt;ct:ssh-public-key-format&lt;/public-key-form\
<public-key-format> at&gt;
ct:ssh-public-key-format &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
</public-key-format> &lt;/public-key&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;
</public-key> &lt;name&gt;corp-fw2&lt;/name&gt;
<public-key> &lt;public-key-format&gt;ct:ssh-public-key-format&lt;/public-key-form\
<name>corp-fw2</name> at&gt;
<public-key-format> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
ct:ssh-public-key-format &lt;/public-key&gt;
</public-key-format> &lt;/inline-definition&gt;
<public-key>BASE64VALUE=</public-key> &lt;/public-key&gt;
</public-key>
</inline-definition>
</public-key>
</truststore-usage> &lt;/truststore-usage&gt;
]]></artwork> </sourcecode>
<t>Following is the "ex-truststore-usage" module's YANG definition:</t <t indent="0" pn="section-2.2.3-10">Following is the "ex-truststore-us
> age" module's YANG definition:</t>
<artwork><![CDATA[ <sourcecode type="yang" markers="false" pn="section-2.2.3-11">
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&gt;"; "Author: YANG Designer <mailto:yang.designer@example.com&gt;";
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-10-10 {
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 990
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" numbered="true" removeInRFC="fals
<name>YANG Module</name> e" toc="include" pn="section-2.3">
<t>This YANG module imports modules from <xref target="RFC8341"/> <name slugifiedName="name-yang-module">YANG Module</name>
and <xref target="I-D.ietf-netconf-crypto-types"/>.</t> <t indent="0" pn="section-2.3-1">This YANG module imports modules from <
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-truststore@2024-03 xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC834
-16.yang"</t> 1"/>
<artwork><![CDATA[ and <xref target="RFC9640" format="default" sectionFormat="of" derived
Content="RFC9640"/>.</t>
<sourcecode type="yang" name="ietf-truststore@2024-10-10.yang" markers="
true" pn="section-2.3-2">
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 1008
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 &lt;mailto:netconf@ietf.org&gt;
Author : Kent Watsen <kent+ietf@watsen.net>"; Author: Kent Watsen &lt;kent+ietf@watsen.net&gt;";
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-10-10 {
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 1103
} }
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 1129
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 1243
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 1347
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" numbered="true" removeInRFC="false" toc="include
<name>Support for Built-in Trust Anchors</name> " pn="section-3">
<t>In some implementations, a server may define some built-in trust anchor <name slugifiedName="name-support-for-built-in-trust-">Support for Built-I
s. n Trust Anchors</name>
<t indent="0" pn="section-3-1">In some implementations, a server may defin
e some built-in trust anchors.
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" format="default" sectionFormat="of" deri
bootstrap server) or public CA certificates to connect to arbitrary We vedContent="RFC8572"/>
b bootstrap server) or public Certification Authority (CA) certificates
services using public PKI.</t> to connect to arbitrary web
<t>Built-in trust anchors are expected to be set by a vendor-specific proc services using PKI.</t>
ess. <t indent="0" pn="section-3-2">Built-in trust anchors are expected to be s
et by a vendor-specific process.
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 indent="0" pn="section-3-3">The primary characteristic of the built-in trust anchors is that they are
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; &lt;operational&gt; (<xref section="5.3" sectionFormat="of" target="RF
system&gt; C8342" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8342#section-
<xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t> 5.3" derivedContent="RFC8342"/>) and &lt;system&gt;
<t>The example below illustrates what the truststore in &lt;operational&gt <xref target="I-D.ietf-netmod-system-config" format="default" sectionF
; ormat="of" derivedContent="NETMOD-SYSTEM-CONFIG"/>, if implemented.</t>
<t indent="0" pn="section-3-4">The example below illustrates what the trus
tstore 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" markers="false" pn="section-3-5">
<truststore &lt;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"&gt;
<certificate-bags> &lt;certificate-bags&gt;
<certificate-bag or:origin="or:system"> &lt;certificate-bag or:origin="or:system"&gt;
<name>Built-In Manufacturer Trust Anchor Certificates</name> &lt;name&gt;Built-In Manufacturer Trust Anchor Certificates&lt;/name&gt;
<description> &lt;description&gt;
Certificates built into the device for authenticating Certificates built into the device for authenticating
manufacturer-signed objects, such as TLS server certificates, manufacturer-signed objects, such as TLS server certificates,
vouchers, etc. vouchers, etc.
</description> &lt;/description&gt;
<certificate> &lt;certificate&gt;
<name>Manufacturer Root CA Cert</name> &lt;name&gt;Manufacturer Root CA Cert&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificate-bag> &lt;/certificate-bag&gt;
<certificate-bag or:origin="or:system">
<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.
</description>
<certificate>
<name>Public Root CA Cert 1</name>
<cert-data>BASE64VALUE=</cert-data>
</certificate>
<certificate>
<name>Public Root CA Cert 2</name>
<cert-data>BASE64VALUE=</cert-data>
</certificate>
<certificate>
<name>Public Root CA Cert 3</name>
<cert-data>BASE64VALUE=</cert-data>
</certificate>
</certificate-bag>
</certificate-bags>
</truststore>
]]></artwork>
<!--
<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> &lt;certificate-bag or:origin="or:system"&gt;
<name>Built-In Public Trust Anchor Certificates</name> &lt;name&gt;Built-In Public Trust Anchor Certificates&lt;/name&gt;
<description> &lt;description&gt;
Certificates built into the device for authenticating Certificates built into the device for authenticating
certificates issued by public certificate authorities, certificates issued by public certificate authorities,
such as the end-entity certificate for web servers. such as the end-entity certificate for web servers.
&lt;/description&gt;
&lt;certificate&gt;
&lt;name&gt;Public Root CA Cert 1&lt;/name&gt;
&lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
&lt;/certificate&gt;
&lt;certificate&gt;
&lt;name&gt;Public Root CA Cert 2&lt;/name&gt;
&lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
&lt;/certificate&gt;
&lt;certificate&gt;
&lt;name&gt;Public Root CA Cert 3&lt;/name&gt;
&lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
&lt;/certificate&gt;
&lt;/certificate-bag&gt;
Only the subset of the certificates that are referenced &lt;/certificate-bags&gt;
by other configuration nodes need to be copied. For &lt;/truststore&gt;
instance, only "Public Root CA Cert 3" is present here. </sourcecode>
</section>
No new certificates can be added, nor existing certificate <section numbered="true" removeInRFC="false" toc="include" pn="section-4">
values changed. Missing certificates have no effect on <name slugifiedName="name-security-considerations">Security Considerations
"operational" when the configuration is applied. </name>
</description> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.1
<certificate> ">
<name>Public Root CA Cert 3</name> <name slugifiedName="name-security-of-data-at-rest">Security of Data at
<cert-data>BASE64VALUE=</cert-data> Rest</name>
</certificate> <t indent="0" pn="section-4.1-1">The YANG module specified in this docum
</certificate-bag> ent defines a mechanism called a
</certificate-bags>
</truststore>
]]></artwork>
</figure>
</t>
-->
</section>
<section>
<name>Security Considerations</name>
<section>
<name>Security of Data at Rest</name>
<t>The YANG module defined 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 indent="0" pn="section-4.1-2">Security controls for the API (i.e., da
discussed in <xref target="sec-mod"/>, but controls for the ta in motion) are
discussed in <xref target="sec-mod" format="default" sectionFormat="
of" derivedContent="Section 4.3"/>, 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 indent="0" pn="section-4.1-3">In order to satisfy the expectations of
implementations MUST ensure that the truststore contents are protect a "truststore", server
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 numbered="true" removeInRFC="false" toc="include" pn="section-4.2
<name>Unconstrained Public Key Usage</name> ">
<t>This module enables the configuration of public keys without <name slugifiedName="name-unconstrained-public-key-us">Unconstrained Pub
lic Key Usage</name>
<t indent="0" pn="section-4.2-1">This module enables the configuration o
f 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 indent="0" pn="section-4.2-2">Trust anchors configured via this modul
e 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" numbered="true" removeInRFC="false" toc="include
<name>Considerations for the "ietf-truststore" YANG Module</name> " pn="section-4.3">
<t>This section follows the template defined in <xref section="3.7.1" ta <name slugifiedName="name-considerations-for-the-ietf">Considerations fo
rget="RFC8407"/>.</t> r the "ietf-truststore" YANG Module</name>
<t>The YANG module defined in this document is designed to be accessed v <t indent="0" pn="section-4.3-1">This section is modeled after the templ
ia YANG ate defined in <xref section="3.7.1" sectionFormat="of" target="RFC8407" format=
based management protocols, such as NETCONF <xref target="RFC6241"/> "default" derivedLink="https://rfc-editor.org/rfc/rfc8407#section-3.7.1" derived
and Content="RFC8407"/>.</t>
RESTCONF <xref target="RFC8040"/>. Both of these protocols have man <t indent="0" pn="section-4.3-2">The "ietf-truststore" YANG module defin
datory-to-implement es "grouping" and "container" statements that are designed to be accessed via Y
secure transport layers (e.g., SSH, TLS) with mutual authentication. ANG-based management protocols, such as NETCONF <xref target="RFC6241" format="d
</t> efault" sectionFormat="of" derivedContent="RFC6241"/> and
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> prov RESTCONF <xref target="RFC8040" format="default" sectionFormat="of"
ides the means derivedContent="RFC8040"/>. These protocols have mandatory-to-implement
to restrict access for particular users to a pre-configured subset o secure transport layers (e.g., Secure Shell (SSH) <xref target="RFC4
f all available 252" format="default" sectionFormat="of" derivedContent="RFC4252"/>, TLS <xref t
arget="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>,
and QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedConte
nt="RFC9000"/>) and mandatory-to-implement mutual authentication.</t>
<t indent="0" pn="section-4.3-3">The Network Configuration Access Contro
l Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derive
dContent="RFC8341"/> provides the means
to restrict access for particular users to a preconfigured subset of all
available
protocol operations and content.</t> protocol operations and content.</t>
<t>Please be aware that this YANG module uses groupings from <t indent="0" pn="section-4.3-4">Please be aware that this YANG module u ses 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 indent="0" pn="section-4.3-5">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. extension for reasons described in <xref section="3.8" sectionFormat
ietf-netconf-crypto-types"/>.</t> ="of" target="RFC9640" format="default" derivedLink="https://rfc-editor.org/rfc/
<t>All the writable data nodes defined by this module, both in the rfc9640#section-3.8" derivedContent="RFC9640"/>.</t>
<t indent="0" pn="section-4.3-6">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 indent="0" pn="section-4.3-7">This module does not define any "rpc" o
thus the security considerations for such is not provided here.</t> r "action" statements, and
thus, the security considerations for such are not provided here.</t
>
</section> </section>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-5">
<name>IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-5.1
<name>The "IETF XML" Registry</name> ">
<t>This document registers one URI in the "ns" subregistry of <name slugifiedName="name-the-ietf-xml-registry">The IETF XML Registry</
the IETF XML Registry <xref target="RFC3688"/>. Following the name>
format in <xref target="RFC3688"/>, the following registration <t indent="0" pn="section-5.1-1">IANA has registered the following URI i
is requested:</t> n the "ns" registry defined of
<artwork><![CDATA[ the "IETF XML Registry" <xref target="RFC3688" format="default" sectionFormat=
URI: urn:ietf:params:xml:ns:yang:ietf-truststore "of" derivedContent="RFC3688"/>.</t>
Registrant Contact: The IESG <dl newline="false" spacing="compact" indent="3" pn="section-5.1-2">
XML: N/A, the requested URI is an XML namespace. <dt pn="section-5.1-2.1">URI:</dt>
]]></artwork> <dd pn="section-5.1-2.2">urn:ietf:params:xml:ns:yang:ietf-truststore</
dd>
<dt pn="section-5.1-2.3">Registrant Contact:</dt>
<dd pn="section-5.1-2.4">The IESG</dd>
<dt pn="section-5.1-2.5">XML:</dt>
<dd pn="section-5.1-2.6">N/A; the requested URI is an XML namespace.</
dd>
</dl>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-5.2
<name>The "YANG Module Names" Registry</name> ">
<t>This document registers one YANG module in the <name slugifiedName="name-the-yang-module-names-regis">The YANG Module N
YANG Module Names registry <xref target="RFC6020"/>. ames Registry</name>
Following the format in <xref target="RFC6020"/>, the <t indent="0" pn="section-5.2-1">IANA has registered the following YANG
following registration is requested:</t> module in the "YANG Module Names" registry defined in <xref target="RFC6020" for
<artwork><![CDATA[ mat="default" sectionFormat="of" derivedContent="RFC6020"/>.</t>
name: ietf-truststore <dl newline="false" spacing="compact" indent="3" pn="section-5.2-2">
namespace: urn:ietf:params:xml:ns:yang:ietf-truststore <dt pn="section-5.2-2.1">Name:</dt>
prefix: ts <dd pn="section-5.2-2.2">ietf-truststore</dd>
reference: RFC BBBB <dt pn="section-5.2-2.3">Namespace:</dt>
]]></artwork> <dd pn="section-5.2-2.4">urn:ietf:params:xml:ns:yang:ietf-truststore</
dd>
<dt pn="section-5.2-2.5">Prefix:</dt>
<dd pn="section-5.2-2.6">ts</dd>
<dt pn="section-5.2-2.7">Reference:</dt>
<dd pn="section-5.2-2.8">RFC 9641</dd>
</dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <displayreference target="I-D.ietf-netconf-http-client-server" to="HTTP-CLIE
<name>References</name> NT-SERVER"/>
<references> <displayreference target="I-D.ietf-netconf-netconf-client-server" to="NETCON
<name>Normative References</name> F-CLIENT-SERVER"/>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <displayreference target="I-D.ietf-netconf-restconf-client-server" to="RESTC
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> ONF-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netmod-system-config" to="NETMOD-SYSTEM-C
ONFIG"/>
<references pn="section-6">
<name slugifiedName="name-references">References</name>
<references pn="section-6.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit le> <title>Key words for use in RFCs to Indicate Requirement Levels</tit le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/> <date month="March" year="1997"/>
<abstract> <abstract>
<t>In many standards track documents several words are used to sig nify the requirements in the specification. These words are often capitalized. T his document defines these words as they should be interpreted in IETF documents . This document specifies an Internet Best Current Practices for the Internet Co mmunity, and requests discussion and suggestions for improvements.</t> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often cap italized. This document defines these words as they should be interpreted in IET F documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t >
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7 <reference anchor="RFC4252" target="https://www.rfc-editor.org/info/rfc4
950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"> 252" quoteTitle="true" derivedAnchor="RFC4252">
<front>
<title>The Secure Shell (SSH) Authentication Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L
onvick"/>
<date month="January" year="2006"/>
<abstract>
<t indent="0">The Secure Shell Protocol (SSH) is a protocol for se
cure remote login and other secure network services over an insecure network. Th
is document describes the SSH authentication protocol framework and public key,
password, and host-based client authentication methods. Additional authenticatio
n methods are described in separate documents. The SSH authentication protocol r
uns on top of the SSH transport layer protocol and provides a single authenticat
ed tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241" quoteTitle="true" derivedAnchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns
"/>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract>
<t indent="0">The Network Configuration Protocol (NETCONF) defined
in this document provides mechanisms to install, manipulate, and delete the con
figuration of network devices. It uses an Extensible Markup Language (XML)-based
data encoding for the configuration data as well as the protocol messages. The
NETCONF protocol operations are realized as remote procedure calls (RPCs). This
document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" quoteTitle="true" derivedAnchor="RFC7950">
<front> <front>
<title>The YANG 1.1 Data Modeling Language</title> <title>The YANG 1.1 Data Modeling Language</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/>
<date month="August" year="2016"/> <date month="August" year="2016"/>
<abstract> <abstract>
<t>YANG is a data modeling language used to model configuration da ta, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of t he YANG language. YANG version 1.1 is a maintenance release of the YANG language , addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document al so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).< /t> <t indent="0">YANG is a data modeling language used to model confi guration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of versi on 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YA NG language, addressing ambiguities and defects in the original specification. T here are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7950"/> <seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/> <seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference> </reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> 040" quoteTitle="true" derivedAnchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<date month="January" year="2017"/>
<abstract>
<t indent="0">This document describes an HTTP-based protocol that
provides a programmatic interface for accessing data defined in YANG, using the
datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/> <date month="May" year="2017"/>
<abstract> <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> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clari fying that only UPPERCASE usage of the key words have the defined special meanin gs.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </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"> <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8 341" quoteTitle="true" derivedAnchor="RFC8341">
<front> <front>
<title>Network Configuration Access Control Model</title> <title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/> <date month="March" year="2018"/>
<abstract> <abstract>
<t>The standardization of network configuration interfaces for use <t indent="0">The standardization of network configuration interfa
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ ces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF pr
ires a structured and secure operating environment that promotes human usability otocol requires a structured and secure operating environment that promotes huma
and multi-vendor interoperability. There is a need for standard mechanisms to r n usability and multi-vendor interoperability. There is a need for standard mech
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu anisms to restrict NETCONF or RESTCONF protocol access for particular users to a
red subset of all available NETCONF or RESTCONF protocol operations and content. preconfigured subset of all available NETCONF or RESTCONF protocol operations a
This document defines such an access control model.</t> nd content. This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t> <t indent="0">This document obsoletes RFC 6536.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="STD" value="91"/> <seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/> <seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/> <seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference> </reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
.ietf-netconf-crypto-types.xml"/> 446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to communi
cate over the Internet in a way that is designed to prevent eavesdropping, tampe
ring, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9
000" quoteTitle="true" derivedAnchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t indent="0">This document defines the core of the QUIC transport
protocol. QUIC provides applications with flow-controlled streams for structure
d communication, low-latency connection establishment, and network path migratio
n. QUIC includes security measures that ensure confidentiality, integrity, and a
vailability in a range of deployment circumstances. Accompanying documents descr
ibe the integration of TLS for key negotiation, loss detection, and an exemplary
congestion control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC9640" target="https://www.rfc-editor.org/info/rfc9
640" quoteTitle="true" derivedAnchor="RFC9640">
<front>
<title>YANG Data Types and Groupings for Cryptography</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9640"/>
<seriesInfo name="DOI" value="10.17487/RFC9640"/>
</reference>
</references> </references>
<references> <references pn="section-6.2">
<name>Informative References</name> <name slugifiedName="name-informative-references">Informative References
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 </name>
688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> <reference anchor="I-D.ietf-netconf-http-client-server" target="https://
datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-23" quoteTit
le="true" derivedAnchor="HTTP-CLIENT-SERVER">
<front> <front>
<title>The IETF XML Registry</title> <title>YANG Groupings for HTTP Clients and HTTP Servers</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/> <author fullname="Kent Watsen" initials="K." surname="Watsen">
<date month="January" year="2004"/> <organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date day="15" month="August" year="2024"/>
<abstract> <abstract>
<t>This document describes an IANA maintained registry for IETF st andards which use Extensible Markup Language (XML) related items such as Namespa ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew ork (RDF) Schemas.</t> <t indent="0">This document presents two YANG modules: the first d efines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these gr oupings will be used to help define the configuration for simple HTTP-based prot ocols (not for complete web servers or browsers). Support is provided for HTTP/1 .1, HTTP/2, and HTTP/3.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="81"/> <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-http-clien
<seriesInfo name="RFC" value="3688"/> t-server-23"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/> <refcontent>Work in Progress</refcontent>
</reference> </reference>
<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="I-D.ietf-netconf-netconf-client-server" target="https ://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-37" qu oteTitle="true" derivedAnchor="NETCONF-CLIENT-SERVER">
<front> <front>
<title>The Base16, Base32, and Base64 Data Encodings</title> <title>NETCONF Client and Server Models</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <author fullname="Kent Watsen" initials="K." surname="Watsen">
<date month="October" year="2006"/> <organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date day="14" month="August" year="2024"/>
<abstract> <abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded da ta, use of padding in encoded data, use of non-alphabet characters in encoded da ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA CK]</t> <t indent="0">This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server . Both modules support both the SSH and TLS transport protocols, and support bot h standard NETCONF and NETCONF Call Home connections. Editorial Note (To be remo ved by RFC Editor) This draft contains placeholder values that need to be replac ed with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specifi ed elsewhere in this document. Artwork in this document contains shorthand refer ences to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --&gt; the assigned RFC value for draft-ietf-netconf -crypto- types * BBBB --&gt; the assigned RFC value for draft-ietf-netconf-trust - anchors * CCCC --&gt; the assigned RFC value for draft-ietf-netconf-keystore * DDDD --&gt; the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --&gt; the assigned RFC value for draft-ietf-netconf-ssh-client- server * F FFF --&gt; the assigned RFC value for draft-ietf-netconf-tls-client- server * GG GG --&gt; the assigned RFC value for draft-ietf-netconf-http- client-server * HH HH --&gt; the assigned RFC value for this draft Artwork in this document contain s placeholder values for the date of publication of this draft. Please apply the following replacement: * 2024-08-14 --&gt; the publication date of this draft T he "Relation to other RFCs" section Section 1.1 contains the text "one or more Y ANG modules" and, later, "modules". This text is sourced from a file in a contex t 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 directly how many modules are define d. The "Relation to other RFCs" section Section 1.1 contains a self- reference t o this draft, along with a corresponding reference in the Appendix. Please repla ce the self-reference in this section with "This RFC" (or similar) and remove th e self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in 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 co nvert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" ma y be interpreted as, identify what looks ugly and ask the authors to make the ad justment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4648"/> <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-netconf-cl
<seriesInfo name="DOI" value="10.17487/RFC4648"/> ient-server-37"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6 020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"> <reference anchor="I-D.ietf-netmod-system-config" target="https://datatr acker.ietf.org/doc/html/draft-ietf-netmod-system-config-09" quoteTitle="true" de rivedAnchor="NETMOD-SYSTEM-CONFIG">
<front> <front>
<title>YANG - A Data Modeling Language for the Network Configuration <title>System-defined Configuration</title>
Protocol (NETCONF)</title> <author fullname="Qiufang Ma" initials="Q." surname="Ma">
<author fullname="M. Bjorklund" initials="M." role="editor" surname= <organization showOnFrontPage="true">Huawei</organization>
"Bjorklund"/> </author>
<date month="October" year="2010"/> <author fullname="Qin Wu" initials="Q." surname="Wu">
<organization showOnFrontPage="true">Huawei</organization>
</author>
<author fullname="Chong Feng" initials="C." surname="Feng"/>
<date day="29" month="September" year="2024"/>
<abstract> <abstract>
<t>YANG is a data modeling language used to model configuration an d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> <t indent="0">The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients. This docu ment introduces the concept of system configuration datastore holding configurat ion controlled by the system on which a server is running. The system configurat ion can be referenced (e.g., leafref) by configuration explicitly created by cli ents. This document updates RFC 8342.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6020"/> <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-system-conf
<seriesInfo name="DOI" value="10.17487/RFC6020"/> ig-09"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"> <reference anchor="I-D.ietf-netconf-restconf-client-server" target="http s://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-38" quoteTitle="true" derivedAnchor="RESTCONF-CLIENT-SERVER">
<front> <front>
<title>Network Configuration Protocol (NETCONF)</title> <title>RESTCONF Client and Server Models</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns <author fullname="Kent Watsen" initials="K." surname="Watsen">
"/> <organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date day="14" month="August" year="2024"/>
<abstract>
<t indent="0">This document presents two YANG modules, one module
to configure a RESTCONF client and the other module to configure a RESTCONF serv
er. Both modules support the TLS transport protocol with both standard RESTCONF
and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor)
This draft contains placeholder values that need to be replaced with finalized
values at the time of publication. This note summarizes all of the substitutions
that are needed. No other RFC Editor instructions are specified elsewhere in th
is document. Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements (note: not all may be present
): * AAAA --&gt; the assigned RFC value for draft-ietf-netconf-crypto- types * B
BBB --&gt; the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC -
-&gt; the assigned RFC value for draft-ietf-netconf-keystore * DDDD --&gt; the a
ssigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --&gt; the as
signed RFC value for draft-ietf-netconf-ssh-client- server * FFFF --&gt; the ass
igned RFC value for draft-ietf-netconf-tls-client- server * GGGG --&gt; the assi
gned RFC value for draft-ietf-netconf-http- client-server * HHHH --&gt; the assi
gned RFC value for draft-ietf-netconf-netconf- client-server * IIII --&gt; the a
ssigned RFC value for this draft Artwork in this document contains placeholder v
alues for the date of publication of this draft. Please apply the following repl
acement: * 2024-08-14 --&gt; the publication date of this draft The "Relation to
other RFCs" section Section 1.1 contains the text "one or more YANG modules" an
d, later, "modules". This text is sourced from a file in a context where it is u
nknown how many modules a draft defines. The text is not wrong as is, but it may
be improved by stating more directly how many modules are defined. The "Relatio
n to other RFCs" section Section 1.1 contains a self- reference to this draft, a
long with a corresponding reference in the Appendix. Please replace the self-ref
erence in this section with "This RFC" (or similar) and remove the self-referenc
e in the "Normative/Informative References" section, whichever it is in. Tree-di
agrams in this draft may use the '\' line-folding mode defined in RFC 8792. Howe
ver, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggest
ed suggested putting a request here for the RFC Editor to help convert "ugly" '\
' folded examples to use the '\\' folding mode. "Help convert" may be interprete
d as, identify what looks ugly and ask the authors to make the adjustment. The f
ollowing Appendix section is to be removed prior to publication: * Appendix A. C
hange Log</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-restconf-c
lient-server-38"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
688" quoteTitle="true" derivedAnchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/>
<abstract>
<t indent="0">This document describes an IANA maintained registry
for IETF standards which use Extensible Markup Language (XML) related items such
as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip
tion Framework (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
020" quoteTitle="true" derivedAnchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn <date month="October" year="2010"/>
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract> <abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do cument provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encod ing for the configuration data as well as the protocol messages. The NETCONF pro tocol operations are realized as remote procedure calls (RPCs). This document ob soletes RFC 4741. [STANDARDS-TRACK]</t> <t indent="0">YANG is a data modeling language used to model confi guration and state data manipulated by the Network Configuration Protocol (NETCO NF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK ]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6241"/> <seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/> <seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference> </reference>
<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"> <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8 259" quoteTitle="true" derivedAnchor="RFC8259">
<front> <front>
<title>RESTCONF Protocol</title> <title>The JavaScript Object Notation (JSON) Data Interchange Format
<author fullname="A. Bierman" initials="A." surname="Bierman"/> </title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="T. Bray" initials="T." role="editor" surname="Bray
<author fullname="K. Watsen" initials="K." surname="Watsen"/> "/>
<date month="January" year="2017"/> <date month="December" year="2017"/>
<abstract> <abstract>
<t>This document describes an HTTP-based protocol that provides a <t indent="0">JavaScript Object Notation (JSON) is a lightweight,
programmatic interface for accessing data defined in YANG, using the datastore c text-based, language-independent data interchange format. It was derived from th
oncepts defined in the Network Configuration Protocol (NETCONF).</t> e ECMAScript Programming Language Standard. JSON defines a small set of formatti
ng rules for the portable representation of structured data.</t>
<t indent="0">This document removes inconsistencies with other spe
cifications of JSON, repairs specification errors, and offers experience-based i
nteroperability guidance.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8040"/> <seriesInfo name="STD" value="90"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/> <seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference> </reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8 340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"> <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8 340" quoteTitle="true" derivedAnchor="RFC8340">
<front> <front>
<title>YANG Tree Diagrams</title> <title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be rger"/> <author fullname="L. Berger" initials="L." role="editor" surname="Be rger"/>
<date month="March" year="2018"/> <date month="March" year="2018"/>
<abstract> <abstract>
<t>This document captures the current syntax used in YANG module t ree diagrams. The purpose of this document is to provide a single location for t his definition. This syntax may be updated from time to time based on the evolut ion of the YANG language.</t> <t indent="0">This document captures the current syntax used in YA NG module tree diagrams. The purpose of this document is to provide a single loc ation for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="215"/> <seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/> <seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/> <seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference> </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"> <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8 342" quoteTitle="true" derivedAnchor="RFC8342">
<front> <front>
<title>Network Management Datastore Architecture (NMDA)</title> <title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae lder"/> <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/> <author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/> <author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/> <date month="March" year="2018"/>
<abstract> <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> <t indent="0">Datastores are a fundamental concept binding the dat a models written in the YANG data modeling language to network management protoc ols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This docu ment defines an architectural framework for datastores based on the experience g ained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8342"/> <seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/> <seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference> </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"> <reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8 407" quoteTitle="true" derivedAnchor="RFC8407">
<front> <front>
<title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="A. Bierman" initials="A." surname="Bierman"/>
<date month="October" year="2018"/> <date month="October" year="2018"/>
<abstract> <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> <t indent="0">This memo provides guidelines for authors and review ers of specifications containing YANG modules. Recommendations and procedures ar e defined, which are intended to increase interoperability and usability of Netw ork Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="216"/> <seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/> <seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/> <seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference> </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"> <reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8 572" quoteTitle="true" derivedAnchor="RFC8572">
<front> <front>
<title>Secure Zero Touch Provisioning (SZTP)</title> <title>Secure Zero Touch Provisioning (SZTP)</title>
<author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="I. Farrer" initials="I." surname="Farrer"/> <author fullname="I. Farrer" initials="I." surname="Farrer"/>
<author fullname="M. Abrahamsson" initials="M." surname="Abrahamsson "/> <author fullname="M. Abrahamsson" initials="M." surname="Abrahamsson "/>
<date month="April" year="2019"/> <date month="April" year="2019"/>
<abstract> <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> <t indent="0">This document presents a technique to securely provi sion a networking device when it is booting in a factory-default state. Variatio ns in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configu ration, and execute arbitrary scripts to address auxiliary needs. The updated de vice is subsequently able to establish secure connections with other systems. Fo r instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8572"/> <seriesInfo name="RFC" value="8572"/>
<seriesInfo name="DOI" value="10.17487/RFC8572"/> <seriesInfo name="DOI" value="10.17487/RFC8572"/>
</reference> </reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8
.ietf-netconf-trust-anchors.xml"/> 792" quoteTitle="true" derivedAnchor="RFC8792">
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <front>
.ietf-netconf-keystore.xml"/> <title>Handling Long Lines in Content of Internet-Drafts and RFCs</t
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D itle>
.ietf-netconf-tcp-client-server.xml"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
.ietf-netconf-ssh-client-server.xml"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <author fullname="Q. Wu" initials="Q." surname="Wu"/>
.ietf-netconf-tls-client-server.xml"/> <date month="June" year="2020"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <abstract>
.ietf-netconf-http-client-server.xml"/> <t indent="0">This document defines two strategies for handling lo
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D ng lines in width-bounded text content. One strategy, called the "single backsla
.ietf-netconf-netconf-client-server.xml"/> sh" strategy, is based on the historical use of a single backslash ('\') charact
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D er to indicate where line-folding has occurred, with the continuation occurring
.ietf-netconf-restconf-client-server.xml"/> with the first character that is not a space character (' ') on the next line. T
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D he second strategy, called the "double backslash" strategy, extends the first st
.ietf-netmod-system-config.xml"/> rategy by adding a second backslash character to identify where the continuation
begins and is thereby able to handle cases not supported by the first strategy.
Both strategies use a self-describing header enabling automated reconstitution
of the original content.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8792"/>
<seriesInfo name="DOI" value="10.17487/RFC8792"/>
</reference>
<reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9
642" quoteTitle="true" derivedAnchor="RFC9642">
<front>
<title>A YANG Data Model for a Keystore</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9642"/>
<seriesInfo name="DOI" value="10.17487/RFC9642"/>
</reference>
<reference anchor="RFC9643" target="https://www.rfc-editor.org/info/rfc9
643" quoteTitle="true" derivedAnchor="RFC9643">
<front>
<title>YANG Groupings for TCP Clients and TCP Servers</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<author initials="M." surname="Scharf" fullname="Michael Scharf">
<organization showOnFrontPage="true">Hochschule Esslingen - Univer
sity of Applied Sciences</organization>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9643"/>
<seriesInfo name="DOI" value="10.17487/RFC9643"/>
</reference>
<reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc9
644" quoteTitle="true" derivedAnchor="RFC9644">
<front>
<title>YANG Groupings for SSH Clients and SSH Servers</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9644"/>
<seriesInfo name="DOI" value="10.17487/RFC9644"/>
</reference>
<reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc9
645" quoteTitle="true" derivedAnchor="RFC9645">
<front>
<title>YANG Groupings for TLS Clients and TLS Servers</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9645"/>
<seriesInfo name="DOI" value="10.17487/RFC9645"/>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"/>
<author initials="J." surname="Paoli" fullname="Jean Paoli"/>
<author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. S
perberg-McQueen"/>
<author initials="E." surname="Maler" fullname="Eve Maler"/>
<author initials="F." surname="Yergeau" fullname="François Yergeau"/
>
<date month="November" year="2008"/>
</front>
<seriesInfo name="World Wide Web Consortium Recomm
endation" value="REC-xml-20081126"/>
</reference>
</references> </references>
</references> </references>
<section anchor="change-log"> <section numbered="false" removeInRFC="false" toc="include" pn="section-appe
<name>Change Log</name> ndix.a">
<section> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<name>00 to 01</name> <t indent="0" pn="section-appendix.a-1">The authors especially thank <cont
<ul spacing="normal"> act fullname="Henk Birkholz"/> for contributing YANG
<li>Added features "x509-certificates" and "ssh-host-keys".</li> to the "ietf-truststore" module supporting raw public keys and PSKs
<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">
<name>Acknowledgements</name>
<t>The authors especially thank Henk Birkholz for contributing 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 indent="0" pn="section-appendix.a-2">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>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization>
<address>
<email>kent+ietf@watsen.net</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 228 change blocks. 
1223 lines changed or deleted 1511 lines changed or added

This html diff was produced by rfcdiff 1.48.