rfc9642.original.xml | rfc9642.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!-- draft submitted in xml v3 --> | ||||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?rfc toc="yes"?> | ||||
<?rfc symrefs="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" | |||
<?rfc sortrefs="yes" ?> | submissionType="IETF" ipr="trust200902" docName="draft-ietf-netconf-keystore-35" | |||
<?rfc compact="yes"?> | number="9642" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs=" | |||
<?rfc subcompact="no"?> | true" sortRefs="true" version="3"> | |||
<?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-keystore-35" | ||||
tocInclude="true" symRefs="true" sortRefs="true" version="3"> | ||||
<!-- xml2rfc v2v3 conversion 3.17.4 --> | ||||
<front> | <front> | |||
<title>A YANG Data Model for a Keystore and Keystore Operations</title> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-keystore-35"/> | <!--[rfced] We have added a short title that spans the header of the | |||
PDF file. Please let us know if this text is agreeable or if | ||||
you prefer otherwise. | ||||
Current: | ||||
Keystore YANG | ||||
--> | ||||
<title abbrev="Keystore YANG">A YANG Data Model for a Keystore and Keystore | ||||
Operations</title> | ||||
<seriesInfo name="RFC" value="9642"/> | ||||
<author initials="K." surname="Watsen" fullname="Kent Watsen"> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
<organization>Watsen Networks</organization> | <organization>Watsen Networks</organization> | |||
<address> | <address> | |||
<email>kent+ietf@watsen.net</email> | <email>kent+ietf@watsen.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date/> | <date day="" month="August" year="2024"/> | |||
<area>Operations</area> | <area>OPS</area> | |||
<workgroup>NETCONF Working Group</workgroup> | <workgroup>netconf</workgroup> | |||
<!-- [rfced] Please insert any keywords (beyond those that appear in | ||||
the title) for use on https://www.rfc-editor.org/search. --> | ||||
<abstract> | <abstract> | |||
<t>This document presents a YANG module called "ietf-keystore" | <t>This document presents a YANG module called "ietf-keystore" | |||
that enables centralized configuration of both symmetric and | that enables centralized configuration of both symmetric and | |||
asymmetric keys. The secret value for both key types may be | asymmetric keys. The secret value for both key types may be | |||
encrypted or hidden. Asymmetric keys may be associated with | encrypted or hidden. Asymmetric keys may be associated with | |||
certificates. Notifications are sent when certificates are | certificates. Notifications are sent when certificates are | |||
about to expire.</t> | about to expire.</t> | |||
</abstract> | </abstract> | |||
<note> | ||||
<name>Editorial Note (To be removed by RFC Editor)</name> | ||||
<t>This draft contains placeholder values that need to be replaced | ||||
with finalized values at the time of publication. This note summarize | ||||
s | ||||
all of the substitutions that are needed. No other RFC Editor | ||||
instructions are specified elsewhere in this document.</t> | ||||
<t>Artwork in this document contains shorthand references to drafts in | ||||
progress. Please apply the following replacements: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<tt>AAAA</tt> --> the assigned RFC value for draft-ietf-netconf-cry | ||||
pto-types</li> | ||||
<li> | ||||
<tt>CCCC</tt> --> the assigned RFC value for this draft</li> | ||||
</ul> | ||||
<t>Artwork in this document contains placeholder values for the date of pu | ||||
blication of this | ||||
draft. Please apply the following replacement: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<tt>2024-03-16</tt> --> the publication date of this draft</li> | ||||
</ul> | ||||
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> | ||||
contains | ||||
the text "one or more YANG modules" and, later, "modules". This text | ||||
is sourced | ||||
from a file in a context where it is unknown how many modules a draft | ||||
defines. | ||||
The text is not wrong as is, but it may be improved by stating more di | ||||
rectly how | ||||
many modules are defined.</t> | ||||
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> | ||||
contains | ||||
a self-reference to this draft, along with a corresponding reference i | ||||
n | ||||
the Appendix. Please replace the self-reference in this section with | ||||
"This RFC" | ||||
(or similar) and remove the self-reference in the "Normative/Informati | ||||
ve References" | ||||
section, whichever it is in.</t> | ||||
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined i | ||||
n RFC 8792. | ||||
However, nicer-to-the-eye is when the '\\' line-folding mode is used. | ||||
The AD suggested | ||||
suggested putting a request here for the RFC Editor to help convert "u | ||||
gly" '\' folded | ||||
examples to use the '\\' folding mode. "Help convert" may be interpre | ||||
ted as, identify | ||||
what looks ugly and ask the authors to make the adjustment.</t> | ||||
<t>The following Appendix section is to be removed prior to publication: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<xref target="change-log"/>. Change Log</li> | ||||
</ul> | ||||
</note> | ||||
</front> | </front> | |||
<middle> | <middle> | |||
<section> | <section> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>This document presents a YANG 1.1 <xref target="RFC7950"/> module call ed | <t>This document presents a YANG 1.1 <xref target="RFC7950"/> module call ed | |||
"ietf-keystore" that enables centralized configuration of both symmetr ic | "ietf-keystore" that enables centralized configuration of both symmetr ic | |||
and asymmetric keys. The secret value for both key types may be | and asymmetric keys. The secret value for both key types may be | |||
encrypted or hidden (see <xref target="I-D.ietf-netconf-crypto-types"/ >). | encrypted or hidden (see <xref target="RFC9640"/>). | |||
Asymmetric keys may be associated with certificates. Notifications ar e | Asymmetric keys may be associated with certificates. Notifications ar e | |||
sent when certificates are about to expire.</t> | sent when certificates are about to expire.</t> | |||
<t>The "ietf-keystore" module defines many "grouping" statements | <t>The "ietf-keystore" module defines many "grouping" statements | |||
intended for use by other modules that may import it. For instance, | intended for use by other modules that may import it. For instance, | |||
there are groupings that define enabling a key to be either configured | there are groupings that define enabling a key to be configured | |||
inline (within the defining data model) or as a reference to a key | either inline (within the defining data model) or as a reference to a | |||
key | ||||
in the central keystore. | in the central keystore. | |||
</t> | </t> | |||
<t>Special consideration has been given for servers that have cryptographi c | <t>Special consideration has been given for servers that have cryptographi c | |||
hardware, such as a Trusted Platform Module (TPM). These servers are | hardware, such as a trusted platform module (TPM). These servers are | |||
unique in that the cryptographic hardware hides the secret key values. | unique in that the cryptographic hardware hides the secret key values. | |||
Additionally, such hardware is commonly initialized when manufactured | Additionally, such hardware is commonly initialized when manufactured | |||
to protect a "built-in" asymmetric key for which its public half is | to protect a "built-in" asymmetric key for which its public half is | |||
conveyed in an identity certificate (e.g., an IDevID | conveyed in an identity certificate (e.g., an Initial Device Identifie | |||
<xref target="Std-802.1AR-2018"/> certificate). Please see | r (IDevID) | |||
<xref target="built-ins"/> to see how built-in keys are supported.</t> | <xref target="Std-802.1AR-2018"/> certificate). See how built-in keys | |||
are | ||||
supported in <xref target="built-ins"/>.</t> | ||||
<t>This document is intended to reflect existing practices that many | <t>This document is intended to reflect existing practices that many | |||
server implementations support at the time of writing. To simplify | server implementations support at the time of writing. To simplify | |||
implementation, advanced key formats may be selectively implemented.</ t> | implementation, advanced key formats may be selectively implemented.</ t> | |||
<t>Implementations may utilize operating-system level | <t>Implementations may utilize operating-system level | |||
keystore utilities (e.g., "Keychain Access" on MacOS) and/or cryptogra phic | keystore utilities (e.g., "Keychain Access" on MacOS) and/or cryptogra phic | |||
hardware (e.g., TPMs).</t> | hardware (e.g., TPMs).</t> | |||
<section anchor="collective-effort"> | <section anchor="collective-effort"> | |||
<name>Relation to other RFCs</name> | <name>Relation to Other RFCs</name> | |||
<t>This document presents one or more YANG modules <xref target="RFC7950 | <t>This document presents a YANG module <xref target="RFC7950"/> | |||
"/> | that is part of a collection of RFCs that work together | |||
that are part of a collection of RFCs that work together | to ultimately support the configuration of both the clients | |||
to, ultimately, support the configuration of both the clients | and servers of the Network Configuration Protocol (NETCONF) <xref ta | |||
and servers of both the NETCONF <xref target="RFC6241"/> and | rget="RFC6241"/> and | |||
RESTCONF <xref target="RFC8040"/> protocols.</t> | RESTCONF <xref target="RFC8040"/>.</t> | |||
<t> The dependency relationship between the primary YANG groupings | <t> The dependency relationship between the primary YANG groupings | |||
defined in the various RFCs is presented in the below diagram. | defined in the various RFCs is presented in the diagram below. | |||
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 the shorthand names are provided | |||
below | ||||
the diagram.</t> | the diagram.</t> | |||
<t>Please note that the arrows in the diagram point from referencer | <t>Please note that the arrows in the diagram point from referencer | |||
to referenced. For example, the "crypto-types" RFC does not | to referenced. For example, the "crypto-types" RFC does not | |||
have any dependencies, whilst the "keystore" RFC depends on the | have any dependencies, whilst the "keystore" RFC depends on the | |||
"crypto-types" RFC.</t> | "crypto-types" RFC.</t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
crypto-types | crypto-types | |||
^ ^ | ^ ^ | |||
/ \ | / \ | |||
/ \ | / \ | |||
skipping to change at line 160 ¶ | skipping to change at line 121 ¶ | |||
| | | +-----+ +---------+ | | | | | +-----+ +---------+ | | |||
| | | | | | | | | | | | | | |||
| +-----------|--------|--------------+ | | | | +-----------|--------|--------------+ | | | |||
| | | | | | | | | | | | | | |||
+-----------+ | | | | | | +-----------+ | | | | | | |||
| | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | |||
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 | <!-- RFC Editor: is there anyway to flush-left the table in PDF/HTML views? --> | |||
ws? --> | <table align="left"> | |||
<table> | <name>Labels in Diagram to RFC Mapping</name> | |||
<name>Label in Diagram to RFC Mapping</name> | ||||
<tbody> | <tbody> | |||
<tr> | <tr> | |||
<th>Label in Diagram</th> | <th>Label in Diagram</th> | |||
<th>Originating RFC</th> | <th>Originating RFC</th> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>crypto-types</td> | <td>crypto-types</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-crypto-types"/></td> | <xref target="RFC9640"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>truststore</td> | <td>truststore</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-trust-anchors"/></td> | <xref target="RFC9641"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>keystore</td> | <td>keystore</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-keystore"/></td> | RFC 9642</td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>tcp-client-server</td> | <td>tcp-client-server</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-tcp-client-server"/></td> | <xref target="RFC9643"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>ssh-client-server</td> | <td>ssh-client-server</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-ssh-client-server"/></td> | <xref target="RFC9644"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>tls-client-server</td> | <td>tls-client-server</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-tls-client-server"/></td> | <xref target="RFC9645"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>http-client-server</td> | <td>http-client-server</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-http-client-server"/></td> | <xref target="I-D.ietf-netconf-http-client-server"/></td> | |||
</tr> | </tr> | |||
<tr> | <tr> | |||
<td>netconf-client-server</td> | <td>netconf-client-server</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-netconf-client-server"/></td> | <xref target="I-D.ietf-netconf-netconf-client-server"/></td> | |||
skipping to change at line 218 ¶ | skipping to change at line 179 ¶ | |||
<tr> | <tr> | |||
<td>restconf-client-server</td> | <td>restconf-client-server</td> | |||
<td> | <td> | |||
<xref target="I-D.ietf-netconf-restconf-client-server"/></td> | <xref target="I-D.ietf-netconf-restconf-client-server"/></td> | |||
</tr> | </tr> | |||
</tbody> | </tbody> | |||
</table> | </table> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Specification Language</name> | <name>Specification Language</name> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | <t> | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
"MAY", and "OPTIONAL" in this document are to be interpreted as | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14> | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/ | ", | |||
> | "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
when, and only when, they appear in all capitals, as shown here.</t> | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | ||||
be | ||||
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref | ||||
target="RFC8174"/> when, and only when, they appear in all capitals, as | ||||
shown here. | ||||
</t> | ||||
</section> | </section> | |||
<section> | <section> | |||
<name>Terminology</name> | <name>Terminology</name> | |||
<t>The terms "client" and "server" are defined in <xref target="RFC6241" /> and are not redefined here.</t> | <t>The terms "client" and "server" are defined in <xref target="RFC6241" /> and are not redefined here.</t> | |||
<t>The term "keystore" is defined in this document as a mechanism that i ntends to safeguard secrets.</t> | <t>The term "keystore" is defined in this document as a mechanism that i ntends to safeguard secrets.</t> | |||
<t>The nomenclature "<running>" and "<operational>" are defi ned in <xref target="RFC8342"/>.</t> | <t>The nomenclatures "<running>" and "<operational>" are def ined in <xref target="RFC8342"/>.</t> | |||
<t>The sentence fragments "augmented" and "augmented in" are used herein as the past tense verbified | <t>The sentence fragments "augmented" and "augmented in" are used herein as the past tense verbified | |||
form of the "augment" statement defined in <xref section="7.17" targ et="RFC7950"/>.</t> | form of the "augment" statement defined in <xref target="RFC7950" se ctionFormat="of" section="7.17"/>.</t> | |||
<t>The term "key" may be used to mean one of three things in this docume nt: 1) the YANG-defined | <t>The term "key" may be used to mean one of three things in this docume nt: 1) the YANG-defined | |||
"asymmetric-key" or "symmetric-key" node defined in this document, 2 ) the raw key data possessed by the | "asymmetric-key" or "symmetric-key" node defined in this document, 2 ) the raw key data possessed by the | |||
aforementioned key nodes, and 3) the "key" of a YANG "list" statemen | aforementioned key nodes, or 3) the "key" of a YANG "list" statement | |||
t. This | . | |||
document attempts to always qualify types '2' and '3' using, "raw ke | ||||
y value" and | <!--[rfced] The phrasing "attempts to always" is confusing. May we | |||
update the text as shown below for clarity? | ||||
Original: | ||||
This document attempts to always qualify types '2' and | ||||
'3' using, "raw key value" and "YANG list key" where needed. | ||||
Perhaps: | ||||
This document qualifies types '2' and '3' using "raw key value" | ||||
and "YANG list key" where needed. | ||||
--> | ||||
This | ||||
document attempts to always qualify types '2' and '3' using "raw key | ||||
value" and | ||||
"YANG list key" where needed. In all other cases, an unqualified "k ey" refers to a YANG-defined | "YANG list key" where needed. In all other cases, an unqualified "k ey" refers to a YANG-defined | |||
"asymmetric-key" or "symmetric-key" node.</t> | "asymmetric-key" or "symmetric-key" node.</t> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Adherence to the NMDA</name> | <name>Adherence to the NMDA</name> | |||
<t>This document is compliant with Network Management Datastore Architec ture | <t>This document is compliant with Network Management Datastore Architec ture | |||
(NMDA) <xref target="RFC8342"/>. For instance, keys and associated | (NMDA) <xref target="RFC8342"/>. For instance, keys and associated | |||
certificates installed during manufacturing (e.g., for an IDevID | certificates installed during manufacturing (e.g., for an IDevID | |||
certificate) are expected to appear in <operational> | certificate) are expected to appear in <operational> | |||
(see <xref target="built-ins"/>).</t> | (see <xref target="built-ins"/>).</t> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Conventions</name> | <name>Conventions</name> | |||
<t>Various examples in this document use "BASE64VALUE=" as a | <t>Various examples in this document use "BASE64VALUE=" as a | |||
placeholder value for binary data that has been base64 | placeholder value for binary data that has been base64-encoded | |||
encoded (per <xref section="9.8" target="RFC7950"/>). This | (per <xref target="RFC7950" sectionFormat="of" section="9.8"/>). Th | |||
placeholder value is used because real base64 encoded structures | is | |||
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 "keystore" | <t>This document uses the adjective "central" to the word "keystore" | |||
to refer to the top-level instance of the "keystore-grouping", when | to refer to the top-level instance of the "keystore-grouping", when | |||
the "central-keystore-supported" feature is enabled. Please be | the "central-keystore-supported" feature is enabled. Please be | |||
aware that consuming YANG modules MAY instantiate the "keystore-grou ping" | aware that consuming YANG modules <bcp14>MAY</bcp14> instantiate the "keystore-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> | |||
<!-- | <!-- | |||
<t>For the trusted-certificates list, Trust Anchor Format | <t>For the trusted-certificates list, Trust Anchor Format | |||
<xref target="RFC5914"/> was evaluated and deemed inappropriate due | <xref target="RFC5914"/> was evaluated and deemed inappropriate due | |||
to this document's need to also support pinning. That is, pinning | to this document's need to also support pinning. That is, pinning | |||
a client-certificate to support NETCONF over TLS client authentication.< /t> | a client-certificate to support NETCONF over TLS client authentication.< /t> | |||
--> | --> | |||
skipping to change at line 285 ¶ | skipping to change at line 264 ¶ | |||
defined in <xref target="keystore-yang-module"/>.</t> | defined in <xref target="keystore-yang-module"/>.</t> | |||
<section anchor="overview"> | <section anchor="overview"> | |||
<name>Data Model Overview</name> | <name>Data Model Overview</name> | |||
<t>This section provides an overview of the "ietf-keystore" module | <t>This section provides an overview of the "ietf-keystore" module | |||
in terms of its features, typedefs, groupings, and protocol-accessib le | in terms of its features, typedefs, groupings, and protocol-accessib le | |||
nodes.</t> | nodes.</t> | |||
<section anchor="features" toc="exclude"> | <section anchor="features" toc="exclude"> | |||
<name>Features</name> | <name>Features</name> | |||
<t>The following diagram lists all the "feature" statements | <t>The following diagram lists all the "feature" statements | |||
defined in the "ietf-keystore" module:</t> | defined in the "ietf-keystore" module:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
Features: | Features: | |||
+-- central-keystore-supported | +-- central-keystore-supported | |||
+-- inline-definitions-supported | +-- inline-definitions-supported | |||
+-- asymmetric-keys | +-- asymmetric-keys | |||
+-- symmetric-keys | +-- symmetric-keys | |||
]]></artwork> | ]]></sourcecode> | |||
<!--<aside>--> | <!--<aside>--> | |||
<t>The diagram above uses syntax that is similar to but not | <t>The diagram above uses syntax that is similar to but not | |||
defined in <xref target="RFC8340"/>.</t> | defined in <xref target="RFC8340"/>.</t> | |||
<!--</aside>--> | <!--</aside>--> | |||
</section> | </section> | |||
<section anchor="typedefs" toc="exclude"> | <section anchor="typedefs" toc="exclude"> | |||
<name>Typedefs</name> | <name>Typedefs</name> | |||
<t>The following diagram lists the "typedef" statements defined in | <t>The following diagram lists the "typedef" statements defined in | |||
the "ietf-keystore" module:</t> | the "ietf-keystore" module:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
Typedefs: | Typedefs: | |||
leafref | leafref | |||
+-- central-symmetric-key-ref | +-- central-symmetric-key-ref | |||
+-- central-asymmetric-key-ref | +-- central-asymmetric-key-ref | |||
]]></artwork> | ]]></sourcecode> | |||
<!--<aside>--> | <!--<aside>--> | |||
<t>The diagram above uses syntax that is similar to but not | <t>The diagram above uses syntax that is similar to but not | |||
defined in <xref target="RFC8340"/>.</t> | defined in <xref target="RFC8340"/>.</t> | |||
<!--</aside>--> | <!--</aside>--> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>All the typedefs defined in the "ietf-keystore" module | <li>All the typedefs defined in the "ietf-keystore" module | |||
extend the base "leafref" type defined in <xref target="RFC7950" />.</li> | extend the base "leafref" type defined in <xref target="RFC7950" />.</li> | |||
<li>The leafrefs refer to symmetric and asymmetric keys in the | <li>The leafrefs refer to symmetric and asymmetric keys in the | |||
central keystore, when this module is implemented.</li> | central keystore when this module is implemented.</li> | |||
<li>These typedefs are provided as an aid to consuming | <li>These typedefs are provided as an aid to consuming | |||
modules that import the "ietf-keystore" module.</li> | modules that import the "ietf-keystore" module.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>Groupings</name> | <name>Groupings</name> | |||
<t>The "ietf-keystore" module defines the following "grouping" stateme nts:</t> | <t>The "ietf-keystore" module defines the following "grouping" stateme nts:</t> | |||
<ul spacing="compact"> | <ul spacing="compact"> | |||
<li>encrypted-by-grouping</li> | <li>encrypted-by-grouping</li> | |||
<li>central-asymmetric-key-certificate-ref-grouping</li> | <li>central-asymmetric-key-certificate-ref-grouping</li> | |||
skipping to change at line 338 ¶ | skipping to change at line 317 ¶ | |||
<li>inline-or-keystore-asymmetric-key-grouping</li> | <li>inline-or-keystore-asymmetric-key-grouping</li> | |||
<li>inline-or-keystore-asymmetric-key-with-certs-grouping</li> | <li>inline-or-keystore-asymmetric-key-with-certs-grouping</li> | |||
<li>inline-or-keystore-end-entity-cert-with-key-grouping</li> | <li>inline-or-keystore-end-entity-cert-with-key-grouping</li> | |||
<li>keystore-grouping</li> | <li>keystore-grouping</li> | |||
</ul> | </ul> | |||
<t>Each of these groupings are presented in the following subsections. </t> | <t>Each of these groupings are presented in the following subsections. </t> | |||
<section anchor="encrypted-by-grouping"> | <section anchor="encrypted-by-grouping"> | |||
<name>The "encrypted-by-grouping" Grouping</name> | <name>The "encrypted-by-grouping" Grouping</name> | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"encrypted-by-grouping" grouping:</t> | "encrypted-by-grouping" grouping:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping encrypted-by-grouping: | grouping encrypted-by-grouping: | |||
+-- (encrypted-by) | +-- (encrypted-by) | |||
+--:(central-symmetric-key-ref) | +--:(central-symmetric-key-ref) | |||
| {central-keystore-supported,symmetric-keys}? | | {central-keystore-supported,symmetric-keys}? | |||
| +-- symmetric-key-ref? ks:central-symmetric-key-ref | | +-- symmetric-key-ref? ks:central-symmetric-key-ref | |||
+--:(central-asymmetric-key-ref) | +--:(central-asymmetric-key-ref) | |||
{central-keystore-supported,asymmetric-keys}? | {central-keystore-supported,asymmetric-keys}? | |||
+-- asymmetric-key-ref? ks:central-asymmetric-key-ref | +-- asymmetric-key-ref? ks:central-asymmetric-key-ref | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>This grouping defines a "choice" statement with options to ref erence | <li>This grouping defines a "choice" statement with options to ref erence | |||
either a symmetric or an asymmetric key configured in the keys tore.</li> | either a symmetric or an asymmetric key configured in the keys tore.</li> | |||
<li>This grouping is usable only when the keystore module is imple mented. | <li>This grouping is usable only when the keystore module is imple mented. | |||
Servers defining custom keystore locations MUST augment in alt ernate | Servers defining custom keystore locations <bcp14>MUST</bcp14> augment in alternate | |||
"encrypted-by" references to the alternate locations.</li> | "encrypted-by" references to the alternate locations.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="central-asymmetric-key-certificate-ref-grouping"> | <section anchor="central-asymmetric-key-certificate-ref-grouping"> | |||
<name>The "central-asymmetric-key-certificate-ref-grouping" Grouping </name> | <name>The "central-asymmetric-key-certificate-ref-grouping" Grouping </name> | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"central-asymmetric-key-certificate-ref-grouping" grouping:</t> | "central-asymmetric-key-certificate-ref-grouping" grouping:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping central-asymmetric-key-certificate-ref-grouping: | grouping central-asymmetric-key-certificate-ref-grouping: | |||
+-- asymmetric-key? ks:central-asymmetric-key-ref | +-- asymmetric-key? ks:central-asymmetric-key-ref | |||
| {central-keystore-supported,asymmetric-keys}? | | {central-keystore-supported,asymmetric-keys}? | |||
+-- certificate? leafref | +-- certificate? leafref | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>This grouping defines a reference to a certificate in two part s: the | <li>This grouping defines a reference to a certificate in two part s: the | |||
first being the name of the asymmetric key the certificate is associated | first being the name of the asymmetric key the certificate is associated | |||
with, and the second being the name of the certificate itself. </li> | with, and the second being the name of the certificate itself. </li> | |||
<li>This grouping is usable only when the keystore module is imple mented. | <li>This grouping is usable only when the keystore module is imple mented. | |||
Servers defining custom keystore locations can define an alter nate grouping | Servers defining custom keystore locations can define an alter nate grouping | |||
for references to the alternate locations.</li> | for references to the alternate locations.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="inline-or-keystore-symmetric-key-grouping"> | <section anchor="inline-or-keystore-symmetric-key-grouping"> | |||
<name>The "inline-or-keystore-symmetric-key-grouping" Grouping</name > | <name>The "inline-or-keystore-symmetric-key-grouping" Grouping</name > | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"inline-or-keystore-symmetric-key-grouping" grouping:</t> | "inline-or-keystore-symmetric-key-grouping" grouping:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping inline-or-keystore-symmetric-key-grouping: | grouping inline-or-keystore-symmetric-key-grouping: | |||
+-- (inline-or-keystore) | +-- (inline-or-keystore) | |||
+--:(inline) {inline-definitions-supported}? | +--:(inline) {inline-definitions-supported}? | |||
| +-- inline-definition | | +-- inline-definition | |||
| +---u ct:symmetric-key-grouping | | +---u ct:symmetric-key-grouping | |||
+--:(central-keystore) | +--:(central-keystore) | |||
{central-keystore-supported,symmetric-keys}? | {central-keystore-supported,symmetric-keys}? | |||
+-- central-keystore-reference? | +-- central-keystore-reference? | |||
ks:central-symmetric-key-ref | ks:central-symmetric-key-ref | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<!--[rfced] For clarity and better sentence flow, may we remove | ||||
"whether" and add "either" as shown below (note that there are | ||||
four instances)? | ||||
Original: | ||||
The "inline-or-keystore-symmetric-key-grouping" grouping is provided | ||||
solely as convenience to consuming modules that wish to offer an | ||||
option for whether a symmetric key is defined inline or as a | ||||
reference to a symmetric key in the keystore. | ||||
Perhaps: | ||||
The "inline-or-keystore-symmetric-key-grouping" grouping is provided | ||||
solely as convenience to consuming modules that wish to offer an | ||||
option for a symmetric key that is defined either inline or as a | ||||
reference to a symmetric key in the keystore. | ||||
--> | ||||
<ul> | <ul> | |||
<li>The "inline-or-keystore-symmetric-key-grouping" grouping is pr ovided | <li>The "inline-or-keystore-symmetric-key-grouping" grouping is pr ovided | |||
solely as convenience to consuming modules that wish to offer | solely as convenience to consuming modules that wish to offer | |||
an option for whether a symmetric key is defined inline | an option for whether a symmetric key is defined inline | |||
or as a reference to a symmetric key in the keystore.</li> | or as a reference to a symmetric key in the keystore.</li> | |||
<li>A "choice" statement is used to expose the various options. | <li>A "choice" statement is used to expose the various options. | |||
Each option is enabled by a "feature" statement. Additional | Each option is enabled by a "feature" statement. Additional | |||
"case" statements MAY be augmented in if, e.g., there is a | "case" statements <bcp14>MAY</bcp14> be augmented in if, e.g., there is a | |||
need to reference a symmetric key in an alternate location.</l i> | need to reference a symmetric key in an alternate location.</l i> | |||
<li>For the "inline-definition" option, the definition uses the | <li>For the "inline-definition" option, the definition uses the | |||
"symmetric-key-grouping" grouping discussed in <xref section=" 2.1.4.3" target="I-D.ietf-netconf-crypto-types"/>.</li> | "symmetric-key-grouping" grouping discussed in <xref target="R FC9640" sectionFormat="of" section="2.1.4.3"/>.</li> | |||
<li>For the "central-keystore" option, the "central-keystore-refer ence" is an | <li>For the "central-keystore" option, the "central-keystore-refer ence" is an | |||
instance of the "symmetric-key-ref" discussed in <xref target= "typedefs"/>.</li> | instance of the "symmetric-key-ref" discussed in <xref target= "typedefs"/>.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="inline-or-keystore-asymmetric-key-grouping"> | <section anchor="inline-or-keystore-asymmetric-key-grouping"> | |||
<name>The "inline-or-keystore-asymmetric-key-grouping" Grouping</nam e> | <name>The "inline-or-keystore-asymmetric-key-grouping" Grouping</nam e> | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"inline-or-keystore-asymmetric-key-grouping" grouping:</t> | "inline-or-keystore-asymmetric-key-grouping" grouping:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping inline-or-keystore-asymmetric-key-grouping: | grouping inline-or-keystore-asymmetric-key-grouping: | |||
+-- (inline-or-keystore) | +-- (inline-or-keystore) | |||
+--:(inline) {inline-definitions-supported}? | +--:(inline) {inline-definitions-supported}? | |||
| +-- inline-definition | | +-- inline-definition | |||
| +---u ct:asymmetric-key-pair-grouping | | +---u ct:asymmetric-key-pair-grouping | |||
+--:(central-keystore) | +--:(central-keystore) | |||
{central-keystore-supported,asymmetric-keys}? | {central-keystore-supported,asymmetric-keys}? | |||
+-- central-keystore-reference? | +-- central-keystore-reference? | |||
ks:central-asymmetric-key-ref | ks:central-asymmetric-key-ref | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>The "inline-or-keystore-asymmetric-key-grouping" grouping is p rovided | <li>The "inline-or-keystore-asymmetric-key-grouping" grouping is p rovided | |||
solely as convenience to consuming modules that wish to offer | solely as convenience to consuming modules that wish to offer | |||
an option for whether an asymmetric key is defined inline | an option for whether an asymmetric key is defined inline | |||
or as a reference to an asymmetric key in the keystore.</li> | or as a reference to an asymmetric key in the keystore.</li> | |||
<li>A "choice" statement is used to expose the various options. | <li>A "choice" statement is used to expose the various options. | |||
Each option is enabled by a "feature" statement. Additional | Each option is enabled by a "feature" statement. Additional | |||
"case" statements MAY be augmented in if, e.g., there is a | "case" statements <bcp14>MAY</bcp14> be augmented in if, e.g., there is a | |||
need to reference an asymmetric key in an alternate location.< /li> | need to reference an asymmetric key in an alternate location.< /li> | |||
<li>For the "inline-definition" option, the definition uses the | <li>For the "inline-definition" option, the definition uses the | |||
"asymmetric-key-pair-grouping" grouping discussed in <xref sec tion="2.1.4.6" target="I-D.ietf-netconf-crypto-types"/>.</li> | "asymmetric-key-pair-grouping" grouping discussed in <xref tar get="RFC9640" sectionFormat="of" section="2.1.4.6"/>.</li> | |||
<li>For the "central-keystore" option, the "central-keystore-refer ence" is an | <li>For the "central-keystore" option, the "central-keystore-refer ence" is an | |||
instance of the "asymmetric-key-ref" typedef discussed in | instance of the "asymmetric-key-ref" typedef discussed in | |||
<xref target="typedefs"/>.</li> | <xref target="typedefs"/>.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="inline-or-keystore-asymmetric-key-with-certs-grouping "> | <section anchor="inline-or-keystore-asymmetric-key-with-certs-grouping "> | |||
<name>The "inline-or-keystore-asymmetric-key-with-certs-grouping" Gr ouping</name> | <name>The "inline-or-keystore-asymmetric-key-with-certs-grouping" Gr ouping</name> | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"inline-or-keystore-asymmetric-key-with-certs-grouping" grouping :</t> | "inline-or-keystore-asymmetric-key-with-certs-grouping" grouping :</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping inline-or-keystore-asymmetric-key-with-certs-grouping: | grouping inline-or-keystore-asymmetric-key-with-certs-grouping: | |||
+-- (inline-or-keystore) | +-- (inline-or-keystore) | |||
+--:(inline) {inline-definitions-supported}? | +--:(inline) {inline-definitions-supported}? | |||
| +-- inline-definition | | +-- inline-definition | |||
| +---u ct:asymmetric-key-pair-with-certs-grouping | | +---u ct:asymmetric-key-pair-with-certs-grouping | |||
+--:(central-keystore) | +--:(central-keystore) | |||
{central-keystore-supported,asymmetric-keys}? | {central-keystore-supported,asymmetric-keys}? | |||
+-- central-keystore-reference? | +-- central-keystore-reference? | |||
ks:central-asymmetric-key-ref | ks:central-asymmetric-key-ref | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>The "inline-or-keystore-asymmetric-key-with-certs-grouping" gr ouping is provided | <li>The "inline-or-keystore-asymmetric-key-with-certs-grouping" gr ouping is provided | |||
solely as convenience to consuming modules that wish to offer | solely as convenience to consuming modules that wish to offer | |||
an option for whether an asymmetric key is defined inline | an option for whether an asymmetric key is defined inline | |||
or as a reference to an asymmetric key in the keystore.</li> | or as a reference to an asymmetric key in the keystore.</li> | |||
<li>A "choice" statement is used to expose the various options. | <li>A "choice" statement is used to expose the various options. | |||
Each option is enabled by a "feature" statement. Additional | Each option is enabled by a "feature" statement. Additional | |||
"case" statements MAY be augmented in if, e.g., there is a | "case" statements <bcp14>MAY</bcp14> be augmented in if, e.g., there is a | |||
need to reference an asymmetric key in an alternate location.< /li> | need to reference an asymmetric key in an alternate location.< /li> | |||
<li>For the "inline-definition" option, the definition uses the | <li>For the "inline-definition" option, the definition uses the | |||
"asymmetric-key-pair-with-certs-grouping" grouping discussed i n <xref section="2.1.4.12" target="I-D.ietf-netconf-crypto-types"/>.</li> | "asymmetric-key-pair-with-certs-grouping" grouping discussed i n <xref target="RFC9640" sectionFormat="of" section="2.1.4.12"/>.</li> | |||
<li>For the "central-keystore" option, the "central-keystore-refer ence" is an | <li>For the "central-keystore" option, the "central-keystore-refer ence" is an | |||
instance of the "asymmetric-key-ref" typedef discussed in | instance of the "asymmetric-key-ref" typedef discussed in | |||
<xref target="typedefs"/>.</li> | <xref target="typedefs"/>.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="inline-or-keystore-end-entity-cert-with-key-grouping" > | <section anchor="inline-or-keystore-end-entity-cert-with-key-grouping" > | |||
<name>The "inline-or-keystore-end-entity-cert-with-key-grouping" Gro uping</name> | <name>The "inline-or-keystore-end-entity-cert-with-key-grouping" Gro uping</name> | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"inline-or-keystore-end-entity-cert-with-key-grouping" grouping: </t> | "inline-or-keystore-end-entity-cert-with-key-grouping" grouping: </t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping inline-or-keystore-end-entity-cert-with-key-grouping: | grouping inline-or-keystore-end-entity-cert-with-key-grouping: | |||
+-- (inline-or-keystore) | +-- (inline-or-keystore) | |||
+--:(inline) {inline-definitions-supported}? | +--:(inline) {inline-definitions-supported}? | |||
| +-- inline-definition | | +-- inline-definition | |||
| +---u ct:asymmetric-key-pair-with-cert-grouping | | +---u ct:asymmetric-key-pair-with-cert-grouping | |||
+--:(central-keystore) | +--:(central-keystore) | |||
{central-keystore-supported,asymmetric-keys}? | {central-keystore-supported,asymmetric-keys}? | |||
+-- central-keystore-reference | +-- central-keystore-reference | |||
+---u central-asymmetric-key-certificate-ref-grouping | +---u central-asymmetric-key-certificate-ref-grouping | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>The "inline-or-keystore-end-entity-cert-with-key-grouping" gro uping is provided | <li>The "inline-or-keystore-end-entity-cert-with-key-grouping" gro uping is provided | |||
solely as convenience to consuming modules that wish to offer | solely as convenience to consuming modules that wish to offer | |||
an option for whether a symmetric key is defined inline | an option for whether a symmetric key is defined inline | |||
or as a reference to a symmetric key in the keystore.</li> | or as a reference to a symmetric key in the keystore.</li> | |||
<li>A "choice" statement is used to expose the various options. | <li>A "choice" statement is used to expose the various options. | |||
Each option is enabled by a "feature" statement. Additional | Each option is enabled by a "feature" statement. Additional | |||
"case" statements MAY be augmented in if, e.g., there is a | "case" statements <bcp14>MAY</bcp14> be augmented in if, e.g., there is a | |||
need to reference a symmetric key in an alternate location.</l i> | need to reference a symmetric key in an alternate location.</l i> | |||
<li>For the "inline-definition" option, the definition uses the | <li>For the "inline-definition" option, the definition uses the | |||
"asymmetric-key-pair-with-certs-grouping" grouping discussed i n <xref section="2.1.4.12" target="I-D.ietf-netconf-crypto-types"/>.</li> | "asymmetric-key-pair-with-certs-grouping" grouping discussed i n <xref target="RFC9640" sectionFormat="of" section="2.1.4.12"/>.</li> | |||
<li>For the "central-keystore" option, the "central-keystore-refer ence" uses the | <li>For the "central-keystore" option, the "central-keystore-refer ence" uses the | |||
"central-asymmetric-key-certificate-ref-grouping" grouping dis cussed in | "central-asymmetric-key-certificate-ref-grouping" grouping dis cussed in | |||
<xref target="central-asymmetric-key-certificate-ref-grouping" />.</li> | <xref target="central-asymmetric-key-certificate-ref-grouping" />.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="keystore-grouping"> | <section anchor="keystore-grouping"> | |||
<name>The "keystore-grouping" Grouping</name> | <name>The "keystore-grouping" Grouping</name> | |||
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he | <t>The following tree diagram <xref target="RFC8340"/> illustrates t he | |||
"keystore-grouping" grouping:</t> | "keystore-grouping" grouping:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
grouping keystore-grouping: | grouping keystore-grouping: | |||
+-- asymmetric-keys {asymmetric-keys}? | +-- asymmetric-keys {asymmetric-keys}? | |||
| +-- asymmetric-key* [name] | | +-- asymmetric-key* [name] | |||
| +-- name? string | | +-- name? string | |||
| +---u ct:asymmetric-key-pair-with-certs-grouping | | +---u ct:asymmetric-key-pair-with-certs-grouping | |||
+-- symmetric-keys {symmetric-keys}? | +-- symmetric-keys {symmetric-keys}? | |||
+-- symmetric-key* [name] | +-- symmetric-key* [name] | |||
+-- name? string | +-- name? string | |||
+---u ct:symmetric-key-grouping | +---u ct:symmetric-key-grouping | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>The "keystore-grouping" grouping defines a keystore instance | <li>The "keystore-grouping" grouping defines a keystore instance | |||
as being composed of symmetric and asymmetric keys. The struc ture | as being composed of symmetric and asymmetric keys. The struc ture | |||
for the symmetric and asymmetric keys is essentially the same, | for the symmetric and asymmetric keys is essentially the same: | |||
being a "list" inside a "container".</li> | a "list" inside a "container".</li> | |||
<li>For asymmetric keys, each "asymmetric-key" uses the | <li>For asymmetric keys, each "asymmetric-key" uses the | |||
"asymmetric-key-pair-with-certs-grouping" grouping discussed i n | "asymmetric-key-pair-with-certs-grouping" grouping discussed i n | |||
<xref section="2.1.4.12" target="I-D.ietf-netconf-crypto-types "/>.</li> | <xref target="RFC9640" sectionFormat="of" section="2.1.4.12"/>.</l i> | |||
<li>For symmetric keys, each "symmetric-key" uses the | <li>For symmetric keys, each "symmetric-key" uses the | |||
"symmetric-key-grouping" grouping discussed in | "symmetric-key-grouping" grouping discussed in | |||
<xref section="2.1.4.3" target="I-D.ietf-netconf-crypto-types" />.</li> | <xref target="RFC9640" sectionFormat="of" section="2.1.4.3"/>. </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="proto-access-nodes" toc="exclude"> | <section anchor="proto-access-nodes" toc="exclude"> | |||
<name>Protocol-accessible Nodes</name> | <name>Protocol-Accessible Nodes</name> | |||
<t>The following tree diagram <xref target="RFC8340"/> lists all the | <t>The following tree diagram <xref target="RFC8340"/> lists all the | |||
protocol-accessible nodes defined in the "ietf-keystore" module, w ithout | protocol-accessible nodes defined in the "ietf-keystore" module wi thout | |||
expanding the "grouping" statements:</t> | expanding the "grouping" statements:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
module: ietf-keystore | module: ietf-keystore | |||
+--rw keystore {central-keystore-supported}? | +--rw keystore {central-keystore-supported}? | |||
+---u keystore-grouping | +---u keystore-grouping | |||
]]></artwork> | ]]></sourcecode> | |||
<t>The following tree diagram <xref target="RFC8340"/> lists all the | <t>The following tree diagram <xref target="RFC8340"/> lists all the | |||
protocol-accessible nodes defined in the "ietf-keystore" module, w ith | protocol-accessible nodes defined in the "ietf-keystore" module, w ith | |||
all "grouping" statements expanded, enabling the keystore's full | all "grouping" statements expanded, enabling the keystore's full | |||
structure to be seen:</t> | structure to be seen:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
module: ietf-keystore | module: ietf-keystore | |||
+--rw keystore {central-keystore-supported}? | +--rw keystore {central-keystore-supported}? | |||
+--rw asymmetric-keys {asymmetric-keys}? | +--rw asymmetric-keys {asymmetric-keys}? | |||
| +--rw asymmetric-key* [name] | | +--rw asymmetric-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 | |||
| +--rw private-key-format? identityref | | +--rw private-key-format? identityref | |||
skipping to change at line 622 ¶ | skipping to change at line 620 ¶ | |||
tric-keys}? | tric-keys}? | |||
| | +--rw symmetric-key-ref? | | | +--rw symmetric-key-ref? | |||
| | ks:central-symmetric-key-ref | | | ks:central-symmetric-key-ref | |||
| +--:(central-asymmetric-key-ref) | | +--:(central-asymmetric-key-ref) | |||
| {central-keystore-supported,asymm\ | | {central-keystore-supported,asymm\ | |||
etric-keys}? | etric-keys}? | |||
| +--rw asymmetric-key-ref? | | +--rw asymmetric-key-ref? | |||
| ks:central-asymmetric-key-ref | | ks:central-asymmetric-key-ref | |||
+--rw encrypted-value-format identityref | +--rw encrypted-value-format identityref | |||
+--rw encrypted-value binary | +--rw encrypted-value binary | |||
]]></artwork> | ]]></sourcecode> | |||
<t>Comments:</t> | <t>Comments:</t> | |||
<ul> | <ul> | |||
<li>Protocol-accessible nodes are those nodes that are accessible | <li>Protocol-accessible nodes are those nodes that are accessible | |||
when the module is "implemented", as described in <xref section= "5.6.5" target="RFC7950"/>.</li> | when the module is "implemented", as described in <xref target=" RFC7950" sectionFormat="of" section="5.6.5"/>.</li> | |||
<li>The protocol-accessible nodes for the "ietf-keystore" module | <li>The protocol-accessible nodes for the "ietf-keystore" module | |||
are instances of the "keystore-grouping" grouping discussed in | are instances of the "keystore-grouping" grouping discussed in | |||
<xref target="keystore-grouping"/>. | <xref target="keystore-grouping"/>. | |||
</li> | </li> | |||
<li>The top-level node "keystore" is additionally constrained | <li>The top-level node "keystore" is additionally constrained | |||
by the feature "central-keystore-supported".</li> | by the feature "central-keystore-supported".</li> | |||
<li>The "keystore-grouping" grouping is discussed in | <li>The "keystore-grouping" grouping is discussed in | |||
<xref target="keystore-grouping"/>.</li> | <xref target="keystore-grouping"/>.</li> | |||
<li>The reason for why "keystore-grouping" exists separate from | <li>The reason for why "keystore-grouping" exists separate from | |||
the protocol-accessible nodes definition is so as to enable | the protocol-accessible nodes definition is to enable | |||
instances of the keystore to be instantiated in other | instances of the keystore 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="examples"> | <section anchor="examples"> | |||
<name>Example Usage</name> | <name>Example Usage</name> | |||
<t>The examples in this section are encoded using XML, such as might | <t>The examples in this section are encoded using XML, such as might | |||
be the case when using the NETCONF protocol. Other encodings MAY | be the case when using the NETCONF protocol. | |||
Other encodings <bcp14>MAY</bcp14> | ||||
be used, such as JSON when using the RESTCONF protocol.</t> | be used, such as JSON when using the RESTCONF protocol.</t> | |||
<section anchor="ks-inst" toc="exclude"> | <section anchor="ks-inst" toc="exclude"> | |||
<name>A Keystore Instance</name> | <name>A Keystore Instance</name> | |||
<t>The following example illustrates keys in <running>. | <t>The following example illustrates keys in <running>. | |||
Please see <xref target="built-ins"/> for an example illustrating | Please see <xref target="built-ins"/> for an example illustrating | |||
built-in values in <operational>.</t> | built-in values in <operational>.</t> | |||
<artwork><![CDATA[ | <sourcecode type="xml"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
<keystore | <keystore | |||
xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | |||
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | |||
<symmetric-keys> | <symmetric-keys> | |||
<symmetric-key> | <symmetric-key> | |||
<name>cleartext-symmetric-key</name> | <name>cleartext-symmetric-key</name> | |||
<key-format>ct:octet-string-key-format</key-format> | <key-format>ct:octet-string-key-format</key-format> | |||
skipping to change at line 767 ¶ | skipping to change at line 767 ¶ | |||
<symmetric-key-ref>encrypted-symmetric-key</symmetric-k\ | <symmetric-key-ref>encrypted-symmetric-key</symmetric-k\ | |||
ey-ref> | ey-ref> | |||
</encrypted-by> | </encrypted-by> | |||
<encrypted-value-format>ct:cms-encrypted-data-format</enc\ | <encrypted-value-format>ct:cms-encrypted-data-format</enc\ | |||
rypted-value-format> | rypted-value-format> | |||
<encrypted-value>BASE64VALUE=</encrypted-value> | <encrypted-value>BASE64VALUE=</encrypted-value> | |||
</encrypted-private-key> | </encrypted-private-key> | |||
</asymmetric-key> | </asymmetric-key> | |||
</asymmetric-keys> | </asymmetric-keys> | |||
</keystore> | </keystore> | |||
]]></sourcecode> | ||||
]]></artwork> | ||||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>A Certificate Expiration Notification</name> | <name>A Certificate Expiration Notification</name> | |||
<t>The following example illustrates a "certificate-expiration" | <t>The following example illustrates a "certificate-expiration" | |||
notification for a certificate associated with an asymmetric | notification for a certificate associated with an asymmetric | |||
key configured in the keystore.</t> | key configured in the keystore.</t> | |||
<artwork><![CDATA[ | <sourcecode type="xml"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
<notification | <notification | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<eventTime>2018-05-25T00:01:00Z</eventTime> | <eventTime>2018-05-25T00:01:00Z</eventTime> | |||
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"> | <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"> | |||
<asymmetric-keys> | <asymmetric-keys> | |||
<asymmetric-key> | <asymmetric-key> | |||
<name>hidden-asymmetric-key</name> | <name>hidden-asymmetric-key</name> | |||
<certificates> | <certificates> | |||
skipping to change at line 798 ¶ | skipping to change at line 797 ¶ | |||
<certificate-expiration> | <certificate-expiration> | |||
<expiration-date>2018-08-05T14:18:53-05:00</expiration\ | <expiration-date>2018-08-05T14:18:53-05:00</expiration\ | |||
-date> | -date> | |||
</certificate-expiration> | </certificate-expiration> | |||
</certificate> | </certificate> | |||
</certificates> | </certificates> | |||
</asymmetric-key> | </asymmetric-key> | |||
</asymmetric-keys> | </asymmetric-keys> | |||
</keystore> | </keystore> | |||
</notification> | </notification> | |||
]]></sourcecode> | ||||
]]></artwork> | ||||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>The "Local or Keystore" Groupings</name> | <name>The "Local or Keystore" Groupings</name> | |||
<t>This section illustrates the various "inline-or-keystore" groupings | <t>This section illustrates the various "inline-or-keystore" groupings | |||
defined in the "ietf-keystore" module, specifically the | defined in the "ietf-keystore" module, specifically the | |||
"inline-or-keystore-symmetric-key-grouping" | "inline-or-keystore-symmetric-key-grouping" | |||
(<xref target="inline-or-keystore-symmetric-key-grouping"/>), | (<xref target="inline-or-keystore-symmetric-key-grouping"/>), | |||
"inline-or-keystore-asymmetric-key-grouping" | "inline-or-keystore-asymmetric-key-grouping" | |||
(<xref target="inline-or-keystore-asymmetric-key-grouping"/>), | (<xref target="inline-or-keystore-asymmetric-key-grouping"/>), | |||
"inline-or-keystore-asymmetric-key-with-certs-grouping" | "inline-or-keystore-asymmetric-key-with-certs-grouping" | |||
(<xref target="inline-or-keystore-asymmetric-key-with-certs-groupi ng"/>), and | (<xref target="inline-or-keystore-asymmetric-key-with-certs-groupi ng"/>), and | |||
"inline-or-keystore-end-entity-cert-with-key-grouping" | "inline-or-keystore-end-entity-cert-with-key-grouping" | |||
(<xref target="inline-or-keystore-end-entity-cert-with-key-groupin g"/>) groupings.</t> | (<xref target="inline-or-keystore-end-entity-cert-with-key-groupin g"/>) groupings.</t> | |||
<t>These examples assume the existence of an example module called "ex -keystore-usage" | <t>These examples assume the existence of an example module called "ex -keystore-usage" | |||
having the namespace "https://example.com/ns/example-keystore-usag e".</t> | that has the namespace "https://example.com/ns/example-keystore-us age".</t> | |||
<t>The ex-keystore-usage module is first presented using tree diagrams | <t>The ex-keystore-usage module is first presented using tree diagrams | |||
<xref target="RFC8340"/>, followed by an instance example illustra ting | <xref target="RFC8340"/>, followed by an instance example illustra ting | |||
all the "inline-or-keystore" groupings in use, followed by the YAN G | all the "inline-or-keystore" groupings in use, followed by the YAN G | |||
module itself.</t> | module itself.</t> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>Tree Diagrams for the "ex-keystore-usage" Module</name> | <name>Tree Diagrams for the "ex-keystore-usage" Module</name> | |||
<t>The following tree diagram illustrates "ex-keystore-usage" withou t | <t>The following tree diagram illustrates "ex-keystore-usage" withou t | |||
expanding the "grouping" statements:</t> | expanding the "grouping" statements:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
module: ex-keystore-usage | module: ex-keystore-usage | |||
+--rw keystore-usage | +--rw keystore-usage | |||
+--rw symmetric-key* [name] | +--rw symmetric-key* [name] | |||
| +--rw name string | | +--rw name string | |||
| +---u ks:inline-or-keystore-symmetric-key-grouping | | +---u ks:inline-or-keystore-symmetric-key-grouping | |||
+--rw asymmetric-key* [name] | +--rw asymmetric-key* [name] | |||
| +--rw name string | | +--rw name string | |||
| +---u ks:inline-or-keystore-asymmetric-key-grouping | | +---u ks:inline-or-keystore-asymmetric-key-grouping | |||
+--rw asymmetric-key-with-certs* [name] | +--rw asymmetric-key-with-certs* [name] | |||
| +--rw name | | +--rw name | |||
| | string | | | string | |||
| +---u ks:inline-or-keystore-asymmetric-key-with-certs-groupi\ | | +---u ks:inline-or-keystore-asymmetric-key-with-certs-groupi\ | |||
ng | ng | |||
+--rw end-entity-cert-with-key* [name] | +--rw end-entity-cert-with-key* [name] | |||
+--rw name | +--rw name | |||
| string | | string | |||
+---u ks:inline-or-keystore-end-entity-cert-with-key-grouping | +---u ks:inline-or-keystore-end-entity-cert-with-key-grouping | |||
]]></artwork> | ]]></sourcecode> | |||
<t>The following tree diagram illustrates the "ex-keystore-usage" | <t>The following tree diagram illustrates the "ex-keystore-usage" | |||
module, with all "grouping" statements expanded, enabling the | module with all "grouping" statements expanded, enabling the | |||
usage's full structure to be seen:</t> | usage's full structure to be seen:</t> | |||
<artwork><![CDATA[ | <sourcecode type="yangtree"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
module: ex-keystore-usage | module: ex-keystore-usage | |||
+--rw keystore-usage | +--rw keystore-usage | |||
+--rw symmetric-key* [name] | +--rw symmetric-key* [name] | |||
| +--rw name string | | +--rw name string | |||
| +--rw (inline-or-keystore) | | +--rw (inline-or-keystore) | |||
| +--:(inline) {inline-definitions-supported}? | | +--:(inline) {inline-definitions-supported}? | |||
| | +--rw inline-definition | | | +--rw inline-definition | |||
| | +--rw key-format? identityref | | | +--rw key-format? identityref | |||
skipping to change at line 980 ¶ | skipping to change at line 978 ¶ | |||
| +--:(p10-csr) | | +--:(p10-csr) | |||
| +--ro p10-csr? p10-csr | | +--ro p10-csr? p10-csr | |||
+--:(central-keystore) | +--:(central-keystore) | |||
{central-keystore-supported,asymmetric-keys}? | {central-keystore-supported,asymmetric-keys}? | |||
+--rw central-keystore-reference | +--rw central-keystore-reference | |||
+--rw asymmetric-key? | +--rw asymmetric-key? | |||
| ks:central-asymmetric-key-ref | | ks:central-asymmetric-key-ref | |||
| {central-keystore-supported,asymmetric-keys\ | | {central-keystore-supported,asymmetric-keys\ | |||
}? | }? | |||
+--rw certificate? leafref | +--rw certificate? leafref | |||
]]></artwork> | ]]></sourcecode> | |||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>Example Usage for the "ex-keystore-usage" Module</name> | <name>Example Usage for the "ex-keystore-usage" Module</name> | |||
<t>The following example provides two equivalent instances of | <t>The following example provides two equivalent instances of | |||
each grouping, the first being a reference to a keystore | each grouping, the first being a reference to a keystore | |||
and the second being inlined. The instance having | and the second being inlined. The instance having | |||
a reference to a keystore is consistent with the keystore | a reference to a keystore is consistent with the keystore | |||
defined in <xref target="ks-inst"/>. The two instances are | defined in <xref target="ks-inst"/>. The two instances are | |||
equivalent, as the inlined instance example contains | equivalent, as the inlined instance example contains | |||
the same values defined by the keystore instance referenced | the same values defined by the keystore instance referenced | |||
by its sibling example.</t> | by its sibling example.</t> | |||
<artwork><![CDATA[ | ||||
<sourcecode type="xml"><![CDATA[ | ||||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
<keystore-usage | <keystore-usage | |||
xmlns="https://example.com/ns/example-keystore-usage" | xmlns="https://example.com/ns/example-keystore-usage" | |||
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | |||
<!-- The following two equivalent examples illustrate the --> | <!-- The following two equivalent examples illustrate the --> | |||
<!-- "inline-or-keystore-symmetric-key-grouping" grouping: --> | <!-- "inline-or-keystore-symmetric-key-grouping" grouping: --> | |||
<symmetric-key> | <symmetric-key> | |||
<name>example 1a</name> | <name>example 1a</name> | |||
<central-keystore-reference>cleartext-symmetric-key</central-key\ | <central-keystore-reference>cleartext-symmetric-key</central-key\ | |||
store-reference> | store-reference> | |||
</symmetric-key> | </symmetric-key> | |||
<symmetric-key> | <symmetric-key> | |||
<name>example 1b</name> | <name>example 1b</name> | |||
<inline-definition> | <inline-definition> | |||
<key-format>ct:octet-string-key-format</key-format> | <key-format>ct:octet-string-key-format</key-format> | |||
<cleartext-symmetric-key>BASE64VALUE=</cleartext-symmetric-key> | <cleartext-symmetric-key>BASE64VALUE=</cleartext-symmetric-key> | |||
</inline-definition> | </inline-definition> | |||
</symmetric-key> | </symmetric-key> | |||
<!-- The following two equivalent examples illustrate the --> | <!-- The following two equivalent examples illustrate the --> | |||
<!-- "inline-or-keystore-asymmetric-key-grouping" grouping: --> | <!-- "inline-or-keystore-asymmetric-key-grouping" grouping: --> | |||
<asymmetric-key> | <asymmetric-key> | |||
<name>example 2a</name> | <name>example 2a</name> | |||
<central-keystore-reference>rsa-asymmetric-key</central-keystore\ | <central-keystore-reference>rsa-asymmetric-key</central-keystore\ | |||
-reference> | -reference> | |||
</asymmetric-key> | </asymmetric-key> | |||
<asymmetric-key> | <asymmetric-key> | |||
<name>example 2b</name> | <name>example 2b</name> | |||
<inline-definition> | <inline-definition> | |||
<public-key-format>ct:subject-public-key-info-format</public-k\ | <public-key-format>ct:subject-public-key-info-format</public-k\ | |||
ey-format> | ey-format> | |||
<public-key>BASE64VALUE=</public-key> | <public-key>BASE64VALUE=</public-key> | |||
<private-key-format>ct:rsa-private-key-format</private-key-for\ | <private-key-format>ct:rsa-private-key-format</private-key-for\ | |||
mat> | mat> | |||
<cleartext-private-key>BASE64VALUE=</cleartext-private-key> | <cleartext-private-key>BASE64VALUE=</cleartext-private-key> | |||
</inline-definition> | </inline-definition> | |||
</asymmetric-key> | </asymmetric-key> | |||
<!-- the following two equivalent examples illustrate --> | <!-- The following two equivalent examples illustrate the --> | |||
<!-- "inline-or-keystore-asymmetric-key-with-certs-grouping": --> | <!-- "inline-or-keystore-asymmetric-key-with-certs-grouping" --> | |||
<!-- grouping: --> | ||||
<asymmetric-key-with-certs> | <asymmetric-key-with-certs> | |||
<name>example 3a</name> | <name>example 3a</name> | |||
<central-keystore-reference>rsa-asymmetric-key</central-keystore\ | <central-keystore-reference>rsa-asymmetric-key</central-keystore\ | |||
-reference> | -reference> | |||
</asymmetric-key-with-certs> | </asymmetric-key-with-certs> | |||
<asymmetric-key-with-certs> | <asymmetric-key-with-certs> | |||
<name>example 3b</name> | <name>example 3b</name> | |||
<inline-definition> | <inline-definition> | |||
<public-key-format>ct:subject-public-key-info-format</public-k\ | <public-key-format>ct:subject-public-key-info-format</public-k\ | |||
ey-format> | ey-format> | |||
<public-key>BASE64VALUE=</public-key> | <public-key>BASE64VALUE=</public-key> | |||
<private-key-format>ct:rsa-private-key-format</private-key-for\ | <private-key-format>ct:rsa-private-key-format</private-key-for\ | |||
mat> | mat> | |||
<cleartext-private-key>BASE64VALUE=</cleartext-private-key> | <cleartext-private-key>BASE64VALUE=</cleartext-private-key> | |||
<certificates> | <certificates> | |||
<certificate> | <certificate> | |||
<name>a locally-defined cert</name> | <name>a locally defined cert</name> | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
</certificates> | </certificates> | |||
</inline-definition> | </inline-definition> | |||
</asymmetric-key-with-certs> | </asymmetric-key-with-certs> | |||
<!-- The following two equivalent examples illustrate --> | <!-- The following two equivalent examples illustrate the --> | |||
<!-- "inline-or-keystore-end-entity-cert-with-key-grouping": --> | <!-- "inline-or-keystore-end-entity-cert-with-key-grouping" --> | |||
<!-- grouping: --> | ||||
<end-entity-cert-with-key> | <end-entity-cert-with-key> | |||
<name>example 4a</name> | <name>example 4a</name> | |||
<central-keystore-reference> | <central-keystore-reference> | |||
<asymmetric-key>rsa-asymmetric-key</asymmetric-key> | <asymmetric-key>rsa-asymmetric-key</asymmetric-key> | |||
<certificate>ex-rsa-cert</certificate> | <certificate>ex-rsa-cert</certificate> | |||
</central-keystore-reference> | </central-keystore-reference> | |||
</end-entity-cert-with-key> | </end-entity-cert-with-key> | |||
<end-entity-cert-with-key> | <end-entity-cert-with-key> | |||
<name>example 4b</name> | <name>example 4b</name> | |||
skipping to change at line 1089 ¶ | skipping to change at line 1090 ¶ | |||
ey-format> | ey-format> | |||
<public-key>BASE64VALUE=</public-key> | <public-key>BASE64VALUE=</public-key> | |||
<private-key-format>ct:rsa-private-key-format</private-key-for\ | <private-key-format>ct:rsa-private-key-format</private-key-for\ | |||
mat> | mat> | |||
<cleartext-private-key>BASE64VALUE=</cleartext-private-key> | <cleartext-private-key>BASE64VALUE=</cleartext-private-key> | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</inline-definition> | </inline-definition> | |||
</end-entity-cert-with-key> | </end-entity-cert-with-key> | |||
</keystore-usage> | </keystore-usage> | |||
]]></artwork> | ]]></sourcecode> | |||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>The "ex-keystore-usage" YANG Module</name> | <name>The "ex-keystore-usage" YANG Module</name> | |||
<!--[rfced] Please see the following warnings from pyang (with the | ||||
ietf option); we think they are OK because this is an example module, | ||||
but please review and let us know if any updates are needed. | ||||
ex-keystore-usage.yang:1: warning: RFC 8407: 4.1: the module name should start w | ||||
ith one of the strings "ietf-" or "iana-" | ||||
ex-keystore-usage.yang:3: warning: RFC 8407: 4.9: namespace value should be "urn | ||||
:ietf:params:xml:ns:yang:ex-keystore-usage" | ||||
ex-keystore-usage.yang:21: warning: RFC 8407: 3.1: The IETF Trust Copyright stat | ||||
ement seems to be missing or is not correct (see pyang -ietf-help for details). | ||||
--> | ||||
<t>Following is the "ex-keystore-usage" module's YANG definition:</t > | <t>Following is the "ex-keystore-usage" module's YANG definition:</t > | |||
<artwork><![CDATA[ | <sourcecode type="yang"><![CDATA[ | |||
module ex-keystore-usage { | module ex-keystore-usage { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "https://example.com/ns/example-keystore-usage"; | namespace "https://example.com/ns/example-keystore-usage"; | |||
prefix ex-keystore-usage; | prefix ex-keystore-usage; | |||
import ietf-keystore { | import ietf-keystore { | |||
prefix ks; | prefix ks; | |||
reference | reference | |||
"RFC CCCC: A YANG Data Model for a Keystore"; | "RFC 9642: A YANG Data Model for a Keystore and Keystore | |||
Operations"; | ||||
} | } | |||
organization | organization | |||
"Example Corporation"; | "Example Corporation"; | |||
contact | contact | |||
"Author: YANG Designer <mailto:yang.designer@example.com>"; | "Author: YANG Designer <mailto:yang.designer@example.com>"; | |||
description | description | |||
"This example module illustrates notable groupings defined | "This example module illustrates notable groupings defined | |||
in the 'ietf-keystore' module."; | in the 'ietf-keystore' module."; | |||
revision 2024-03-16 { | revision 2024-03-16 { | |||
description | description | |||
"Initial version"; | "Initial version"; | |||
reference | reference | |||
"RFC CCCC: A YANG Data Model for a Keystore"; | "RFC 9642: A YANG Data Model for a Keystore and Keystore | |||
Operations"; | ||||
} | } | |||
container keystore-usage { | container keystore-usage { | |||
description | description | |||
"An illustration of the various keystore groupings."; | "An illustration of the various keystore groupings."; | |||
list symmetric-key { | list symmetric-key { | |||
key "name"; | key "name"; | |||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
skipping to change at line 1162 ¶ | skipping to change at line 1174 ¶ | |||
} | } | |||
list asymmetric-key-with-certs { | list asymmetric-key-with-certs { | |||
key "name"; | key "name"; | |||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
"An arbitrary name for this key."; | "An arbitrary name for this key."; | |||
} | } | |||
uses ks:inline-or-keystore-asymmetric-key-with-certs-grouping; | uses ks:inline-or-keystore-asymmetric-key-with-certs-grouping; | |||
description | description | |||
"An asymmetric key and its associated certs, that may be | "An asymmetric key and its associated certs that may be | |||
configured locally or be a reference to an asymmetric key | configured locally or be a reference to an asymmetric | |||
(and its associated certs) in the keystore."; | key (and its associated certs) in the keystore."; | |||
} | } | |||
list end-entity-cert-with-key { | list end-entity-cert-with-key { | |||
key "name"; | key "name"; | |||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
"An arbitrary name for this key."; | "An arbitrary name for this key."; | |||
} | } | |||
uses ks:inline-or-keystore-end-entity-cert-with-key-grouping; | uses ks:inline-or-keystore-end-entity-cert-with-key-grouping; | |||
description | description | |||
"An end-entity certificate and its associated asymmetric | "An end-entity certificate and its associated asymmetric | |||
key, that may be configured locally or be a reference | key that may be configured locally or be a reference | |||
to another certificate (and its associated asymmetric | to another certificate (and its associated asymmetric | |||
key) in the keystore."; | key) in the keystore."; | |||
} | } | |||
} | } | |||
} | } | |||
]]></artwork> | ]]></sourcecode> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="keystore-yang-module"> | <section anchor="keystore-yang-module"> | |||
<name>YANG Module</name> | <name>YANG Module</name> | |||
<t>This YANG module has normative references to <xref target="RFC8341"/> | <t>This YANG module has normative references to <xref target="RFC8341"/> | |||
and <xref target="I-D.ietf-netconf-crypto-types"/>.</t> | and <xref target="RFC9640"/>.</t> | |||
<t keepWithNext="true"><CODE BEGINS> file "ietf-keystore@2024-03-1 | <!-- <t keepWithNext="true"><CODE BEGINS> file "ietf-keystore@2024-03 | |||
6.yang"</t> | -16.yang"</t>--> | |||
<artwork><![CDATA[ | ||||
<!--[rfced] Section 2.3. This is the only description that contains | ||||
"asymmetric-key" (hyphenated). Should the hyphen be removed for | ||||
consistency, or is this instance different than the others? | ||||
Original: | ||||
description | ||||
"A reference to an asymmetric-key (and all of its | ||||
associated certificates) in the keystore, when | ||||
this module is implemented."; | ||||
Perhaps: | ||||
description | ||||
"A reference to an asymmetric key (and all of its | ||||
associated certificates) in the keystore, when | ||||
this module is implemented."; | ||||
--> | ||||
<!-- [rfced] Note that we made one minor update to the YANG module | ||||
ietf-keystore to match the formatted output of pyang. | ||||
--> | ||||
<sourcecode type="yang" name="ietf-keystore@2024-03-16.yang" markers="tr | ||||
ue"><![CDATA[ | ||||
module ietf-keystore { | module ietf-keystore { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; | namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; | |||
prefix ks; | prefix ks; | |||
import ietf-netconf-acm { | import ietf-netconf-acm { | |||
prefix nacm; | prefix nacm; | |||
reference | reference | |||
"RFC 8341: Network Configuration Access Control Model"; | "RFC 8341: Network Configuration Access Control Model"; | |||
} | } | |||
import ietf-crypto-types { | import ietf-crypto-types { | |||
prefix ct; | prefix ct; | |||
reference | reference | |||
"RFC AAAA: YANG Data Types and Groupings for Cryptography"; | "RFC 9640: YANG Data Types and Groupings for Cryptography"; | |||
} | } | |||
organization | organization | |||
"IETF NETCONF (Network Configuration) Working Group"; | "IETF NETCONF (Network Configuration) Working Group"; | |||
contact | contact | |||
"WG Web: https://datatracker.ietf.org/wg/netconf | "WG Web: https://datatracker.ietf.org/wg/netconf | |||
WG List: NETCONF WG list <mailto:netconf@ietf.org> | WG List: NETCONF WG list <mailto:netconf@ietf.org> | |||
Author: Kent Watsen <mailto:kent+ietf@watsen.net>"; | Author: Kent Watsen <mailto:kent+ietf@watsen.net>"; | |||
description | description | |||
"This module defines a 'keystore' to centralize management | "This module defines a 'keystore' to centralize management | |||
of security credentials. | of security credentials. | |||
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 CCCC | This version of this YANG module is part of RFC 9642 | |||
(https://www.rfc-editor.org/info/rfcCCCC); see the RFC | (https://www.rfc-editor.org/info/rfc9642); see the RFC | |||
itself for full legal notices. | itself for full legal notices."; | |||
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', | ||||
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', | ||||
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document | ||||
are to be interpreted as described in BCP 14 (RFC 2119) | ||||
(RFC 8174) when, and only when, they appear in all | ||||
capitals, as shown here."; | ||||
revision 2024-03-16 { | revision 2024-03-16 { | |||
description | description | |||
"Initial version"; | "Initial version"; | |||
reference | reference | |||
"RFC CCCC: A YANG Data Model for a Keystore"; | "RFC 9642: A YANG Data Model for a Keystore and Keystore | |||
Operations"; | ||||
} | } | |||
/****************/ | /****************/ | |||
/* Features */ | /* Features */ | |||
/****************/ | /****************/ | |||
feature central-keystore-supported { | feature central-keystore-supported { | |||
description | description | |||
"The 'central-keystore-supported' feature indicates that | "The 'central-keystore-supported' feature indicates that | |||
the server supports the central keystore (i.e., fully | the server supports the central keystore (i.e., fully | |||
implements the 'ietf-keystore' module)."; | implements the 'ietf-keystore' 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 keys."; | the server supports locally defined keys."; | |||
} | } | |||
feature asymmetric-keys { | feature asymmetric-keys { | |||
description | description | |||
"The 'asymmetric-keys' feature indicates that the server | "The 'asymmetric-keys' feature indicates that the server | |||
implements the /keystore/asymmetric-keys subtree."; | implements the /keystore/asymmetric-keys subtree."; | |||
} | } | |||
feature symmetric-keys { | feature symmetric-keys { | |||
skipping to change at line 1312 ¶ | skipping to change at line 1347 ¶ | |||
/*****************/ | /*****************/ | |||
/* Groupings */ | /* Groupings */ | |||
/*****************/ | /*****************/ | |||
grouping encrypted-by-grouping { | grouping encrypted-by-grouping { | |||
description | description | |||
"A grouping that defines a 'choice' statement that can be | "A grouping that defines a 'choice' statement that can be | |||
augmented into the 'encrypted-by' node, present in the | augmented into the 'encrypted-by' node, present in the | |||
'symmetric-key-grouping' and 'asymmetric-key-pair-grouping' | 'symmetric-key-grouping' and 'asymmetric-key-pair-grouping' | |||
groupings defined in RFC AAAA, enabling references to keys | groupings defined in RFC 9640, enabling references to keys | |||
in the central keystore."; | in the central keystore."; | |||
choice encrypted-by { | choice encrypted-by { | |||
nacm:default-deny-write; | nacm:default-deny-write; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"A choice amongst other symmetric or asymmetric keys."; | "A choice amongst other symmetric or asymmetric keys."; | |||
case central-symmetric-key-ref { | case central-symmetric-key-ref { | |||
if-feature "central-keystore-supported"; | if-feature "central-keystore-supported"; | |||
if-feature "symmetric-keys"; | if-feature "symmetric-keys"; | |||
leaf symmetric-key-ref { | leaf symmetric-key-ref { | |||
skipping to change at line 1346 ¶ | skipping to change at line 1381 ¶ | |||
encrypted the associated key."; | encrypted the associated key."; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
// *-ref groupings | // *-ref groupings | |||
grouping central-asymmetric-key-certificate-ref-grouping { | grouping central-asymmetric-key-certificate-ref-grouping { | |||
description | description | |||
"Grouping for the reference to a certificate associated | "A grouping for the reference to a certificate associated | |||
with an asymmetric key stored in the central keystore."; | with an asymmetric key stored in the central keystore."; | |||
leaf asymmetric-key { | leaf asymmetric-key { | |||
nacm:default-deny-write; | nacm:default-deny-write; | |||
if-feature "central-keystore-supported"; | if-feature "central-keystore-supported"; | |||
if-feature "asymmetric-keys"; | if-feature "asymmetric-keys"; | |||
type ks:central-asymmetric-key-ref; | type ks:central-asymmetric-key-ref; | |||
must '../certificate'; | must '../certificate'; | |||
description | description | |||
"A reference to an asymmetric key in the keystore."; | "A reference to an asymmetric key in the keystore."; | |||
} | } | |||
skipping to change at line 1392 ¶ | skipping to change at line 1427 ¶ | |||
choice inline-or-keystore { | choice inline-or-keystore { | |||
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 keystore."; | that exists in the keystore."; | |||
case inline { | case inline { | |||
if-feature "inline-definitions-supported"; | if-feature "inline-definitions-supported"; | |||
container inline-definition { | container inline-definition { | |||
description | description | |||
"Container to hold the local key definition."; | "A container to hold the local key definition."; | |||
uses ct:symmetric-key-grouping; | uses ct:symmetric-key-grouping; | |||
} | } | |||
} | } | |||
case central-keystore { | case central-keystore { | |||
if-feature "central-keystore-supported"; | if-feature "central-keystore-supported"; | |||
if-feature "symmetric-keys"; | if-feature "symmetric-keys"; | |||
leaf central-keystore-reference { | leaf central-keystore-reference { | |||
type ks:central-symmetric-key-ref; | type ks:central-symmetric-key-ref; | |||
description | description | |||
"A reference to an symmetric key that exists in | "A reference to a symmetric key that exists in | |||
the central keystore."; | the central keystore."; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
grouping inline-or-keystore-asymmetric-key-grouping { | grouping inline-or-keystore-asymmetric-key-grouping { | |||
description | description | |||
"A grouping for the configuration of an asymmetric key. The | "A grouping for the configuration of an asymmetric key. The | |||
asymmetric key may be defined inline or as a reference to | asymmetric key may be defined inline or as a reference to | |||
an asymmetric key stored in the central keystore. | an asymmetric key stored in the central keystore. | |||
Servers that wish to define alternate keystore locations | Servers that wish to define alternate keystore locations | |||
SHOULD augment in custom 'case' statements enabling | SHOULD augment in custom 'case' statements enabling | |||
references to those alternate keystore locations."; | references to those alternate keystore locations."; | |||
choice inline-or-keystore { | choice inline-or-keystore { | |||
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 keystore."; | that exists in the keystore."; | |||
case inline { | case inline { | |||
if-feature "inline-definitions-supported"; | if-feature "inline-definitions-supported"; | |||
container inline-definition { | container inline-definition { | |||
description | description | |||
"Container to hold the local key definition."; | "A container to hold the local key definition."; | |||
uses ct:asymmetric-key-pair-grouping; | uses ct:asymmetric-key-pair-grouping; | |||
} | } | |||
} | } | |||
case central-keystore { | case central-keystore { | |||
if-feature "central-keystore-supported"; | if-feature "central-keystore-supported"; | |||
if-feature "asymmetric-keys"; | if-feature "asymmetric-keys"; | |||
leaf central-keystore-reference { | leaf central-keystore-reference { | |||
type ks:central-asymmetric-key-ref; | type ks:central-asymmetric-key-ref; | |||
description | description | |||
"A reference to an asymmetric key that exists in | "A reference to an asymmetric key that exists in | |||
skipping to change at line 1468 ¶ | skipping to change at line 1503 ¶ | |||
choice inline-or-keystore { | choice inline-or-keystore { | |||
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 keystore."; | that exists in the keystore."; | |||
case inline { | case inline { | |||
if-feature "inline-definitions-supported"; | if-feature "inline-definitions-supported"; | |||
container inline-definition { | container inline-definition { | |||
description | description | |||
"Container to hold the local key definition."; | "A container to hold the local key definition."; | |||
uses ct:asymmetric-key-pair-with-certs-grouping; | uses ct:asymmetric-key-pair-with-certs-grouping; | |||
} | } | |||
} | } | |||
case central-keystore { | case central-keystore { | |||
if-feature "central-keystore-supported"; | if-feature "central-keystore-supported"; | |||
if-feature "asymmetric-keys"; | if-feature "asymmetric-keys"; | |||
leaf central-keystore-reference { | leaf central-keystore-reference { | |||
type ks:central-asymmetric-key-ref; | type ks:central-asymmetric-key-ref; | |||
description | description | |||
"A reference to an asymmetric-key (and all of its | "A reference to an asymmetric-key (and all of its | |||
skipping to change at line 1507 ¶ | skipping to change at line 1542 ¶ | |||
choice inline-or-keystore { | choice inline-or-keystore { | |||
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 keystore."; | that exists in the keystore."; | |||
case inline { | case inline { | |||
if-feature "inline-definitions-supported"; | if-feature "inline-definitions-supported"; | |||
container inline-definition { | container inline-definition { | |||
description | description | |||
"Container to hold the local key definition."; | "A container to hold the local key definition."; | |||
uses ct:asymmetric-key-pair-with-cert-grouping; | uses ct:asymmetric-key-pair-with-cert-grouping; | |||
} | } | |||
} | } | |||
case central-keystore { | case central-keystore { | |||
if-feature "central-keystore-supported"; | if-feature "central-keystore-supported"; | |||
if-feature "asymmetric-keys"; | if-feature "asymmetric-keys"; | |||
container central-keystore-reference { | container central-keystore-reference { | |||
uses central-asymmetric-key-certificate-ref-grouping; | uses central-asymmetric-key-certificate-ref-grouping; | |||
description | description | |||
"A reference to a specific certificate associated with | "A reference to a specific certificate associated with | |||
an asymmetric key stored in the central keystore."; | an asymmetric key stored in the central keystore."; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
// the keystore grouping | // the keystore grouping | |||
grouping keystore-grouping { | grouping keystore-grouping { | |||
description | description | |||
"Grouping definition enables use in other contexts. If ever | "A grouping definition enables use in other contexts. If ever | |||
done, implementations MUST augment new 'case' statements | done, implementations MUST augment new 'case' statements | |||
into the various inline-or-keystore 'choice' statements to | into the various inline-or-keystore 'choice' statements to | |||
supply leafrefs to the model-specific location(s)."; | supply leafrefs to the model-specific location(s)."; | |||
container asymmetric-keys { | container asymmetric-keys { | |||
nacm:default-deny-write; | nacm:default-deny-write; | |||
if-feature "asymmetric-keys"; | if-feature "asymmetric-keys"; | |||
description | description | |||
"A list of asymmetric keys."; | "A list of asymmetric keys."; | |||
list asymmetric-key { | list asymmetric-key { | |||
key "name"; | key "name"; | |||
skipping to change at line 1573 ¶ | skipping to change at line 1608 ¶ | |||
uses ct:symmetric-key-grouping; | uses ct:symmetric-key-grouping; | |||
} | } | |||
} | } | |||
} | } | |||
/*********************************/ | /*********************************/ | |||
/* Protocol accessible nodes */ | /* Protocol accessible nodes */ | |||
/*********************************/ | /*********************************/ | |||
container keystore { | container keystore { | |||
if-feature central-keystore-supported; | if-feature "central-keystore-supported"; | |||
description | description | |||
"A central keystore containing a list of symmetric keys and | "A central keystore containing a list of symmetric keys and | |||
a list of asymmetric keys."; | a list of asymmetric keys."; | |||
nacm:default-deny-write; | nacm:default-deny-write; | |||
uses keystore-grouping { | uses keystore-grouping { | |||
augment "symmetric-keys/symmetric-key/key-type/encrypted-" | augment "symmetric-keys/symmetric-key/key-type/encrypted-" | |||
+ "symmetric-key/encrypted-symmetric-key/encrypted-by" { | + "symmetric-key/encrypted-symmetric-key/encrypted-by" { | |||
description | description | |||
"Augments in a choice statement enabling the encrypting | "Augments in a choice statement enabling the encrypting | |||
key to be any other symmetric or asymmetric key in the | key to be any other symmetric or asymmetric key in the | |||
skipping to change at line 1599 ¶ | skipping to change at line 1634 ¶ | |||
+ "encrypted-by" { | + "encrypted-by" { | |||
description | description | |||
"Augments in a choice statement enabling the encrypting | "Augments in a choice statement enabling the encrypting | |||
key to be any other symmetric or asymmetric key in the | key to be any other symmetric or asymmetric key in the | |||
central keystore."; | central keystore."; | |||
uses encrypted-by-grouping; | uses encrypted-by-grouping; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
]]></artwork> | ]]></sourcecode> | |||
<t keepWithPrevious="true"><CODE ENDS></t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="built-ins"> | <section anchor="built-ins"> | |||
<name>Support for Built-in Keys</name> | <name>Support for Built-In Keys</name> | |||
<t>In some implementations, a server may support keys built into the serve r. | <t>In some implementations, a server may support keys built into the serve r. | |||
Built-in keys MAY be set during the manufacturing process or be dynami cally | Built-in keys <bcp14>MAY</bcp14> be set during the manufacturing proce ss or be dynamically | |||
generated the first time the server is booted or a particular service | generated the first time the server is booted or a particular service | |||
(e.g., SSH) is enabled.</t> | (e.g., Secure Shell (SSH)) is enabled.</t> | |||
<t>Built-in keys are "hidden" keys expected to be set by a vendor-specific process. | <t>Built-in keys are "hidden" keys expected to be set by a vendor-specific process. | |||
Any ability for operators to set and/or modify built-in keys is outsid e the | Any ability for operators to set and/or modify built-in keys is outsid e the | |||
scope of this document.</t> | scope of this document.</t> | |||
<!--[rfced] Would it be correct to update "as opposed to configuration" | ||||
to "as opposed to being configured" in the following | ||||
sentence? | ||||
Original: | ||||
The primary characteristic of the built-in keys is that they are | ||||
provided by the server, as opposed to configuration. | ||||
Perhaps: | ||||
The primary characteristic of the built-in keys is that they are | ||||
provided by the server, as opposed to being configured. | ||||
--> | ||||
<t>The primary characteristic of the built-in keys is that they are provid ed | <t>The primary characteristic of the built-in keys is that they are provid ed | |||
by the server, as opposed to configuration. As such, they are present in | by the server, as opposed to configuration. As such, they are present in | |||
<operational> (<xref section="5.3" target="RFC8342"/>), and < system> | <operational> (<xref target="RFC8342" sectionFormat="of" section ="5.3"/>) and <system> | |||
<xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t> | <xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t> | |||
<t>The example below illustrates what the keystore in <operational> | <t>The example below illustrates what the keystore in <operational> | |||
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 keys have the "or:origin" annotation value "or:system".</t> | built-in keys have the "or:origin" annotation value "or:system".</t> | |||
<artwork><![CDATA[ | <sourcecode type="xml"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | |||
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"> | |||
<asymmetric-keys> | <asymmetric-keys> | |||
<asymmetric-key or:origin="or:system"> | <asymmetric-key or:origin="or:system"> | |||
<name>Manufacturer-Generated Hidden Key</name> | <name>Manufacturer-Generated Hidden Key</name> | |||
<public-key-format>ct:subject-public-key-info-format</public-k\ | <public-key-format>ct:subject-public-key-info-format</public-k\ | |||
skipping to change at line 1642 ¶ | skipping to change at line 1690 ¶ | |||
<hidden-private-key/> | <hidden-private-key/> | |||
<certificates> | <certificates> | |||
<certificate> | <certificate> | |||
<name>Manufacturer-Generated IDevID Cert</name> | <name>Manufacturer-Generated IDevID Cert</name> | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
</certificates> | </certificates> | |||
</asymmetric-key> | </asymmetric-key> | |||
</asymmetric-keys> | </asymmetric-keys> | |||
</keystore> | </keystore> | |||
]]></artwork> | ]]></sourcecode> | |||
<t>The following example illustrates how a single built-in key definition | <t>The following example illustrates how a single built-in key definition | |||
from the previous example has been propagated to <running>:</t> | from the previous example has been propagated to <running>:</t> | |||
<artwork><![CDATA[ | <sourcecode type="xml"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | |||
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> | |||
<asymmetric-keys> | <asymmetric-keys> | |||
<asymmetric-key> | <asymmetric-key> | |||
<name>Manufacturer-Generated Hidden Key</name> | <name>Manufacturer-Generated Hidden Key</name> | |||
<public-key-format>ct:subject-public-key-info-format</public-k\ | <public-key-format>ct:subject-public-key-info-format</public-k\ | |||
ey-format> | ey-format> | |||
<public-key>BASE64VALUE=</public-key> | <public-key>BASE64VALUE=</public-key> | |||
skipping to change at line 1670 ¶ | skipping to change at line 1718 ¶ | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
<certificate> | <certificate> | |||
<name>Deployment-Specific LDevID Cert</name> | <name>Deployment-Specific LDevID Cert</name> | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
</certificates> | </certificates> | |||
</asymmetric-key> | </asymmetric-key> | |||
</asymmetric-keys> | </asymmetric-keys> | |||
</keystore> | </keystore> | |||
]]></artwork> | ]]></sourcecode> | |||
<t>After the above configuration is applied, <operational> should ap pear | <t>After the above configuration is applied, <operational> should ap pear | |||
as follows:</t> | as follows:</t> | |||
<artwork><![CDATA[ | <sourcecode type="xml"><![CDATA[ | |||
=============== NOTE: '\' line wrapping per RFC 8792 ================ | =============== NOTE: '\' line wrapping per RFC 8792 ================ | |||
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore" | |||
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"> | |||
<asymmetric-keys> | <asymmetric-keys> | |||
<asymmetric-key or:origin="or:system"> | <asymmetric-key or:origin="or:system"> | |||
<name>Manufacturer-Generated Hidden Key</name> | <name>Manufacturer-Generated Hidden Key</name> | |||
<public-key-format>ct:subject-public-key-info-format</public-k\ | <public-key-format>ct:subject-public-key-info-format</public-k\ | |||
skipping to change at line 1700 ¶ | skipping to change at line 1748 ¶ | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
<certificate or:origin="or:intended"> | <certificate or:origin="or:intended"> | |||
<name>Deployment-Specific LDevID Cert</name> | <name>Deployment-Specific LDevID Cert</name> | |||
<cert-data>BASE64VALUE=</cert-data> | <cert-data>BASE64VALUE=</cert-data> | |||
</certificate> | </certificate> | |||
</certificates> | </certificates> | |||
</asymmetric-key> | </asymmetric-key> | |||
</asymmetric-keys> | </asymmetric-keys> | |||
</keystore> | </keystore> | |||
]]></artwork> | ]]></sourcecode> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Encrypting Keys in Configuration</name> | <name>Encrypting Keys in Configuration</name> | |||
<t>This section describes an approach that enables both the symmetric | <t>This section describes an approach that enables both the symmetric | |||
and asymmetric keys on a server to be encrypted, such that traditional | and asymmetric keys on a server to be encrypted, such that traditional | |||
backup/restore procedures can be used without concern for raw key | backup/restore procedures can be used without concern for raw key | |||
data being compromised when in transit.</t> | data being compromised when in transit.</t> | |||
<t>The approach presented in this section is not normative. This section | <t>The approach presented in this section is not normative. This section | |||
answers how a configuration containing secrets that are encrypted by a | answers how a configuration containing secrets that are encrypted by a | |||
built-in key (<xref target="built-ins"/>) can be backup'ed from one se | built-in key (<xref target="built-ins"/>) can be backed up from one se | |||
rver | rver | |||
and restored on a different server, when each server has unique master | and restored on a different server when each server has unique master | |||
keys. | keys. | |||
The API defined by the "ietf-keystore" YANG module presented in this | The API defined by the "ietf-keystore" YANG module presented in this | |||
document is sufficient to support the workflow described in this secti on.</t> | document is sufficient to support the workflow described in this secti on.</t> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>Key Encryption Key</name> | <name>Key Encryption Key</name> | |||
<t>The ability to encrypt configured keys is predicated on the | <t>The ability to encrypt configured keys is predicated on the | |||
existence of a "key encryption key" (KEK). There may be any | existence of a key encryption key (KEK). There may be any | |||
number of KEKs in a server. A KEK, by its namesake, is a key | number of KEKs in a server. A KEK, by its namesake, is a key | |||
that is used to encrypt other keys. A KEK MAY be either a | that is used to encrypt other keys. A KEK <bcp14>MAY</bcp14> be eith er a | |||
symmetric key or an asymmetric key.</t> | symmetric key or an asymmetric key.</t> | |||
<t>If a KEK is a symmetric key, then the server MUST provide an API for | <t>If a KEK is a symmetric key, then the server <bcp14>MUST</bcp14> prov ide an API for | |||
administrators to encrypt other keys without needing to know | administrators to encrypt other keys without needing to know | |||
the symmetric key's value. If the KEK is an asymmetric key, then | the symmetric key's value. If the KEK is an asymmetric key, then | |||
the server SHOULD provide an API enabling the encryption of other | the server <bcp14>SHOULD</bcp14> provide an API enabling the encrypt ion of other | |||
keys or, alternatively, assume the administrators can do so themselv es | keys or, alternatively, assume the administrators can do so themselv es | |||
using the asymmetric key's public half.</t> | using the asymmetric key's public half.</t> | |||
<t>A server MUST possess access to the KEK, or an API using the KEK, | <t>A server <bcp14>MUST</bcp14> possess access to the KEK, or an API usi ng the KEK, | |||
so that it can decrypt the other keys in the configuration at runtim e.</t> | so that it can decrypt the other keys in the configuration at runtim e.</t> | |||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>Configuring Encrypted Keys</name> | <name>Configuring Encrypted Keys</name> | |||
<t>Each time a new key is configured, it SHOULD be encrypted by | <t>Each time a new key is configured, it <bcp14>SHOULD</bcp14> be encryp | |||
a KEK.</t> | ted by | |||
<t>In "ietf-crypto-types" <xref target="I-D.ietf-netconf-crypto-types"/> | a KEK.</t> | |||
, | ||||
<!--[rfced] Should "ietf-crypto-types" be referred to as "the | ||||
"ietf-crypto-types" module" in the following text? | ||||
Original: | ||||
In "ietf-crypto-types" [I-D.ietf-netconf-crypto-types], the format for | ||||
encrypted values is described by identity statements derived from the | ||||
"symmetrically-encrypted-value-format" and | ||||
"asymmetrically-encrypted-value-format" identity statements. | ||||
Perhaps: | ||||
In the "ietf-crypto-types" module [RFC 9640], the format for | ||||
encrypted values is described by identity statements derived from the | ||||
"symmetrically-encrypted-value-format" and | ||||
"asymmetrically-encrypted-value-format" identity statements. | ||||
--> | ||||
<t>In "ietf-crypto-types" <xref target="RFC9640"/>, | ||||
the format for encrypted values is described by identity statements | the format for encrypted values is described by identity statements | |||
derived from the "symmetrically-encrypted-value-format" and | derived from the "symmetrically-encrypted-value-format" and | |||
"asymmetrically-encrypted-value-format" identity statements.</t> | "asymmetrically-encrypted-value-format" identity statements.</t> | |||
<t>Implementations of servers implementing the "ietf-keystore" module | <t>Implementations of servers implementing the "ietf-keystore" module | |||
SHOULD provide an API that simultaneously generates a key and encryp | <bcp14>SHOULD</bcp14> provide an API that simultaneously generates a | |||
ts | key and encrypts | |||
the generated key using a KEK. Thus the cleartext value of the newl | the generated key using a KEK. Thus, the cleartext value of the new | |||
y | ly | |||
generated key may never be known to the administrators generating th e keys. | generated key may never be known to the administrators generating th e keys. | |||
Such API is defined in the "ietf-ssh-common" and the "ietf-tls-commo | Such an API is defined in the "ietf-ssh-common" and "ietf-tls-common | |||
n" | " | |||
YANG modules defined in <xref target="I-D.ietf-netconf-ssh-client-se | YANG modules defined in <xref target="RFC9644"/> | |||
rver"/>, | and <xref target="RFC9645"/>, respectively.</t> | |||
and <xref target="I-D.ietf-netconf-tls-client-server"/>, respectivel | ||||
y.</t> | ||||
<t>In case the server implementation does not provide such an API, then | <t>In case the server implementation does not provide such an API, then | |||
the generating and encrypting steps MAY be performed outside the | the generating and encrypting steps <bcp14>MAY</bcp14> be performed | |||
server, e.g., by an administrator with special access control rights | outside the | |||
(e.g., an organization's crypto officer).</t> | server, e.g., by an administrator with special access control rights | |||
(such as an organization's crypto officer).</t> | ||||
<t>In either case, the encrypted key can be configured into the keystore | <t>In either case, the encrypted key can be configured into the keystore | |||
using either the "encrypted-symmetric-key" (for symmetric keys) or t he | using either the "encrypted-symmetric-key" (for symmetric keys) or t he | |||
"encrypted-private-key" (for asymmetric keys) nodes. These two node s | "encrypted-private-key" (for asymmetric keys) nodes. These two node s | |||
contain both the encrypted raw key value as well as a reference to | contain both the encrypted raw key value as well as a reference to | |||
the KEK that encrypted the key.</t> | the KEK that encrypted the key.</t> | |||
</section> | </section> | |||
<section toc="exclude"> | <section toc="exclude"> | |||
<name>Migrating Configuration to Another Server</name> | <name>Migrating Configuration to Another Server</name> | |||
<t>When a KEK is used to encrypt other keys, migrating the configuration | <t>When a KEK is used to encrypt other keys, migrating the configuration | |||
to another server is only possible if the second server has the same KEK. | to another server is only possible if the second server has the same KEK. | |||
How the second server comes to have the same KEK is discussed in thi s | How the second server comes to have the same KEK is discussed in thi s | |||
section.</t> | section.</t> | |||
<t>In some deployments, mechanisms outside the scope of this document | <t>In some deployments, mechanisms outside the scope of this document | |||
may be used to migrate a KEK from one server to another. That said, | may be used to migrate a KEK from one server to another. That said, | |||
beware that the ability to do so typically entails having access to | beware that the ability to do so typically entails having access to | |||
the first server but, in some scenarios, the first server may no | the first server; however, in some scenarios, the first server may n o | |||
longer be operational.</t> | longer be operational.</t> | |||
<t>In other deployments, an organization's crypto officer, possessing a | <t>In other deployments, an organization's crypto officer, possessing a | |||
KEK's cleartext value, configures the same KEK on the second server, | KEK's cleartext value, configures the same KEK on the second server, | |||
presumably as a hidden key or a key protected by access-control, so | presumably as a hidden key or a key protected by access control, so | |||
that the cleartext value is not | that the cleartext value is not | |||
disclosed to regular administrators. However, this approach creates | disclosed to regular administrators. However, this approach creates | |||
high-coupling to and dependency on the crypto officers that does not | high coupling to and dependency on the crypto officers that does not | |||
scale in production environments.</t> | scale in production environments.</t> | |||
<t>In order to decouple the crypto officers from the regular administrat ors, | <t>In order to decouple the crypto officers from the regular administrat ors, | |||
a special KEK, called the "master key" (MK), may be used.</t> | a special KEK, called the "master key" (MK), may be used.</t> | |||
<t>A MK is commonly a globally-unique built-in (see <xref target="built- ins"/>) | <t>An MK is commonly a globally unique built-in (see <xref target="built -ins"/>) | |||
asymmetric key. The private raw key value, due to its long lifetime, is hidden | asymmetric key. The private raw key value, due to its long lifetime, is hidden | |||
(i.e., "hidden-private-key" in <xref section="2.1.4.5." target="I-D. ietf-netconf-crypto-types"/>). The raw public key value is often | (i.e., "hidden-private-key"; see <xref target="RFC9640" sectionForma t="of" section="2.1.4.5."/>). The raw public key value is often | |||
contained in an identity certificate (e.g., IDevID). How to | contained in an identity certificate (e.g., IDevID). How to | |||
configure a MK during the manufacturing process is outside the | configure an MK during the manufacturing process is outside the | |||
scope of this document.</t> | scope of this document.</t> | |||
<t>Assuming the server has a MK, the MK can be used to encrypt a | <t>Assuming the server has an MK, the MK can be used to encrypt a | |||
"shared KEK", which is then used to encrypt the keys configured | "shared KEK", which is then used to encrypt the keys configured | |||
by regular administrators.</t> | by regular administrators.</t> | |||
<t>With this extra level of indirection, it is possible for a | <t>With this extra level of indirection, it is possible for a | |||
crypto officer to encrypt the same KEK for a multiplicity of | crypto officer to encrypt the same KEK for a multiplicity of | |||
servers offline using the public key contained in their identity | servers offline using the public key contained in their identity | |||
certificates. The crypto officer can then safely handoff | certificates. The crypto officer can then safely hand off | |||
the encrypted KEKs to regular administrators responsible for | the encrypted KEKs to regular administrators responsible for | |||
server installations, including migrations.</t> | server installations, including migrations.</t> | |||
<t>In order to migrate the configuration from a first server, an | <t>In order to migrate the configuration from a first server, an | |||
administrator would need to make just a single modification to | administrator would need to make just a single modification to | |||
the configuration before loading it onto a second server, which | the configuration before loading it onto a second server, which | |||
is to replace the encrypted KEK keystore entry from the first | is to replace the encrypted KEK keystore entry from the first | |||
server with the encrypted KEK for the second server. Upon doing | server with the encrypted KEK for the second server. Upon doing | |||
this, the configuration (containing many encrypted keys) can be | this, the configuration (containing many encrypted keys) can be | |||
loaded into the second server while enabling the second server | loaded into the second server while enabling the second server | |||
to decrypt all the encrypted keys in the configuration.</t> | to decrypt all the encrypted keys in the configuration.</t> | |||
skipping to change at line 1857 ¶ | skipping to change at line 1921 ¶ | |||
]]></artwork> | ]]></artwork> | |||
</section> | </section> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<section> | <section> | |||
<name>Security of Data at Rest and in Motion</name> | <name>Security of Data at Rest and in Motion</name> | |||
<t>The YANG module defined in this document defines a mechanism called a | <t>The YANG module defined in this document defines a mechanism called a | |||
"keystore" that intends to protect its contents from unauthorized | "keystore" that intends to protect its contents from unauthorized | |||
disclosure and modification.</t> | disclosure and modification.</t> | |||
<t>In order to satisfy the expectations of a "keystore", it | <t>In order to satisfy the expectations of a keystore, it | |||
is RECOMMENDED that server implementations ensure that the keystore | is <bcp14>RECOMMENDED</bcp14> that server implementations ensure tha | |||
contents are encrypted when persisted to non-volatile memory, | t the keystore | |||
and ensure that the keystore contents that have been decrypted | contents are encrypted when persisted to non-volatile memory | |||
in volatile memory are zeroized when not in use.</t> | and that the keystore contents that have been decrypted | |||
<t>The keystore contents may be encrypted either by encrypting | in volatile memory are zeroized when not in use.</t> | |||
<!--[rfced] In order to make this "either" sentence parallel, we | ||||
updated the text as shown below. Please let us know of any | ||||
objections. | ||||
Original: | ||||
The keystore contents may be encrypted either by encrypting the | ||||
contents individually (e.g., using the "encrypted" value formats) or, | ||||
in case cleartext values are used (which is NOT RECOMMENDED per | ||||
Section 3.5 of [I-D.ietf-netconf-crypto-types]), then, e.g., | ||||
disk-level encryption may be used. | ||||
Current: | ||||
The keystore contents may be encrypted by either encrypting the | ||||
contents individually (e.g., using the "encrypted" value formats) | ||||
or using disk-level encryption, for example, in case cleartext | ||||
values are used (which is NOT RECOMMENDED per Section 3.5 of | ||||
[RFC9640]). | ||||
--> | ||||
<t>The keystore contents may be encrypted by either encrypting | ||||
the contents individually (e.g., using the "encrypted" value | the contents individually (e.g., using the "encrypted" value | |||
formats) or, in case cleartext values are used (which is NOT | formats) or using disk-level encryption, for example, in case | |||
RECOMMENDED per <xref section="3.5" target="I-D.ietf-netconf-crypto- | cleartext values are used (which is <bcp14>NOT | |||
types"/>), | RECOMMENDED</bcp14> per <xref target="RFC9640" sectionFormat="of" se | |||
then, e.g., disk-level encryption may be used.</t> | ction="3.5"/>).</t> | |||
<t>If the keystore contents are not encrypted when persisted, | <t>If the keystore contents are not encrypted when persisted, | |||
then server implementations MUST ensure the persisted storage | then server implementations <bcp14>MUST</bcp14> ensure the persisted storage | |||
is inaccessible.</t> | is inaccessible.</t> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Unconstrained Private Key Usage</name> | <name>Unconstrained Private Key Usage</name> | |||
<t>This module enables the configuration of private keys without | <t>This module enables the configuration of private 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 (e.g., signature, decryption, both).</t> | allowed to be used for (such as signature, decryption, or both).</t> | |||
<t>This module also does not constrain the usage of the associated | <t>This module also does not constrain the usage of the associated | |||
public keys, other than in the context of a configured certificate | public keys other than in the context of a configured certificate | |||
(e.g., an identity certificate), in which case the key usage is | (e.g., an identity certificate), in which case the key usage is | |||
constrained by the certificate.</t> | constrained by the certificate.</t> | |||
</section> | </section> | |||
<section anchor="sec-mod"> | <section anchor="sec-mod"> | |||
<name>Considerations for the "ietf-keystore" YANG Module</name> | ||||
<t>This section follows the template defined in <xref section="3.7.1" ta | <!--[rfced] *AD - We note that the text in Section 3.8 does not exactly match | |||
rget="RFC8407"/>.</t> | the YANG security considerations boilerplate text listed at | |||
<t>The YANG module defined in this document is designed to be accessed v | <https://wiki.ietf.org/group/ops/yang-security-guidelines>, including missing | |||
ia YANG | references to RFC 6242 and 8446. Please review and let us know if the text | |||
based management protocols, such as NETCONF <xref target="RFC6241"/> | should be updated to match. | |||
and | --> | |||
RESTCONF <xref target="RFC8040"/>. Both of these protocols have man | <name>Security Considerations for the "ietf-keystore" YANG Module</name> | |||
datory-to-implement | <t>This section follows the template defined in <xref target="RFC8407" s | |||
secure transport layers (e.g., SSH, TLS) with mutual authentication. | ectionFormat="of" section="3.7.1"/>.</t> | |||
</t> | ||||
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> prov | <!-- DNE: YANG Security Boilerplate: | |||
ides the means | Begin paragraph 1 | |||
to restrict access for particular users to a pre-configured subset o | SG reveted - AQed bc does not match the template --> | |||
f all available | <t>The YANG module specified in this document defines a schema for data | |||
protocol operations and content.</t> | that is designed to be accessed via network management protocols such as NETCONF | |||
<t>Please be aware that this YANG module uses groupings from | <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. Both of these pr | |||
otocols have mandatory-to-implement secure transport layers (e.g., Secure Shell | ||||
(SSH), TLS) with mutual authentication. | ||||
</t> | ||||
<!-- End paragraph 1--> | ||||
<!-- Begin paragraph 2 --> | ||||
<t>The Network Configuration Access Control Model (NACM) <xref | ||||
target="RFC8341"/> provides the means to restrict access for | ||||
particular users to a preconfigured subset | ||||
of all available protocol operations and | ||||
content.</t> | ||||
<!--End paragraph 2--> | ||||
<!-- Paragraph 3 is missing (or it's the paragraph below, which does not match t | ||||
he template --> | ||||
<t>Please be aware that this YANG module uses groupings from | ||||
other YANG modules that define nodes that may be considered | other YANG modules that define nodes that may be considered | |||
sensitive or vulnerable in network environments. Please | sensitive or vulnerable in network environments. Please | |||
review the Security Considerations for dependent YANG modules | review the Security Considerations for dependent YANG modules | |||
for information as to which nodes may be considered sensitive | for information as to which nodes may be considered sensitive | |||
or vulnerable in network environments.</t> | or vulnerable in network environments.</t> | |||
<t>Some of the readable data nodes defined in this YANG module | ||||
<!-- Begin Paragraph 4 --> | ||||
<t>Some of the readable data nodes in this YANG module | ||||
may be considered sensitive or vulnerable in some network | may be considered sensitive or vulnerable in some network | |||
environments. It is thus important to control read access | environments. It is thus important to control read access | |||
(e.g., via get, get-config, or notification) to these | (e.g., via get, get-config, or notification) to these | |||
data nodes. The following subtrees and data nodes have particular | data nodes. These are the subtrees and data nodes and their | |||
sensitivity/vulnerability: | sensitivity/vulnerability: | |||
<!-- End paragraph 4--> | ||||
<!--End DNE--> | ||||
</t> | </t> | |||
<ul spacing="normal"> | <dl spacing="normal" newline="true"> | |||
<li> | <dt>The "cleartext-symmetric-key" node:</dt> | |||
<t>The "cleartext-symmetric-key" node: | <dd>This node, imported from the "symmetric-key-grouping" | |||
</t> | grouping defined in <xref target="RFC9640"/>, is | |||
<ul empty="true"> | ||||
<li>The "cleartext-symmetric-key" node, imported from the "symmetr | ||||
ic-key-grouping" | ||||
grouping defined in <xref target="I-D.ietf-netconf-crypto-ty | ||||
pes"/> is | ||||
additionally sensitive to read operations such that, | additionally sensitive to read operations such that, | |||
in normal use cases, it should never be returned to a client . | in normal use cases, it should never be returned to a client . | |||
For this reason, the NACM extension "default-deny-all" was | For this reason, the NACM extension "default-deny-all" was | |||
applied to it in <xref target="I-D.ietf-netconf-crypto-types | applied to it in <xref target="RFC9640"/>.</dd> | |||
"/>.</li> | ||||
</ul> | <dt>The "cleartext-private-key" node:</dt> | |||
</li> | <dd>This node, defined in the "asymmetric-key-pair-grouping" | |||
<li> | grouping in <xref target="RFC9640"/>, is | |||
<t>The "cleartext-private-key" node: | ||||
</t> | ||||
<ul empty="true"> | ||||
<li>The "cleartext-private-key" node defined in the "asymmetric-ke | ||||
y-pair-grouping" | ||||
grouping defined in <xref target="I-D.ietf-netconf-crypto-ty | ||||
pes"/> is | ||||
additionally sensitive to read operations such that, in | additionally sensitive to read operations such that, in | |||
normal use cases, it should never be returned to a client. For this | normal use cases, it should never be returned to a client. For this | |||
reason, the NACM extension "default-deny-all" is applied | reason, the NACM extension "default-deny-all" is applied | |||
to it in <xref target="I-D.ietf-netconf-crypto-types"/>.</li | to it in <xref target="RFC9640"/>.</dd> | |||
> | </dl> | |||
</ul> | <t>All the writable data nodes defined by this YANG module, both in the | |||
</li> | ||||
</ul> | ||||
<t>All the writable data nodes defined by this module, both in the | ||||
"grouping" statements as well as the protocol-accessible "keystore" | "grouping" statements as well as the protocol-accessible "keystore" | |||
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 key or reference | environments. For instance, any modification to a key or reference | |||
to a key may dramatically alter the implemented security policy. | to a key may dramatically alter the implemented security policy. | |||
For this reason, the NACM extension "default-deny-write" has been | For this reason, the NACM extension "default-deny-write" has been | |||
set for all data nodes defined in this module.</t> | set for all data nodes defined in this module.</t> | |||
<t>This module does not define any "rpc" or "action" statements, and | <t>This YANG module does not define any "rpc" or "action" statements, an d | |||
thus the security considerations for such is not provided here.</t> | thus the security considerations for such is not provided here.</t> | |||
<t>Built-in key types SHOULD be either hidden and/or encrypted (not | <t>Built-in key types <bcp14>SHOULD</bcp14> be hidden and/or encrypted ( not | |||
cleartext). If this is not possible, access control mechanisms | cleartext). If this is not possible, access control mechanisms | |||
like NACM SHOULD be used to limit access to the key's secret data | like NACM <bcp14>SHOULD</bcp14> be used to limit access to the key's secret data | |||
to only the most trusted authorized clients (e.g., belonging to | to only the most trusted authorized clients (e.g., belonging to | |||
an organization’s crypto officer).</t> | an organization's crypto officer).</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<section> | <section> | |||
<name>The "IETF XML" Registry</name> | <name>The IETF XML Registry</name> | |||
<t>This document registers one URI in the "ns" subregistry of the | <t>IANA has registered the following URI in the "ns" registry of | |||
IETF XML Registry <xref target="RFC3688"/>. Following the format | the "IETF XML Registry" <xref target="RFC3688"/>.</t> | |||
in <xref target="RFC3688"/>, the following registration is | <dl spacing="compact"> | |||
requested:</t> | <dt>URI:</dt><dd> urn:ietf:params:xml:ns:yang:ietf-keystore</dd> | |||
<artwork><![CDATA[ | <dt>Registrant Contact:</dt><dd> The IESG</dd> | |||
URI: urn:ietf:params:xml:ns:yang:ietf-keystore | <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd> | |||
Registrant Contact: The IESG | </dl> | |||
XML: N/A, the requested URI is an XML namespace. | ||||
]]></artwork> | ||||
</section> | </section> | |||
<section> | <section> | |||
<name>The "YANG Module Names" Registry</name> | <name>The YANG Module Names Registry</name> | |||
<t>This document registers one YANG module in the | <t>IANA has registered the following YANG module in the | |||
YANG Module Names registry <xref target="RFC6020"/>. | "YANG Module Names" registry defined in <xref target="RFC6020"/>. | |||
Following the format in <xref target="RFC6020"/>, the | </t> | |||
following registration is requested:</t> | <dl spacing="compact"> | |||
<artwork><![CDATA[ | <dt>Name:</dt><dd>ietf-keystore</dd> | |||
name: ietf-keystore | <dt>Maintained by IANA:</dt><dd>N</dd> | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-keystore | <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-keystore</dd> | |||
prefix: ks | <dt>Prefix:</dt><dd>ks</dd> | |||
reference: RFC CCCC | <dt>Reference:</dt><dd>RFC 9642</dd> | |||
]]></artwork> | </dl> | |||
</section> | </section> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<displayreference target="I-D.ietf-netmod-system-config" to="NETMOD-SYSTEM-CONFI | ||||
G"/> | ||||
<displayreference target="I-D.ietf-netconf-http-client-server" to="HTTP-CLIENT-S | ||||
ERVER"/> | ||||
<displayreference target="I-D.ietf-netconf-netconf-client-server" to="NETCONF-CL | ||||
IENT-SERVER"/> | ||||
<displayreference target="I-D.ietf-netconf-restconf-client-server" to="RESTCONF- | ||||
CLIENT-SERVER"/> | ||||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 | ||||
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21 | |||
<front> | 19.xml"/> | |||
<title>Key words for use in RFCs to Indicate Requirement Levels</tit | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60 | |||
le> | 20.xml"/> | |||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62 | |||
<date month="March" year="1997"/> | 41.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79 | |||
<t>In many standards track documents several words are used to sig | 50.xml"/> | |||
nify the requirements in the specification. These words are often capitalized. T | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80 | |||
his document defines these words as they should be interpreted in IETF documents | 40.xml"/> | |||
. This document specifies an Internet Best Current Practices for the Internet Co | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
mmunity, and requests discussion and suggestions for improvements.</t> | 74.xml"/> | |||
</abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
</front> | 41.xml"/> | |||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="2119"/> | <!-- [I-D.ietf-netconf-crypto-types] companion document RFC 9640 --> | |||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | <reference anchor="RFC9640" target="https://www.rfc-editor.org/info/rfc9 | |||
</reference> | 640"> | |||
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6 | <front> | |||
020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"> | <title>YANG Data Types and Groupings for Cryptography</title> | |||
<front> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
<title>YANG - A Data Modeling Language for the Network Configuration | <organization>Watsen Networks</organization> | |||
Protocol (NETCONF)</title> | </author> | |||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | <date month="August" year="2024"/> | |||
"Bjorklund"/> | </front> | |||
<date month="October" year="2010"/> | <seriesInfo name="RFC" value="9640"/> | |||
<abstract> | <seriesInfo name="DOI" value="10.17487/RFC9640"/> | |||
<t>YANG is a data modeling language used to model configuration an | </reference> | |||
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON | ||||
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6020"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6020"/> | ||||
</reference> | ||||
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7 | ||||
950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"> | ||||
<front> | ||||
<title>The YANG 1.1 Data Modeling Language</title> | ||||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | ||||
<date month="August" year="2016"/> | ||||
<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> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7950"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7950"/> | ||||
</reference> | ||||
<reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8 | ||||
341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"> | ||||
<front> | ||||
<title>Network Configuration Access Control Model</title> | ||||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<date month="March" year="2018"/> | ||||
<abstract> | ||||
<t>The standardization of network configuration interfaces for use | ||||
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ | ||||
ires a structured and secure operating environment that promotes human usability | ||||
and multi-vendor interoperability. There is a need for standard mechanisms to r | ||||
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu | ||||
red subset of all available NETCONF or RESTCONF protocol operations and content. | ||||
This document defines such an access control model.</t> | ||||
<t>This document obsoletes RFC 6536.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="91"/> | ||||
<seriesInfo name="RFC" value="8341"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8341"/> | ||||
</reference> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | ||||
.ietf-netconf-crypto-types.xml"/> | ||||
</references> | </references> | |||
<references> | <references> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 | ||||
688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36 | |||
<front> | 88.xml"/> | |||
<title>The IETF XML Registry</title> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
<author fullname="M. Mealling" initials="M." surname="Mealling"/> | 40.xml"/> | |||
<date month="January" year="2004"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83 | |||
<abstract> | 42.xml"/> | |||
<t>This document describes an IANA maintained registry for IETF st | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84 | |||
andards which use Extensible Markup Language (XML) related items such as Namespa | 07.xml"/> | |||
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew | ||||
ork (RDF) Schemas.</t> | <!-- [I-D.ietf-netconf-trust-anchors] companion document RFC 9641--> | |||
</abstract> | <reference anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc9 | |||
</front> | 641"> | |||
<seriesInfo name="BCP" value="81"/> | <front> | |||
<seriesInfo name="RFC" value="3688"/> | <title>A YANG Data Model for a Truststore</title> | |||
<seriesInfo name="DOI" value="10.17487/RFC3688"/> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
</reference> | <organization>Watsen Networks</organization> | |||
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 | </author> | |||
241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"> | <date month="August" year="2024"/> | |||
<front> | </front> | |||
<title>Network Configuration Protocol (NETCONF)</title> | <seriesInfo name="RFC" value="9641"/> | |||
<author fullname="R. Enns" initials="R." role="editor" surname="Enns | <seriesInfo name="DOI" value="10.17487/RFC9641"/> | |||
"/> | </reference> | |||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | <!-- [I-D.ietf-netconf-tcp-client-server] companion document RFC 9643 --> | |||
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn | <reference anchor="RFC9643" target="https://www.rfc-editor.org/info/rfc9 | |||
ame="Schoenwaelder"/> | 643"> | |||
<author fullname="A. Bierman" initials="A." role="editor" surname="B | ||||
ierman"/> | ||||
<date month="June" year="2011"/> | ||||
<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> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6241"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6241"/> | ||||
</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"> | ||||
<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>This document describes an HTTP-based protocol that provides a | ||||
programmatic interface for accessing data defined in YANG, using the datastore c | ||||
oncepts defined in the Network Configuration Protocol (NETCONF).</t> | ||||
</abstract> | ||||
</front> | ||||
<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" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> | ||||
<front> | ||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti | ||||
tle> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<date month="May" year="2017"/> | ||||
<abstract> | ||||
<t>RFC 2119 specifies common key words that may be used in protoco | ||||
l specifications. This document aims to reduce the ambiguity by clarifying that | ||||
only UPPERCASE usage of the key words have the defined special meanings.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="8174"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/> | ||||
</reference> | ||||
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8 | ||||
340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"> | ||||
<front> | ||||
<title>YANG Tree Diagrams</title> | ||||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | ||||
<author fullname="L. Berger" initials="L." role="editor" surname="Be | ||||
rger"/> | ||||
<date month="March" year="2018"/> | ||||
<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> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="215"/> | ||||
<seriesInfo name="RFC" value="8340"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8340"/> | ||||
</reference> | ||||
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8 | ||||
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"> | ||||
<front> | <front> | |||
<title>Network Management Datastore Architecture (NMDA)</title> | <title>YANG Groupings for TCP Clients and TCP Servers</title> | |||
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae | <organization>Watsen Networks</organization> | |||
lder"/> | </author> | |||
<author fullname="P. Shafer" initials="P." surname="Shafer"/> | <author initials="M." surname="Scharf" fullname="Michael Scharf"> | |||
<author fullname="K. Watsen" initials="K." surname="Watsen"/> | <organization>Hochschule Esslingen - University of Applied | |||
<author fullname="R. Wilton" initials="R." surname="Wilton"/> | Sciences</organization> | |||
<date month="March" year="2018"/> | </author> | |||
<abstract> | <date month="August" year="2024"/> | |||
<t>Datastores are a fundamental concept binding the data models wr | ||||
itten in the YANG data modeling language to network management protocols such as | ||||
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define | ||||
s an architectural framework for datastores based on the experience gained with | ||||
the initial simpler model, addressing requirements that were not well supported | ||||
in the initial model. This document updates RFC 7950.</t> | ||||
</abstract> | ||||
</front> | </front> | |||
<seriesInfo name="RFC" value="8342"/> | <seriesInfo name="RFC" value="9643"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC8342"/> | <seriesInfo name="DOI" value="10.17487/RFC9643"/> | |||
</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"> | <!-- [I-D.ietf-netconf-ssh-client-server] companion document RFC 9644--> | |||
<reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc96 | ||||
44"> | ||||
<front> | ||||
<title>YANG Groupings for SSH Clients and SSH Servers</title> | ||||
<author initials="K." surname="Watsen" fullname="Kent Watsen"> | ||||
<organization>Watsen Networks</organization> | ||||
</author> | ||||
<date month="August" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9644"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9644"/> | ||||
</reference> | ||||
<!-- [I-D.ietf-netconf-tls-client-server] IESG state: RFC Ed Queue as of 04/01/2 | ||||
4; companion document RFC 9645 --> | ||||
<reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc9 | ||||
645"> | ||||
<front> | <front> | |||
<title>Guidelines for Authors and Reviewers of Documents Containing | <title>YANG Groupings for TLS Clients and TLS Servers</title> | |||
YANG Data Models</title> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
<author fullname="A. Bierman" initials="A." surname="Bierman"/> | <organization>Watsen Networks</organization> | |||
<date month="October" year="2018"/> | </author> | |||
<abstract> | <date month="August" year="2024"/> | |||
<t>This memo provides guidelines for authors and reviewers of spec | ||||
ifications containing YANG modules. Recommendations and procedures are defined, | ||||
which are intended to increase interoperability and usability of Network Configu | ||||
ration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YAN | ||||
G modules. This document obsoletes RFC 6087.</t> | ||||
</abstract> | ||||
</front> | </front> | |||
<seriesInfo name="BCP" value="216"/> | <seriesInfo name="RFC" value="9645"/> | |||
<seriesInfo name="RFC" value="8407"/> | <seriesInfo name="DOI" value="10.17487/RFC9645"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC8407"/> | ||||
</reference> | </reference> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | ||||
.ietf-netconf-trust-anchors.xml"/> | <!-- [I-D.ietf-netconf-http-client-server] IESG state: IESG Evaluation::Revised | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | I-D Needed (8/23/2024)--> | |||
.ietf-netconf-keystore.xml"/> | <xi:include | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-http-cl | |||
.ietf-netconf-tcp-client-server.xml"/> | ient-server"/> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | ||||
.ietf-netconf-ssh-client-server.xml"/> | <!-- [I-D.ietf-netconf-netconf-client-server] IESG state: AD Evaluation as of 08 | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | /23/24 --> | |||
.ietf-netconf-tls-client-server.xml"/> | <xi:include | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-netconf | |||
.ietf-netconf-http-client-server.xml"/> | -client-server"/> | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | ||||
.ietf-netconf-netconf-client-server.xml"/> | <!-- [I-D.ietf-netconf-restconf-client-server] IESG state: AD Evaluation as of 8 | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | /23/2024 --> | |||
.ietf-netconf-restconf-client-server.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net | |||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D | conf-restconf-client-server"/> | |||
.ietf-netmod-system-config.xml"/> | ||||
<!-- [I-D.ietf-netmod-system-config] IESG state: I-D Exists as of 8/23/24. Enter | ||||
ed the long way to display the Ed role --> | ||||
<reference anchor="I-D.ietf-netmod-system-config" target="https://datatracker.ie | ||||
tf.org/doc/html/draft-ietf-netmod-system-config-08"> | ||||
<front> | ||||
<title>System-defined Configuration</title> | ||||
<author fullname="Qiufang Ma" initials="Q." surname="Ma" role="editor"> | ||||
<organization>Huawei</organization> | ||||
</author> | ||||
<author fullname="Qin Wu" initials="Q." surname="Wu"> | ||||
<organization>Huawei</organization> | ||||
</author> | ||||
<author fullname="Chong Feng" initials="C." surname="Feng"/> | ||||
<date day="18" month="June" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-system-config-08"/> | ||||
</reference> | ||||
<reference anchor="Std-802.1AR-2018" target="https://standards.ieee.org/ standard/802_1AR-2018.html"> | <reference anchor="Std-802.1AR-2018" target="https://standards.ieee.org/ standard/802_1AR-2018.html"> | |||
<front> | <front> | |||
<title>IEEE Standard for Local and metropolitan area networks - Secu re Device Identity</title> | <title>IEEE Standard for Local and Metropolitan Area Networks - Secu re Device Identity</title> | |||
<author> | <author> | |||
<organization>IEEE SA-Standards Board</organization> | <organization>IEEE</organization> | |||
</author> | </author> | |||
<date month="August" year="2018"/> | <date month="August" year="2018"/> | |||
</front> | </front> | |||
<seriesInfo name="IEEE Std" value="802.1AR-2018"/> | ||||
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/> | ||||
</reference> | </reference> | |||
</references> | </references> | |||
</references> | </references> | |||
<section anchor="change-log"> | ||||
<name>Change Log</name> | ||||
<section> | ||||
<name>00 to 01</name> | ||||
<ul spacing="normal"> | ||||
<li>Replaced the 'certificate-chain' structures with PKCS#7 structures | ||||
. | ||||
(Issue #1)</li> | ||||
<li>Added 'private-key' as a configurable data node, and removed the | ||||
'generate-private-key' and 'load-private-key' actions. (Issue #2) | ||||
</li> | ||||
<li>Moved 'user-auth-credentials' to the ietf-ssh-client module. | ||||
(Issues #4 and #5)</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>01 to 02</name> | ||||
<ul spacing="normal"> | ||||
<li>Added back 'generate-private-key' action.</li> | ||||
<li>Removed 'RESTRICTED' enum from the 'private-key' leaf type.</li> | ||||
<li>Fixed up a few description statements.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>02 to 03</name> | ||||
<ul spacing="normal"> | ||||
<li>Changed draft's title.</li> | ||||
<li>Added missing references.</li> | ||||
<li>Collapsed sections and levels.</li> | ||||
<li>Added RFC 8174 to Requirements Language Section.</li> | ||||
<li>Renamed 'trusted-certificates' to 'pinned-certificates'.</li> | ||||
<li>Changed 'public-key' from config false to config true.</li> | ||||
<li>Switched 'host-key' from OneAsymmetricKey to definition from RFC 4 | ||||
253.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>03 to 04</name> | ||||
<ul spacing="normal"> | ||||
<li>Added typedefs around leafrefs to common keystore paths</li> | ||||
<li>Now tree diagrams reference ietf-netmod-yang-tree-diagrams</li> | ||||
<li>Removed Design Considerations section</li> | ||||
<li>Moved key and certificate definitions from data tree to groupings< | ||||
/li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>04 to 05</name> | ||||
<ul spacing="normal"> | ||||
<li>Removed trust anchors (now in their own draft)</li> | ||||
<li>Added back global keystore structure</li> | ||||
<li>Added groupings enabling keys to either be locally defined or a re | ||||
ference to the keystore.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>05 to 06</name> | ||||
<ul spacing="normal"> | ||||
<li>Added feature "local-keys-supported"</li> | ||||
<li>Added nacm:default-deny-all and nacm:default-deny-write</li> | ||||
<li>Renamed generate-asymmetric-key to generate-hidden-key</li> | ||||
<li>Added an install-hidden-key action</li> | ||||
<li>Moved actions inside fo the "asymmetric-key" container</li> | ||||
<li>Moved some groupings to draft-ietf-netconf-crypto-types</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>06 to 07</name> | ||||
<ul spacing="normal"> | ||||
<li>Removed a "require-instance false"</li> | ||||
<li>Clarified some description statements</li> | ||||
<li>Improved the keystore-usage examples</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>07 to 08</name> | ||||
<ul spacing="normal"> | ||||
<li>Added "inline-definition" containers to avoid posibility of the | ||||
action/notification statements being under a "case" statement.</ | ||||
li> | ||||
<li>Updated copyright date, boilerplate template, affiliation, | ||||
folding algorithm, and reformatted the YANG module.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>08 to 09</name> | ||||
<ul spacing="normal"> | ||||
<li>Added a 'description' statement to the 'must' in the | ||||
/keystore/asymmetric-key node explaining that the descendant | ||||
values may exist in <operational> only, and that | ||||
implementation MUST assert that the values are either | ||||
configured or that they exist in <operational>.</li> | ||||
<li>Copied above 'must' statement (and description) into | ||||
the inline-or-keystore-asymmetric-key-grouping, | ||||
inline-or-keystore-asymmetric-key-with-certs-grouping, | ||||
and inline-or-keystore-end-entity-cert-with-key-grouping | ||||
statements.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>09 to 10</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated draft title to match new truststore draft title</li> | ||||
<li>Moved everything under a top-level 'grouping' to enable use in oth | ||||
er contexts.</li> | ||||
<li>Renamed feature from 'local-keys-supported' to 'inline-definitions | ||||
-supported' (same name used in truststore)</li> | ||||
<li>Removed the either-all-or-none 'must' expressions for the key's 3- | ||||
tuple values (since the values are now 'mandatory true' in crypto-types)</li> | ||||
<li>Example updated to reflect 'mandatory true' change in crypto-types | ||||
draft</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>10 to 11</name> | ||||
<ul spacing="normal"> | ||||
<li>Replaced typedef asymmetric-key-certificate-ref with grouping asym | ||||
metric-key-certificate-ref-grouping.</li> | ||||
<li>Added feature feature 'key-generation'.</li> | ||||
<li>Cloned groupings symmetric-key-grouping, asymmetric-key-pair-group | ||||
ing, | ||||
asymmetric-key-pair-with-cert-grouping, and asymmetric-key-pair | ||||
-with-certs-grouping | ||||
from crypto-keys, augmenting into each new case statements for | ||||
values that | ||||
have been encrypted by other keys in the keystore. Refactored | ||||
keystore model | ||||
to use these groupings.</li> | ||||
<li>Added new 'symmetric-keys' lists, as a sibling to the existing 'as | ||||
ymmetric-keys' list.</li> | ||||
<li>Added RPCs (not actions) 'generate-symmetric-key' and 'generate-as | ||||
ymmetric-key' to | ||||
*return* a (potentially encrypted) key.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>11 to 12</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated to reflect crypto-type's draft using enumerations over ide | ||||
ntities.</li> | ||||
<li>Added examples for the 'generate-symmetric-key' and 'generate-asym | ||||
metric-key' RPCs.</li> | ||||
<li>Updated the Introduction section.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>12 to 13</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated examples to incorporate new "key-format" identities.</li> | ||||
<li>Made the two "generate-*-key" RPCs be "action" statements instead. | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>13 to 14</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated YANG module and examples to incorporate the new iana-*-alg | ||||
orithm modules in the crypto-types draft.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>14 to 15</name> | ||||
<ul spacing="normal"> | ||||
<li>Added new "Support for Built-in Keys" section.</li> | ||||
<li>Added 'must' expressions asserting that the 'key-format' leaf when | ||||
ever an encrypted key is specified.</li> | ||||
<li>Added inline-or-keystore-symmetric-key-grouping for PSK support.</ | ||||
li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>15 to 16</name> | ||||
<ul spacing="normal"> | ||||
<li>Moved the generate key actions to ietf-crypt-types as RPCs, which | ||||
are | ||||
augmented by ietf-keystore to support encrypted keys. Examples | ||||
updated | ||||
accordingly.</li> | ||||
<li>Added a SSH certificate-based key (RFC 6187) and a raw private key | ||||
to | ||||
the example instance document (partly so they could be reference | ||||
d by | ||||
examples in the SSH and TLS client/server drafts.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>16 to 17</name> | ||||
<ul spacing="normal"> | ||||
<li>Removed augments to the "generate-symmetric-key" and "generate-asy | ||||
mmetric-key" groupings.</li> | ||||
<li>Removed "generate-symmetric-key" and "generate-asymmetric-key" exa | ||||
mples.</li> | ||||
<li>Removed the "algorithm" nodes from remaining examples.</li> | ||||
<li>Updated the "Support for Built-in Keys" section.</li> | ||||
<li>Added new section "Encrypting Keys in Configuration".</li> | ||||
<li>Added a "Note to Reviewers" note to first page.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>17 to 18</name> | ||||
<ul spacing="normal"> | ||||
<li>Removed dangling/unnecessary ref to RFC 8342.</li> | ||||
<li>r/MUST/SHOULD/ wrt strength of keys being configured over transpor | ||||
ts.</li> | ||||
<li>Added an example for the "certificate-expiration" notification.</l | ||||
i> | ||||
<li>Clarified that OS MAY have a multiplicity of underlying keystores | ||||
and/or TPMs.</li> | ||||
<li>Clarified expected behavior for "built-in" keys in <operational | ||||
></li> | ||||
<li>Clarified the "Migrating Configuration to Another Server" section. | ||||
</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>18 to 19</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated examples to reflect new "cleartext-" prefix in the crypto- | ||||
types draft.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>19 to 20</name> | ||||
<ul spacing="normal"> | ||||
<li>Addressed SecDir comments from Magnus Nystroem and Sandra Murphy.< | ||||
/li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>20 to 21</name> | ||||
<ul spacing="normal"> | ||||
<li>Added a "Unconstrained Private Key Usage" Security Consideration t | ||||
o address | ||||
concern raised by SecDir.</li> | ||||
<li>(Editorial) Removed the output of "grouping" statements in the tre | ||||
e diagrams | ||||
for the "ietf-keystore" and "ex-keystore-usage" modules.</li> | ||||
<li>Addressed comments raised by YANG Doctor.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>21 to 22</name> | ||||
<ul spacing="normal"> | ||||
<li>Added prefixes to 'path' statements per trust-anchors/issues/1</li | ||||
> | ||||
<li>Renamed feature "keystore-supported" to "central-keystore-supporte | ||||
d".</li> | ||||
<li>Associated with above, generally moved text to refer to a "central | ||||
" keystore.</li> | ||||
<li>Aligned modules with `pyang -f` formatting.</li> | ||||
<li>Fixed nits found by YANG Doctor reviews.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>22 to 23</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated 802.1AR ref to latest version</li> | ||||
<li>Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.</ | ||||
li> | ||||
<li>Minor editorial nits</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>23 to 24</name> | ||||
<ul spacing="normal"> | ||||
<li>Added features "asymmetric-keys" and "symmetric-keys"</li> | ||||
<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>24 to 25</name> | ||||
<ul spacing="normal"> | ||||
<li>Added a "term" for "key" (IEEE liaison).</li> | ||||
<li>Clarified draft text to ensure proper use of the "key" term. (IEEE | ||||
liaison)</li> | ||||
<li>Added statement that built-in keys SHOULD NOT be cleartext. (IEEE | ||||
liaison)</li> | ||||
<li>Added "if-feature central-keystore-supported" to top-level "keysto | ||||
re" container.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>25 to 26</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated per Shepherd reviews impacting the suite of drafts.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>26 to 27</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated per Shepherd reviews impacting the suite of drafts.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>27 to 28</name> | ||||
<ul spacing="normal"> | ||||
<li>Updated per Tom Petch review.</li> | ||||
<li>s/local/inline/ in feature names, grouping names, and node names.< | ||||
/li> | ||||
<li>Removed special handling text for built-in keys</li> | ||||
<li>Updated section on built-in keys to read almost the same as | ||||
the section in the trust-anchors draft.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>28 to 29</name> | ||||
<ul spacing="normal"> | ||||
<li>Addresses AD review comments.</li> | ||||
<li>Added note to Editor to fix line foldings.</li> | ||||
<li>Renamed "keystore" to "central keystore" throughout.</li> | ||||
<li>Renamed "encrypted-by-choice-grouping" to "encrypted-by-grouping". | ||||
</li> | ||||
<li>Removed "public-key-format" and "public-key" nodes from examples.< | ||||
/li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>29 to 30</name> | ||||
<ul spacing="normal"> | ||||
<li>Addresses Gen-ART review by Reese Enghardt.</li> | ||||
<li>Addresses review by Tom Petch.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>30 to 31</name> | ||||
<ul spacing="normal"> | ||||
<li>Addresses 1st-round of IESG reviews.</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>31 to 33</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> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>33 to 34</name> | ||||
<ul spacing="normal"> | ||||
<li>Nothing changed. Only bumped for automation...</li> | ||||
</ul> | ||||
</section> | ||||
<section> | ||||
<name>34 to 35</name> | ||||
<ul spacing="normal"> | ||||
<li>Address Roman Danyliw's comments.</li> | ||||
</ul> | ||||
</section> | ||||
</section> | ||||
<section numbered="false"> | <section numbered="false"> | |||
<name>Acknowledgements</name> | <name>Acknowledgements</name> | |||
<t>The authors would like to thank the following for | <t>The authors would like to thank the following for | |||
lively discussions on list and in the halls (ordered | lively discussions on list and in the halls (ordered | |||
by first name): | by first name): | |||
Alan Luchuk, | <contact fullname="Alan Luchuk"/>, | |||
Andy Bierman, | <contact fullname="Andy Bierman"/>, | |||
Benoit Claise, | <contact fullname="Balázs Kovács"/>, | |||
Bert Wijnen, | <contact fullname="Benoit Claise"/>, | |||
Balázs Kovács, | <contact fullname="Bert Wijnen"/>, | |||
David Lamparter, | <contact fullname="David Lamparter"/>, | |||
Eric Voit, | <contact fullname="Eric Voit"/>, | |||
Éric Vyncke, | <contact fullname="Éric Vyncke"/>, | |||
Francesca Palombini, | <contact fullname="Francesca Palombini"/>, | |||
Ladislav Lhotka, | <contact fullname="Jürgen Schönwälder"/>, | |||
Liang Xia, | <contact fullname="Ladislav Lhotka"/>, | |||
Jürgen Schönwälder, | <contact fullname="Liang Xia"/>, | |||
Mahesh Jethanandani, | <contact fullname="Magnus Nyström"/>, | |||
Magnus Nyström, | <contact fullname="Mahesh Jethanandani"/>, | |||
Martin Björklund, | <contact fullname="Martin Björklund"/>, | |||
Mehmet Ersue, | <contact fullname="Mehmet Ersue"/>, | |||
Murray Kucherawy, | <contact fullname="Murray Kucherawy"/>, | |||
Paul Wouters, | <contact fullname="Paul Wouters"/>, | |||
Phil Shafer, | <contact fullname="Phil Shafer"/>, | |||
Qin Wu, | <contact fullname="Qin Wu"/>, | |||
Radek Krejci, | <contact fullname=" Radek Krejci"/>, | |||
Ramkumar Dhanapal, | <contact fullname="Ramkumar Dhanapal"/>, | |||
Reese Enghardt, | <contact fullname="Reese Enghardt"/>, | |||
Reshad Rahman, | <contact fullname=" Reshad Rahman"/>, | |||
Rob Wilton, | <contact fullname="Rob Wilton"/>, | |||
Roman Danyliw, | <contact fullname="Roman Danyliw"/>, | |||
Sandra Murphy, | <contact fullname="Sandra Murphy"/>, | |||
Sean Turner, | <contact fullname=" Sean Turner"/>, | |||
Tom Petch, | <contact fullname="Tom Petch"/>, | |||
Warren Kumari, | <contact fullname="Warren Kumari"/>, | |||
and Zaheduzzaman Sarker.</t> | and <contact fullname="Zaheduzzaman Sarker"/>.</t> | |||
</section> | </section> | |||
<!-- [rfced] We updated several <artwork> elements to <sourcecode>. | ||||
Please review and confirm if this is correct or if further | ||||
updates are needed. | ||||
In addition, please consider whether the "type" attribute of the | ||||
sourcecode elements has been set correctly or if updates are needed. | ||||
The current list of preferred values for "type" is available at | ||||
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current | ||||
list does not contain an applicable type, feel free to suggest additions | ||||
for consideration. Note that it is also acceptable to leave the "type" | ||||
attribute not set. | ||||
--> | ||||
<!-- [rfced] FYI - We have added expansions for the following abbreviations | ||||
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each | ||||
expansion in the document carefully to ensure correctness. | ||||
Initial Device Identifier (IDevID) | ||||
Network Configuration Protocol (NETCONF) | ||||
Secure Shell (SSH) | ||||
Note: we made this term lowercase to match the companion documents: | ||||
trusted platform module (TPM) | ||||
--> | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the online | ||||
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
and let us know if any changes are needed. | ||||
For example, please consider whether the following should be updated: | ||||
- Master | ||||
In addition, please consider whether "traditional" should be updated | ||||
for clarity. While the NIST website | ||||
<https://www.nist.gov/nist-research-library/ | ||||
nist-technical-series-publications-author-instructions#table1> | ||||
indicates that this term is potentially biased, it is also ambiguous. | ||||
"Tradition" is a subjective term, as it is not the same for everyone. | ||||
--> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 173 change blocks. | ||||
981 lines changed or deleted | 662 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |