rfc9640.original.xml   rfc9640.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
<?rfc sortrefs="yes" ?> ipr="trust200902" submissionType="IETF" docName="draft-ietf-netconf-crypto-types
<?rfc compact="yes"?> -34" number="9640" obsoletes="" updates="" tocInclude="true" symRefs="true" sort
<?rfc subcompact="no"?> Refs="true" version="3" xml:lang="en">
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<!-- <?rfc-ext allow-markup-in-artwork="yes" ?> what does this do? -->
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<!--<rfc xmlns:xiax="https://watsen.net/xiax" category="std" ipr="trust200902" d
ocName="draft-ietf-netconf-crypto-types-34">-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
ipr="trust200902" submissionType="IETF" docName="draft-ietf-netconf-crypto-types
-34" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="YANG Data Types and Groupings for Crypto">YANG Data Types and Groupings for Cryptography</title> <title abbrev="YANG Data Types and Groupings for Crypto">YANG Data Types and Groupings for Cryptography</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-crypto-types-34" /> <seriesInfo name="RFC" value="9640"/>
<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 month="October" year="2024"/>
<area>Operations</area> <area>OPS</area>
<workgroup>NETCONF Working Group</workgroup> <workgroup>netconf</workgroup>
<abstract> <abstract>
<t>This document presents a YANG 1.1 (RFC 7950) module defining identities , <t>This document presents a YANG 1.1 (RFC 7950) module defining identities ,
typedefs, and groupings useful to cryptographic applications.</t> typedefs, and groupings useful to cryptographic applications.</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 summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.</t>
<t>Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
</t>
<ul spacing="normal">
<li>
<tt>AAAA</tt> --&gt; the assigned RFC value for this draft</li>
</ul>
<t>Artwork in this document contains placeholder values for the date
of publication of this draft. Please apply the following replacement:
</t>
<ul spacing="normal">
<li>
<tt>2024-03-16</tt> --&gt; the publication date of this draft</li>
</ul>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/>
contains
the text "one or more YANG modules" and, later, "modules". This text
is sourced
from a file in a context where it is unknown how many modules a draft
defines.
The text is not wrong as is, but it may be improved by stating more di
rectly how
many modules are defined.</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/>
contains
a self-reference to this draft, along with a corresponding reference i
n
the Appendix. Please replace the self-reference in this section with
"This RFC"
(or similar) and remove the self-reference in the "Normative/Informati
ve References"
section, whichever it is in.</t>
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined i
n RFC 8792.
However, nicer-to-the-eye is when the '\\' line-folding mode is used.
The AD suggested
suggested putting a request here for the RFC Editor to help convert "u
gly" '\' folded
examples to use the '\\' folding mode. "Help convert" may be interpre
ted as, identify
what looks ugly and ask the authors to make the adjustment.</t>
<t>The following Appendix section is to be removed prior to publication:
</t>
<ul spacing="normal">
<li>
<xref target="change-log"/>. Change Log</li>
</ul>
</note>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>This document presents a YANG 1.1 <xref target="RFC7950"/> <t>This document presents a YANG 1.1 <xref target="RFC7950"/>
module defining identities, typedefs, and groupings useful to module defining identities, typedefs, and groupings useful to
cryptographic applications.</t> cryptographic applications.</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 both the NETCONF <xref target="RFC6241"/> and and servers of both the Network Configuration Protocol (NETCONF) <xr
RESTCONF <xref target="RFC8040"/> protocols.</t> ef target="RFC6241"/> and
RESTCONF <xref target="RFC8040"/>.</t>
<t> The dependency relationship between the primary YANG groupings <t> The dependency relationship between the primary YANG groupings
defined in the various RFCs is presented in the below diagram. defined in the various RFCs is presented in the below diagram.
In some cases, a draft may define secondary groupings that In some cases, a document may define secondary groupings that
introduce dependencies not illustrated in the diagram. introduce dependencies not illustrated in the diagram.
The labels in the diagram are a shorthand name for the defining The labels in the diagram are shorthand names for the defining
RFC. The citation reference for shorthand name is provided below RFCs. The citation references for 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 align="center"><![CDATA[
crypto-types crypto-types
^ ^ ^ ^
/ \ / \
/ \ / \
truststore keystore truststore keystore
^ ^ ^ ^ ^ ^ ^ ^
| +---------+ | | | +---------+ | |
| | | | | | | |
| +------------+ | | +------------+ |
tcp-client-server | / | | tcp-client-server | / | |
skipping to change at line 132 skipping to change at line 77
| | | +-----+ +---------+ | | | | +-----+ +---------+ |
| | | | | | | | | | | |
| +-----------|--------|--------------+ | | | +-----------|--------|--------------+ | |
| | | | | | | | | | | |
+-----------+ | | | | | +-----------+ | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
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 ws? -->
<table> <table>
<name>Label in Diagram to RFC Mapping</name> <name>Labels in Diagram to RFC Mapping</name>
<tbody> <tbody>
<tr> <tr>
<th>Label in Diagram</th> <th>Label in Diagram</th>
<th>Originating RFC</th> <th>Reference</th>
</tr> </tr>
<tr> <tr>
<td>crypto-types</td> <td>crypto-types</td>
<td> <td>
<xref target="I-D.ietf-netconf-crypto-types"/></td> RFC 9640</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> <xref target="RFC9642"/></td>
</tr> </tr>
<tr> <tr>
<td>tcp-client-server</td> <td>tcp-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-tcp-client-server"/></td> <xref target="RFC9643"/></td>
</tr> </tr>
<tr> <tr>
<td>ssh-client-server</td> <td>ssh-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-ssh-client-server"/></td> <xref target="RFC9644"/></td>
</tr> </tr>
<tr> <tr>
<td>tls-client-server</td> <td>tls-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-tls-client-server"/></td> <xref target="RFC9645"/></td>
</tr> </tr>
<tr> <tr>
<td>http-client-server</td> <td>http-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-http-client-server"/></td> <xref target="I-D.ietf-netconf-http-client-server"/></td>
</tr> </tr>
<tr> <tr>
<td>netconf-client-server</td> <td>netconf-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-netconf-client-server"/></td> <xref target="I-D.ietf-netconf-netconf-client-server"/></td>
skipping to change at line 190 skipping to change at line 134
<tr> <tr>
<td>restconf-client-server</td> <td>restconf-client-server</td>
<td> <td>
<xref target="I-D.ietf-netconf-restconf-client-server"/></td> <xref target="I-D.ietf-netconf-restconf-client-server"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section>
<name>Specification Language</name> <name>Specification Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/ NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section> <section>
<name>Adherence to the NMDA</name> <name>Adherence to the NMDA</name>
<t>This document is compliant with the Network Management Datastore <t>This document is compliant with the Network Management Datastore
Architecture (NMDA) <xref target="RFC8342"/>. It does not define Architecture (NMDA) <xref target="RFC8342"/>. It does not define
any protocol accessible nodes that are "config false".</t> any protocol-accessible nodes that are "config false".</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 (per <xref section="9.8" target="RFC7950"/>). This encoded (per <xref section="9.8" sectionFormat="of" target="RFC7950"
placeholder value is used because real base64 encoded structures />). This
placeholder value is used because real base64-encoded structures
are often many lines long and hence distracting to the example are often many lines long and hence distracting to the example
being presented.</t> being presented.</t>
<t>Various examples in this document use the XML
<xref target="W3C.REC-xml-20081126"/> encoding. Other encodings, such as
JSON <xref target="RFC8259"/>,
could alternatively be used.</t>
<t>Various examples in this document contain long lines that may be folde
d,
as described in <xref target="RFC8792"/>.</t>
</section> </section>
</section> </section>
<section> <section>
<name>The "ietf-crypto-types" Module</name> <name>The "ietf-crypto-types" Module</name>
<t>This section defines a YANG 1.1 <xref target="RFC7950"/> module called <t>This section defines a YANG 1.1 <xref target="RFC7950"/> module called
"ietf-crypto-types". A high-level overview of the module is provided in "ietf-crypto-types". A high-level overview of the module is provided in
<xref target="crypto-types-overview"/>. Examples illustrating the modu le's use <xref target="crypto-types-overview"/>. Examples illustrating the modu le's use
are provided in <xref target="crypto-types-examples">Examples</xref>. The YANG are provided in <xref target="crypto-types-examples"/>. The YANG
module itself is defined in <xref target="crypto-types-yang-module"/>. </t> module itself is defined in <xref target="crypto-types-yang-module"/>. </t>
<section anchor="crypto-types-overview"> <section anchor="crypto-types-overview">
<name>Data Model Overview</name> <name>Data Model Overview</name>
<t>This section provides an overview of the "ietf-crypto-types" module <t>This section provides an overview of the "ietf-crypto-types" module
in terms of its features, identities, typedefs, and groupings.</t> in terms of its features, identities, typedefs, and groupings.</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-crypto-types" module:</t> defined in the "ietf-crypto-types" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Features: Features:
+-- one-symmetric-key-format +-- one-symmetric-key-format
+-- one-asymmetric-key-format +-- one-asymmetric-key-format
+-- symmetrically-encrypted-value-format +-- symmetrically-encrypted-value-format
+-- asymmetrically-encrypted-value-format +-- asymmetrically-encrypted-value-format
+-- cms-enveloped-data-format +-- cms-enveloped-data-format
+-- cms-encrypted-data-format +-- cms-encrypted-data-format
+-- p10-csr-format +-- p10-csr-format
+-- csr-generation +-- csr-generation
+-- certificate-expiration-notification +-- certificate-expiration-notification
+-- cleartext-passwords +-- cleartext-passwords
+-- encrypted-passwords +-- encrypted-passwords
+-- cleartext-symmetric-keys +-- cleartext-symmetric-keys
+-- hidden-symmetric-keys +-- hidden-symmetric-keys
+-- encrypted-symmetric-keys +-- encrypted-symmetric-keys
+-- cleartext-private-keys +-- cleartext-private-keys
+-- hidden-private-keys +-- hidden-private-keys
+-- encrypted-private-keys +-- encrypted-private-keys
]]></artwork> ]]></sourcecode>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
the same as that in <xref target="RFC8340"/>.</t> the same as that in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section> </section>
<section anchor="identities" toc="exclude"> <section anchor="identities" toc="exclude">
<name>Identities</name> <name>Identities</name>
<t>The following diagram illustrates the hierarchical relationship <t>The following diagram illustrates the hierarchical relationship
amongst the "identity" statements defined in the "ietf-crypto-type s" amongst the "identity" statements defined in the "ietf-crypto-type s"
module:</t> module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Identities: Identities:
+-- public-key-format +-- public-key-format
| +-- subject-public-key-info-format | +-- subject-public-key-info-format
| +-- ssh-public-key-format | +-- ssh-public-key-format
+-- private-key-format +-- private-key-format
| +-- rsa-private-key-format | +-- rsa-private-key-format
| +-- ec-private-key-format | +-- ec-private-key-format
| +-- one-asymmetric-key-format | +-- one-asymmetric-key-format
| {one-asymmetric-key-format}? | {one-asymmetric-key-format}?
+-- symmetric-key-format +-- symmetric-key-format
skipping to change at line 282 skipping to change at line 231
| +-- symmetrically-encrypted-value-format | +-- symmetrically-encrypted-value-format
| | | {symmetrically-encrypted-value-format}? | | | {symmetrically-encrypted-value-format}?
| | +-- cms-encrypted-data-format | | +-- cms-encrypted-data-format
| | {cms-encrypted-data-format}? | | {cms-encrypted-data-format}?
| +-- asymmetrically-encrypted-value-format | +-- asymmetrically-encrypted-value-format
| | {asymmetrically-encrypted-value-format}? | | {asymmetrically-encrypted-value-format}?
| +-- cms-enveloped-data-format | +-- cms-enveloped-data-format
| {cms-enveloped-data-format}? | {cms-enveloped-data-format}?
+-- csr-format +-- csr-format
+-- p10-csr-format {p10-csr-format?} +-- p10-csr-format {p10-csr-format?}
]]></artwork> ]]></sourcecode>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
the same as that in <xref target="RFC8340"/>.</t> the same as that in <xref target="RFC8340"/>.</t>
<!--</aside>-->
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The diagram shows that there are five base identities. The <li>The diagram shows that there are five base identities. The
first three identities are used to indicate the format for the first three identities are used to indicate the format for the
key data, while the fourth identity is used to indicate the form at key data, while the fourth identity is used to indicate the form at
for encrypted values. The fifth identity is used to indicate th e for encrypted values. The fifth identity is used to indicate th e
format for a certificate signing request. The base identities a re format for a certificate signing request (CSR). The base identi ties are
"abstract", in the object oriented programming sense, in that "abstract", in the object oriented programming sense, in that
they only define a "class" of formats, rather than a specific they only define a "class" of formats, rather than a specific
format.</li> format.</li>
<li>The various terminal identities define specific encoding <li>The various terminal identities define specific encoding
formats. The derived identities defined in this document are formats. The derived identities defined in this document are
sufficient for the effort described in <xref target="collective- sufficient for the effort described in <xref target="collective-
effort"/> effort"/>,
but, by nature of them being identities, additional derived but by nature of them being identities, additional derived
identities MAY be defined by future efforts.</li> identities <bcp14>MAY</bcp14> be defined by future efforts.</li>
<li>Identities used to specify uncommon formats are enabled by <li>Identities used to specify uncommon formats are enabled by
"feature" statements, allowing applications to support them "feature" statements, allowing applications to support them
when needed.</li> when needed.</li>
</ul> </ul>
</section> </section>
<section anchor="typedefs" toc="exclude"> <section anchor="typedefs" toc="exclude">
<name>Typedefs</name> <name>Typedefs</name>
<t>The following diagram illustrates the relationship amongst the <t>The following diagram illustrates the relationship amongst the
"typedef" statements defined in the "ietf-crypto-types" module:</t > "typedef" statements defined in the "ietf-crypto-types" module:</t >
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Typedefs: Typedefs:
binary binary
+-- csr-info +-- csr-info
+-- csr +-- csr
+-- x509 +-- x509
| +-- trust-anchor-cert-x509 | +-- trust-anchor-cert-x509
| +-- end-entity-cert-x509 | +-- end-entity-cert-x509
+-- crl +-- crl
+-- ocsp-request +-- ocsp-request
+-- ocsp-response +-- ocsp-response
+-- cms +-- cms
+-- data-content-cms +-- data-content-cms
+-- signed-data-cms +-- signed-data-cms
| +-- trust-anchor-cert-cms | +-- trust-anchor-cert-cms
| +-- end-entity-cert-cms | +-- end-entity-cert-cms
+-- enveloped-data-cms +-- enveloped-data-cms
+-- digested-data-cms +-- digested-data-cms
+-- encrypted-data-cms +-- encrypted-data-cms
+-- authenticated-data-cms +-- authenticated-data-cms
]]></artwork> ]]></sourcecode>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not <t>The diagram above uses syntax that is similar to but not
the same as that in <xref target="RFC8340"/>.</t> the same as that in <xref target="RFC8340"/>.</t>
<!--</aside>-->
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>All the typedefs defined in the "ietf-crypto-types" module <li>All the typedefs defined in the "ietf-crypto-types" module
extend the "binary" type defined in <xref target="RFC7950"/>.</l i> extend the "binary" type defined in <xref target="RFC7950"/>.</l i>
<li>Additionally, all the typedefs define a type for encoding an ASN .1 <li>Additionally, all the typedefs define a type for encoding an ASN .1
<xref target="ITU.X680.2021"/> structure using DER <xref target= "ITU.X690.2021"/>.</li> <xref target="ITU.X680.2021"/> structure using DER <xref target= "ITU.X690.2021"/>.</li>
<li>The "trust-anchor-*" and "end-entity-*" typedefs are syntactical ly <li>The "trust-anchor-*" and "end-entity-*" typedefs are syntactical ly
identical to their base typedefs and only distinguish themselves identical to their base typedefs and only distinguish themselves
by the expected nature of their content. These typedefs are by the expected nature of their content. These typedefs are
defined to facilitate common modeling needs.</li> defined to facilitate common modeling needs.</li>
skipping to change at line 370 skipping to change at line 315
<li>end-entity-cert-grouping</li> <li>end-entity-cert-grouping</li>
<li>generate-csr-grouping</li> <li>generate-csr-grouping</li>
<li>asymmetric-key-pair-with-cert-grouping</li> <li>asymmetric-key-pair-with-cert-grouping</li>
<li>asymmetric-key-pair-with-certs-grouping</li> <li>asymmetric-key-pair-with-certs-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-value-grouping"> <section anchor="encrypted-value-grouping">
<name>The "encrypted-value-grouping" Grouping</name> <name>The "encrypted-value-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-value-grouping" grouping:</t> "encrypted-value-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping encrypted-value-grouping: grouping encrypted-value-grouping:
+-- encrypted-by +-- encrypted-by
+-- encrypted-value-format identityref +-- encrypted-value-format identityref
+-- encrypted-value binary +-- encrypted-value binary
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "encrypted-by" node is an empty container (difficult to <li>The "encrypted-by" node is an empty container (difficult to
see in the diagram) that a consuming module MUST augment key see in the diagram) that a consuming module <bcp14>MUST</bcp14 > augment key
references into. The "ietf-crypto-types" module is unable to references into. The "ietf-crypto-types" module is unable to
populate this container as the module only defines groupings. populate this container as the module only defines groupings.
<xref target="ct-usage"/> presents an example illustrating <xref target="ct-usage"/> presents an example illustrating
a consuming module populating the "encrypted-by" container.</l i> a consuming module populating the "encrypted-by" container.</l i>
<li> <li>
<t>The "encrypted-value" node is the value, encrypted by the <t>The "encrypted-value" node is the value encrypted by the
key referenced by the "encrypted-by" node, and encoded in key referenced by the "encrypted-by" node and encoded in
the format appropriate for the kind of key it was encrypted the format appropriate for the kind of key it was encrypted
by.</t> by.</t>
<ul> <ul>
<li>If the value is encrypted by a symmetric key, then the <li>If the value is encrypted by a symmetric key, then the
encrypted value is encoded using the format associated wit h encrypted value is encoded using the format associated wit h
the "symmetrically-encrypted-value-format" identity.</li> the "symmetrically-encrypted-value-format" identity.</li>
<li>If the value is encrypted by an asymmetric key, then the <li>If the value is encrypted by an asymmetric key, then the
encrypted value is encoded using the format associated wit h encrypted value is encoded using the format associated wit h
the "asymmetrically-encrypted-value-format" identity.</li> the "asymmetrically-encrypted-value-format" identity.</li>
</ul> </ul>
<t>See <xref target="identities"/> for information about <t>See <xref target="identities"/> for information about
the "format" identities.</t> the "format" identities.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="password-grouping"> <section anchor="password-grouping">
<name>The "password-grouping" Grouping</name> <name>The "password-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"password-grouping" grouping. This tree diagram does "password-grouping" grouping. This tree diagram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping password-grouping: grouping password-grouping:
+-- (password-type) +-- (password-type)
+--:(cleartext-password) {cleartext-passwords}? +--:(cleartext-password) {cleartext-passwords}?
| +-- cleartext-password? string | +-- cleartext-password? string
+--:(encrypted-password) {encrypted-passwords}? +--:(encrypted-password) {encrypted-passwords}?
+-- encrypted-password +-- encrypted-password
+---u encrypted-value-grouping +---u encrypted-value-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "password-grouping" enables configuration of credentials n <li>The "password-grouping" enables the configuration of credentia
eeded to ls needed to
authenticate to a remote system. The 'ianach:crypt-hash' type authenticate to a remote system. The "ianach:crypt-hash" type
def from def from
<xref target="RFC7317"/> should be used instead when needing t o <xref target="RFC7317"/> should be used instead when needing t o
configure a password to authencate a local account.</li> configure a password to authenticate a local account.</li>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "encrypted-value-grouping" grouping is discussed in <li>The "encrypted-value-grouping" grouping is discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping"/>.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>The "choice" statement enables the password data to be cleart ext or <t>The "choice" statement enables the password data to be cleart ext or
encrypted, as follows: encrypted, as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "cleartext-password" node can encode any cleartext val ue.</li> <li>The "cleartext-password" node can encode any cleartext val ue.</li>
<li>The "encrypted-password" node's structure is discussed in <li>The "encrypted-password" node is an instance of the "encry pted-value-grouping" discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="symmetric-key-grouping"> <section anchor="symmetric-key-grouping">
<name>The "symmetric-key-grouping" Grouping</name> <name>The "symmetric-key-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"symmetric-key-grouping" grouping. This tree diagram does "symmetric-key-grouping" grouping. This tree diagram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping symmetric-key-grouping: grouping symmetric-key-grouping:
+-- key-format? identityref +-- key-format? identityref
+-- (key-type) +-- (key-type)
+--:(cleartext-symmetric-key) +--:(cleartext-symmetric-key)
| +-- cleartext-symmetric-key? binary | +-- cleartext-symmetric-key? binary
| {cleartext-symmetric-keys}? | {cleartext-symmetric-keys}?
+--:(hidden-symmetric-key) {hidden-symmetric-keys}? +--:(hidden-symmetric-key) {hidden-symmetric-keys}?
| +-- hidden-symmetric-key? empty | +-- hidden-symmetric-key? empty
+--:(encrypted-symmetric-key) {encrypted-symmetric-keys}? +--:(encrypted-symmetric-key) {encrypted-symmetric-keys}?
+-- encrypted-symmetric-key +-- encrypted-symmetric-key
+---u encrypted-value-grouping +---u encrypted-value-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "encrypted-value-grouping" grouping is discussed in <li>The "encrypted-value-grouping" grouping is discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping"/>.</li>
</ul> </ul>
</li> </li>
<li>The "key-format" node is an identity-reference to the "symmetr ic-key-format" <li>The "key-format" node is an identity-reference to the "symmetr ic-key-format"
abstract base identity discussed in <xref target="identities"/ >, abstract base identity discussed in <xref target="identities"/ >,
enabling the symmetric key to be encoded using any of the fo rmats enabling the symmetric key to be encoded using any of the fo rmats
defined by the derived identities.</li> defined by the derived identities.</li>
<li> <li>
<t>The "choice" statement enables the private key data to be cle artext, <t>The "choice" statement enables the private key data to be cle artext,
encrypted, or hidden, as follows: encrypted, or hidden, as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "cleartext-symmetric-key" node can encode any cleartex t key value.</li> <li>The "cleartext-symmetric-key" node can encode any cleartex t key value.</li>
<li>The "hidden-symmetric-key" node is of type "empty" as the real <li>The "hidden-symmetric-key" node is of type "empty" as the real
value cannot be presented via the management interface.</l i> value cannot be presented via the management interface.</l i>
<li>The "encrypted-symmetric-key" node's structure is discusse d in <li>The "encrypted-symmetric-key" node's structure is discusse d in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="public-key-grouping"> <section anchor="public-key-grouping">
<name>The "public-key-grouping" Grouping</name> <name>The "public-key-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"public-key-grouping" grouping. This tree diagram does "public-key-grouping" grouping. This tree diagram does
not expand any internally used grouping statement(s):</t> not expand any internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping public-key-grouping: grouping public-key-grouping:
+-- public-key-format identityref +-- public-key-format identityref
+-- public-key binary +-- public-key binary
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>The "public-key-format" node is an identity-reference to the " public-key-format" <li>The "public-key-format" node is an identity-reference to the " public-key-format"
abstract base identity discussed in <xref target="identities"/ >, abstract base identity discussed in <xref target="identities"/ >,
enabling the public key to be encoded using any of the formats enabling the public key to be encoded using any of the formats
defined by the derived identities. </li> defined by the derived identities. </li>
<li>The "public-key" node is the public key data in the selected f ormat. <li>The "public-key" node is the public key data in the selected f ormat.
No "choice" statement is used to hide or encrypt the public ke y data No "choice" statement is used to hide or encrypt the public ke y data
because it is unnecessary to do so for public keys.</li> because it is unnecessary to do so for public keys.</li>
</ul> </ul>
</section> </section>
<section anchor="private-key-grouping"> <section anchor="private-key-grouping">
<name>The "private-key-grouping" Grouping</name> <name>The "private-key-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"private-key-grouping" grouping. This tree diagram does not expa nd the internally "private-key-grouping" grouping. This tree diagram does not expa nd the internally
used grouping statement(s):</t> used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping private-key-grouping: grouping private-key-grouping:
+-- private-key-format? identityref +-- private-key-format? identityref
+-- (private-key-type) +-- (private-key-type)
+--:(cleartext-private-key) {cleartext-private-keys}? +--:(cleartext-private-key) {cleartext-private-keys}?
| +-- cleartext-private-key? binary | +-- cleartext-private-key? binary
+--:(hidden-private-key) {hidden-private-keys}? +--:(hidden-private-key) {hidden-private-keys}?
| +-- hidden-private-key? empty | +-- hidden-private-key? empty
+--:(encrypted-private-key) {encrypted-private-keys}? +--:(encrypted-private-key) {encrypted-private-keys}?
+-- encrypted-private-key +-- encrypted-private-key
+---u encrypted-value-grouping +---u encrypted-value-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "encrypted-value-grouping" grouping is discussed in <li>The "encrypted-value-grouping" grouping is discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping"/>.</li>
</ul> </ul>
</li> </li>
<li>The "private-key-format" node is an identity-reference to the "private-key-format" <li>The "private-key-format" node is an identity-reference to the "private-key-format"
abstract base identity discussed in <xref target="identities "/>, abstract base identity discussed in <xref target="identities "/>,
enabling the private key to be encoded using any of the form ats enabling the private key to be encoded using any of the form ats
defined by the derived identities.</li> defined by the derived identities.</li>
<li> <li>
<t>The "choice" statement enables the private key data to be cle artext, <t>The "choice" statement enables the private key data to be cle artext,
encrypted, or hidden, as follows: encrypted, or hidden, as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "cleartext-private-key" node can encode any cleartext key value.</li> <li>The "cleartext-private-key" node can encode any cleartext key value.</li>
<li>The "hidden-private-key" node is of type "empty" as the re al <li>The "hidden-private-key" node is of type "empty" as the re al
value cannot be presented via the management interface.</l i> value cannot be presented via the management interface.</l i>
<li>The "encrypted-private-key" node's structure is discussed in <li>The "encrypted-private-key" node's structure is discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="asymmetric-key-pair-grouping"> <section anchor="asymmetric-key-pair-grouping">
<name>The "asymmetric-key-pair-grouping" Grouping</name> <name>The "asymmetric-key-pair-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"asymmetric-key-pair-grouping" grouping. This tree diagram does "asymmetric-key-pair-grouping" grouping. This tree diagram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping asymmetric-key-pair-grouping: grouping asymmetric-key-pair-grouping:
+---u public-key-grouping +---u public-key-grouping
+---u private-key-grouping +---u private-key-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "public-key-grouping" grouping is discussed in <li>The "public-key-grouping" grouping is discussed in
<xref target="public-key-grouping"/>.</li> <xref target="public-key-grouping"/>.</li>
<li>The "private-key-grouping" grouping is discussed in <li>The "private-key-grouping" grouping is discussed in
<xref target="private-key-grouping"/>.</li> <xref target="private-key-grouping"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="certificate-expiration-grouping"> <section anchor="certificate-expiration-grouping">
<name>The "certificate-expiration-grouping" Grouping</name> <name>The "certificate-expiration-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"certificate-expiration-grouping" grouping:</t> "certificate-expiration-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping certificate-expiration-grouping: grouping certificate-expiration-grouping:
+---n certificate-expiration +---n certificate-expiration
{certificate-expiration-notification}? {certificate-expiration-notification}?
+-- expiration-date yang:date-and-time +-- expiration-date yang:date-and-time
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>This grouping's only purpose is to define the "certificate-exp iration" <li>This grouping's only purpose is to define the "certificate-exp iration"
notification statement, used by the groupings defined in notification statement, used by the groupings defined in Secti
<xref target="trust-anchor-cert-grouping"/> and ons
<xref target="end-entity-cert-grouping"/>.</li> <xref target="trust-anchor-cert-grouping" format="counter"/> a
nd
<xref target="end-entity-cert-grouping" format="counter"/>.</l
i>
<li>The "certificate-expiration" notification enables servers to <li>The "certificate-expiration" notification enables servers to
notify clients when certificates are nearing expiration.</li> notify clients when certificates are nearing expiration.</li>
<li>The "expiration-date" node indicates when the designated <li>The "expiration-date" node indicates when the designated
certificate will (or did) expire.</li> certificate will (or did) expire.</li>
<li>Identification of the certificate that is expiring is built <li>Identification of the certificate that is expiring is built
into the notification itself. For an example, please see into the notification itself. For an example, please see
<xref target="cert-exp-notif-ex"/>.</li> <xref target="cert-exp-notif-ex"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="trust-anchor-cert-grouping"> <section anchor="trust-anchor-cert-grouping">
<name>The "trust-anchor-cert-grouping" Grouping</name> <name>The "trust-anchor-cert-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"trust-anchor-cert-grouping" grouping. This tree diagram does "trust-anchor-cert-grouping" grouping. This tree diagram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping trust-anchor-cert-grouping: grouping trust-anchor-cert-grouping:
+-- cert-data? trust-anchor-cert-cms +-- cert-data? trust-anchor-cert-cms
+---u certificate-expiration-grouping +---u certificate-expiration-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "certificate-expiration-grouping" grouping is discusse d in <li>The "certificate-expiration-grouping" grouping is discusse d in
<xref target="certificate-expiration-grouping"/>.</li> <xref target="certificate-expiration-grouping"/>.</li>
</ul> </ul>
</li> </li>
<li>The "cert-data" node contains a chain of one or more certifica tes <li>The "cert-data" node contains a chain of one or more certifica tes
containing at most one self-signed certificates (the "root" ce rtificate), containing at most one self-signed certificate (the "root" cer tificate),
encoded using a "signed-data-cms" typedef discussed in <xref t arget="typedefs"/>.</li> encoded using a "signed-data-cms" typedef discussed in <xref t arget="typedefs"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="end-entity-cert-grouping"> <section anchor="end-entity-cert-grouping">
<name>The "end-entity-cert-grouping" Grouping</name> <name>The "end-entity-cert-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"end-entity-cert-grouping" grouping. This tree diagram does "end-entity-cert-grouping" grouping. This tree diagram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping end-entity-cert-grouping: grouping end-entity-cert-grouping:
+-- cert-data? end-entity-cert-cms +-- cert-data? end-entity-cert-cms
+---u certificate-expiration-grouping +---u certificate-expiration-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "certificate-expiration-grouping" grouping is discusse d in <li>The "certificate-expiration-grouping" grouping is discusse d in
<xref target="certificate-expiration-grouping"/>.</li> <xref target="certificate-expiration-grouping"/>.</li>
</ul> </ul>
</li> </li>
<li>The "cert-data" node contains a chain of one or more certifica tes <li>The "cert-data" node contains a chain of one or more certifica tes
containing at most one certificate that is neither self-signed containing at most one certificate that is not self-signed and
nor does not have
having Basic constraint "CA true", encoded using a "signed-dat Basic constraint "CA true" (where "CA" means Certification Aut
a-cms" hority), encoded using a "signed-data-cms"
typedef discussed in <xref target="typedefs"/>.</li> typedef discussed in <xref target="typedefs"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="generate-csr-grouping"> <section anchor="generate-csr-grouping">
<name>The "generate-csr-grouping" Grouping</name> <name>The "generate-csr-grouping" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates t he <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"generate-csr-grouping" grouping:</t> "generate-csr-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping generate-csr-grouping: grouping generate-csr-grouping:
+---x generate-csr {csr-generation}? +---x generate-csr {csr-generation}?
+---w input +---w input
| +---w csr-format identityref | +---w csr-format identityref
| +---w csr-info csr-info | +---w csr-info csr-info
+--ro output +--ro output
+--ro (csr-type) +--ro (csr-type)
+--:(p10-csr) +--:(p10-csr)
+--ro p10-csr? p10-csr +--ro p10-csr? p10-csr
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>This grouping's only purpose is to define the "generate-certif <li>This grouping's only purpose is to define the "generate-csr"
icate-signing-request" action statement, used by the groupings defined in Sections <x
action statement, used by the groupings defined in <xref targe ref target="asymmetric-key-pair-with-cert-grouping" format="counter"/>
t="asymmetric-key-pair-with-cert-grouping"/> and <xref target="asymmetric-key-pair-with-certs-grouping" for
and <xref target="asymmetric-key-pair-with-certs-grouping"/>.< mat="counter"/>.</li>
/li> <li>This action takes two input parameters: a "csr-info" parameter
<li>This action takes as input a "csr-info" type and returns a , for what content should be in the certificate, and a "csr-format" parameter, f
"csr" type, both of which are discussed in <xref target="typed or what CSR format to return. The action returns the CSR in the specified forma
efs"/>.</li> t. Both the "csr-info" and "csr" types are discussed in <xref target="typedefs"
/>.</li>
<li>For an example, please see <xref target="gcsr-action"/>.</li> <li>For an example, please see <xref target="gcsr-action"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="asymmetric-key-pair-with-cert-grouping"> <section anchor="asymmetric-key-pair-with-cert-grouping">
<name>The "asymmetric-key-pair-with-cert-grouping" Grouping</name> <name>The "asymmetric-key-pair-with-cert-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"asymmetric-key-pair-with-cert-grouping" grouping. This tree di agram does "asymmetric-key-pair-with-cert-grouping" grouping. This tree di agram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping asymmetric-key-pair-with-cert-grouping: grouping asymmetric-key-pair-with-cert-grouping:
+---u asymmetric-key-pair-grouping +---u asymmetric-key-pair-grouping
+---u end-entity-cert-grouping +---u end-entity-cert-grouping
+---u generate-csr-grouping +---u generate-csr-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>This grouping defines an asymmetric key with at most one assoc iated <li>This grouping defines an asymmetric key with at most one assoc iated
certificate, a commonly needed combination in protocol models. </li> certificate, a commonly needed combination in protocol models. </li>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "asymmetric-key-pair-grouping" grouping is discussed i n <li>The "asymmetric-key-pair-grouping" grouping is discussed i n
<xref target="asymmetric-key-pair-grouping"/>.</li> <xref target="asymmetric-key-pair-grouping"/>.</li>
<li>The "end-entity-cert-grouping" grouping is discussed in <li>The "end-entity-cert-grouping" grouping is discussed in
<xref target="end-entity-cert-grouping"/>.</li> <xref target="end-entity-cert-grouping"/>.</li>
<li>The "generate-csr-grouping" grouping is discussed in <li>The "generate-csr-grouping" grouping is discussed in
<xref target="generate-csr-grouping"/>.</li> <xref target="generate-csr-grouping"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="asymmetric-key-pair-with-certs-grouping"> <section anchor="asymmetric-key-pair-with-certs-grouping">
<name>The "asymmetric-key-pair-with-certs-grouping" Grouping</name> <name>The "asymmetric-key-pair-with-certs-grouping" Grouping</name>
<t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the <t>This section presents a tree diagram <xref target="RFC8340"/> ill ustrating the
"asymmetric-key-pair-with-certs-grouping" grouping. This tree di agram does "asymmetric-key-pair-with-certs-grouping" grouping. This tree di agram does
not expand the internally used grouping statement(s):</t> not expand the internally used "grouping" statement(s):</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping asymmetric-key-pair-with-certs-grouping: grouping asymmetric-key-pair-with-certs-grouping:
+---u asymmetric-key-pair-grouping +---u asymmetric-key-pair-grouping
+-- certificates +-- certificates
| +-- certificate* [name] | +-- certificate* [name]
| +-- name? string | +-- name string
| +---u end-entity-cert-grouping | +---u end-entity-cert-grouping
+---u generate-csr-grouping +---u generate-csr-grouping
]]></artwork> ]]></sourcecode>
<t>Comments:</t> <t>Comments:</t>
<ul> <ul>
<li>This grouping defines an asymmetric key with one or more <li>This grouping defines an asymmetric key with one or more
associated certificates, a commonly needed combination in associated certificates, a commonly needed combination in
configuration models.</li> configuration models.</li>
<li> <li>
<t>For the referenced grouping statement(s): <t>For the referenced "grouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The "asymmetric-key-pair-grouping" grouping is discussed i n <li>The "asymmetric-key-pair-grouping" grouping is discussed i n
<xref target="asymmetric-key-pair-grouping"/>.</li> <xref target="asymmetric-key-pair-grouping"/>.</li>
<li>The "end-entity-cert-grouping" grouping is discussed in <li>The "end-entity-cert-grouping" grouping is discussed in
<xref target="end-entity-cert-grouping"/>.</li> <xref target="end-entity-cert-grouping"/>.</li>
<li>The "generate-csr-grouping" grouping is discussed in <li>The "generate-csr-grouping" grouping is discussed in
<xref target="generate-csr-grouping"/>.</li> <xref target="generate-csr-grouping"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Protocol-accessible Nodes</name> <name>Protocol-Accessible Nodes</name>
<t>The "ietf-crypto-types" module does not contain any protocol-access ible nodes, <t>The "ietf-crypto-types" module does not contain any protocol-access ible nodes,
but the module needs to be "implemented", as described in <xref se ction="5.6.5" target="RFC7950"/>, in order for the identities in but the module needs to be "implemented", as described in <xref se ction="5.6.5" target="RFC7950"/>, in order for the identities in
<xref target="identities"/> to be defined.</t> <xref target="identities"/> to be defined.</t>
</section> </section>
</section> </section>
<section anchor="crypto-types-examples"> <section anchor="crypto-types-examples">
<name>Example Usage</name> <name>Example Usage</name>
<section anchor="ct-usage" toc="exclude"> <section anchor="ct-usage" toc="exclude">
<name>The "symmetric-key-grouping", "asymmetric-key-pair-w ith-certs-grouping", and "password-grouping" Groupings</name> <name>The "symmetric-key-grouping", "asymmetric-key-pair-w ith-certs-grouping", and "password-grouping" Groupings</name>
<t>The following non-normative module is constructed in order to illus trate the <t>The following non-normative module is constructed in order to illus trate the
use of the "symmetric-key-grouping" (<xref target="symmetric-key-g rouping"/>), the use of the "symmetric-key-grouping" (<xref target="symmetric-key-g rouping"/>), the
"asymmetric-key-pair-with-certs-grouping" (<xref target="asymmetri c-key-pair-with-certs-grouping"/>), "asymmetric-key-pair-with-certs-grouping" (<xref target="asymmetri c-key-pair-with-certs-grouping"/>),
and the "password-grouping" (<xref target="password-grouping"/>) g rouping statements.</t> and the "password-grouping" (<xref target="password-grouping"/>) " grouping" statements.</t>
<t>Notably, this example module and associated configuration data illu strates that <t>Notably, this example module and associated configuration data illu strates that
a hidden private key (ex-hidden-asymmetric-key) a hidden private key (ex-hidden-asymmetric-key)
has been used to encrypt a symmetric key (ex-encrypted-one-symmetr ic-based-symmetric-key) has been used to encrypt a symmetric key (ex-encrypted-one-symmetr ic-based-symmetric-key)
that has been used to encrypt another private key (ex-encrypted-rs a-based-asymmetric-key). that has been used to encrypt another private key (ex-encrypted-rs a-based-asymmetric-key).
Additionally, the symmetric key is also used to encrypt a password (ex-encrypted-password).</t> Additionally, the symmetric key is also used to encrypt a password (ex-encrypted-password).</t>
<section toc="exclude"> <section toc="exclude">
<name>Example Module</name> <name>Example Module</name>
<artwork><![CDATA[ <sourcecode type="yang"><![CDATA[
module ex-crypto-types-usage { module ex-crypto-types-usage {
yang-version 1.1; yang-version 1.1;
namespace "https://example.com/ns/example-crypto-types-usage"; namespace "https://example.com/ns/example-crypto-types-usage";
prefix ectu; prefix ectu;
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
"Example Corporation"; "Example Corporation";
contact contact
"YANG Designer <mailto:yang.designer@example.com>"; "YANG Designer <mailto:yang.designer@example.com>";
description description
"This example module illustrates the 'symmetric-key-grouping' "This example module illustrates the 'symmetric-key-grouping'
and 'asymmetric-key-grouping' groupings defined in the and 'asymmetric-key-grouping' groupings defined in the
'ietf-crypto-types' module defined in RFC AAAA."; 'ietf-crypto-types' module defined in RFC 9640.";
revision 2024-03-16 { revision 2024-03-16 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC AAAA: Common YANG Data Types for Cryptography"; "RFC 9640: YANG Data Types and Groupings for Cryptography";
} }
container symmetric-keys { container symmetric-keys {
description description
"A container of symmetric keys."; "A container of symmetric keys.";
list symmetric-key { list symmetric-key {
key "name"; key "name";
description description
"A symmetric key"; "A symmetric key.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for this key."; "An arbitrary name for this key.";
} }
uses ct:symmetric-key-grouping { uses ct:symmetric-key-grouping {
augment "key-type/encrypted-symmetric-key/" augment "key-type/encrypted-symmetric-key/"
+ "encrypted-symmetric-key/encrypted-by" { + "encrypted-symmetric-key/encrypted-by" {
description description
"Augments in a choice statement enabling the "Augments in a 'choice' statement enabling the
encrypting key to be any other symmetric or encrypting key to be any other symmetric or
asymmetric key."; asymmetric key.";
uses encrypted-by-grouping; uses encrypted-by-grouping;
} }
} }
} }
} }
container asymmetric-keys { container asymmetric-keys {
description description
"A container of asymmetric keys."; "A container of asymmetric keys.";
skipping to change at line 831 skipping to change at line 775
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 ct:asymmetric-key-pair-with-certs-grouping { uses ct:asymmetric-key-pair-with-certs-grouping {
augment "private-key-type/encrypted-private-key/" augment "private-key-type/encrypted-private-key/"
+ "encrypted-private-key/encrypted-by" { + "encrypted-private-key/encrypted-by" {
description description
"Augments in a choice statement enabling the "Augments in a 'choice' statement enabling the
encrypting key to be any other symmetric or encrypting key to be any other symmetric or
asymmetric key."; asymmetric key.";
uses encrypted-by-grouping; uses encrypted-by-grouping;
} }
} }
description description
"An asymmetric key pair with associated certificates."; "An asymmetric key pair with associated certificates.";
} }
} }
container passwords { container passwords {
skipping to change at line 855 skipping to change at line 799
key "name"; key "name";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for this password."; "An arbitrary name for this password.";
} }
uses ct:password-grouping { uses ct:password-grouping {
augment "password-type/encrypted-password/" augment "password-type/encrypted-password/"
+ "encrypted-password/encrypted-by" { + "encrypted-password/encrypted-by" {
description description
"Augments in a choice statement enabling the "Augments in a 'choice' statement enabling the
encrypting key to be any symmetric or encrypting key to be any symmetric or
asymmetric key."; asymmetric key.";
uses encrypted-by-grouping; uses encrypted-by-grouping;
} }
} }
description description
"A password."; "A password.";
} }
} }
skipping to change at line 897 skipping to change at line 841
path "/ectu:asymmetric-keys/ectu:asymmetric-key/" path "/ectu:asymmetric-keys/ectu:asymmetric-key/"
+ "ectu:name"; + "ectu:name";
} }
description description
"Identifies the asymmetric key that encrypts this key."; "Identifies the asymmetric key that encrypts this key.";
} }
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Tree Diagram for the Example Module</name> <name>Tree Diagram for the Example Module</name>
<t>The tree diagram <xref target="RFC8340"/> for this example module <t>The tree diagram <xref target="RFC8340"/> for this example module
follows:</t> is as follows:</t>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ex-crypto-types-usage module: ex-crypto-types-usage
+--rw symmetric-keys +--rw symmetric-keys
| +--rw symmetric-key* [name] | +--rw symmetric-key* [name]
| +--rw name string | +--rw name string
| +--rw key-format? identityref | +--rw key-format? identityref
| +--rw (key-type) | +--rw (key-type)
| +--:(cleartext-symmetric-key) | +--:(cleartext-symmetric-key)
| | +--rw cleartext-symmetric-key? binary | | +--rw cleartext-symmetric-key? binary
| | {cleartext-symmetric-keys}? | | {cleartext-symmetric-keys}?
| +--:(hidden-symmetric-key) {hidden-symmetric-keys}? | +--:(hidden-symmetric-key) {hidden-symmetric-keys}?
skipping to change at line 976 skipping to change at line 920
+--:(encrypted-password) {encrypted-passwords}? +--:(encrypted-password) {encrypted-passwords}?
+--rw encrypted-password +--rw encrypted-password
+--rw encrypted-by +--rw encrypted-by
| +--rw (encrypted-by) | +--rw (encrypted-by)
| +--:(symmetric-key-ref) | +--:(symmetric-key-ref)
| | +--rw symmetric-key-ref? leafref | | +--rw symmetric-key-ref? leafref
| +--:(asymmetric-key-ref) | +--:(asymmetric-key-ref)
| +--rw asymmetric-key-ref? leafref | +--rw asymmetric-key-ref? leafref
+--rw encrypted-value-format identityref +--rw encrypted-value-format identityref
+--rw encrypted-value binary +--rw encrypted-value binary
]]></artwork> ]]></sourcecode>
</section> </section>
<section toc="exclude"> <section toc="exclude">
<name>Usage Example for the Example Module</name> <name>Usage Example for the Example Module</name>
<t>Finally, the following example illustrates various symmetric and asymmetric keys <t>Finally, the following example illustrates various symmetric and asymmetric keys
as they might appear in configuration:</t> as they might appear in configuration.</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<symmetric-keys <symmetric-keys
xmlns="https://example.com/ns/example-crypto-types-usage" xmlns="https://example.com/ns/example-crypto-types-usage"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<symmetric-key> <symmetric-key>
<name>ex-hidden-symmetric-key</name> <name>ex-hidden-symmetric-key</name>
<hidden-symmetric-key/> <hidden-symmetric-key/>
</symmetric-key> </symmetric-key>
<symmetric-key> <symmetric-key>
skipping to change at line 1096 skipping to change at line 1040
<encrypted-by> <encrypted-by>
<symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ <symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\
c-key</symmetric-key-ref> c-key</symmetric-key-ref>
</encrypted-by> </encrypted-by>
<encrypted-value-format>ct:cms-encrypted-data-format</encrypte\ <encrypted-value-format>ct:cms-encrypted-data-format</encrypte\
d-value-format> d-value-format>
<encrypted-value>BASE64VALUE=</encrypted-value> <encrypted-value>BASE64VALUE=</encrypted-value>
</encrypted-password> </encrypted-password>
</password> </password>
</passwords> </passwords>
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="gcsr-action" toc="exclude"> <section anchor="gcsr-action" toc="exclude">
<name>The "generate-certificate-signing-request" Action</name> <name>The "generate-csr" Action</name>
<t>The following example illustrates the "generate-certificate-signing <t>The following example illustrates the "generate-csr"
-request" action, discussed in <xref target="generate-csr-grouping"/>, with the
action, discussed in <xref target="generate-csr-grouping"/>, with NETCONF protocol.</t>
the NETCONF protocol.</t>
<t keepWithNext="true">REQUEST</t> <t keepWithNext="true">REQUEST</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"> xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
<action xmlns="urn:ietf:params:xml:ns:yang:1"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<asymmetric-keys <asymmetric-keys
xmlns="https://example.com/ns/example-crypto-types-usage"> xmlns="https://example.com/ns/example-crypto-types-usage">
<asymmetric-key> <asymmetric-key>
<name>ex-hidden-asymmetric-key</name> <name>ex-hidden-asymmetric-key</name>
<generate-csr> <generate-csr>
<csr-format>ct:p10-csr-format</csr-format> <csr-format>ct:p10-csr-format</csr-format>
<csr-info>BASE64VALUE=</csr-info> <csr-info>BASE64VALUE=</csr-info>
</generate-csr> </generate-csr>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</action> </action>
</rpc> </rpc>
]]></artwork> ]]></sourcecode>
<t keepWithNext="true">RESPONSE</t> <t keepWithNext="true">RESPONSE</t>
<artwork><![CDATA[ <sourcecode type="xml"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\ <p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\
>BASE64VALUE=</p10-csr> >BASE64VALUE=</p10-csr>
</rpc-reply> </rpc-reply>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="cert-exp-notif-ex" toc="exclude"> <section anchor="cert-exp-notif-ex" toc="exclude">
<name>The "certificate-expiration" Notification</name> <name>The "certificate-expiration" Notification</name>
<t>The following example illustrates the "certificate-expiration" <t>The following example illustrates the "certificate-expiration"
notification, discussed in <xref target="certificate-expiration-gr ouping"/>, notification, discussed in <xref target="certificate-expiration-gr ouping"/>,
with the NETCONF protocol.</t> with the NETCONF protocol.</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>
<asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\ <asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\
s-usage"> s-usage">
<asymmetric-key> <asymmetric-key>
<name>ex-hidden-asymmetric-key</name> <name>ex-hidden-asymmetric-key</name>
<certificates> <certificates>
skipping to change at line 1160 skipping to change at line 1104
<name>ex-hidden-asymmetric-key-cert</name> <name>ex-hidden-asymmetric-key-cert</name>
<certificate-expiration> <certificate-expiration>
<expiration-date>2018-08-05T14:18:53-05:00</expiration-d\ <expiration-date>2018-08-05T14:18:53-05:00</expiration-d\
ate> ate>
</certificate-expiration> </certificate-expiration>
</certificate> </certificate>
</certificates> </certificates>
</asymmetric-key> </asymmetric-key>
</asymmetric-keys> </asymmetric-keys>
</notification> </notification>
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="crypto-types-yang-module"> <section anchor="crypto-types-yang-module">
<name>YANG Module</name> <name>YANG Module</name>
<t>This module has normative references to <xref target="RFC2119"/>, <t>This module has normative references to <xref target="RFC2119"/>,
<xref target="RFC2986"/>, <xref target="RFC4253"/>, <xref target="RFC5 280"/>, <xref target="RFC2986"/>, <xref target="RFC4253"/>, <xref target="RFC5 280"/>,
<xref target="RFC5652"/>, <xref target="RFC5915"/>, <xref target="RFC5 958"/>, <xref target="RFC5652"/>, <xref target="RFC5915"/>, <xref target="RFC5 958"/>,
<xref target="RFC6031"/>, <xref target="RFC6960"/>, <xref target="RFC6031"/>, <xref target="RFC6960"/>,
<xref target="RFC6991"/>, <xref target="RFC7093"/>, <xref target="RFC8 017"/>, <xref target="RFC6991"/>, <xref target="RFC7093"/>, <xref target="RFC8 017"/>,
<xref target="RFC8174"/>, <xref target="RFC8341"/>, <xref target="RFC8174"/>, <xref target="RFC8341"/>,
and <xref target="ITU.X690.2021"/>.</t> and <xref target="ITU.X690.2021"/>.</t>
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-crypto-types@2024- <sourcecode name="ietf-crypto-types@2024-03-16.yang" type="yang" markers
03-16.yang"</t> ="true"><![CDATA[
<artwork><![CDATA[
module ietf-crypto-types { module ietf-crypto-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-crypto-types";
prefix ct; prefix ct;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
skipping to change at line 1203 skipping to change at line 1146
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 common YANG types for cryptographic "This module defines common YANG types for cryptographic
applications. applications.
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 AAAA This version of this YANG module is part of RFC 9640
(https://www.rfc-editor.org/info/rfcAAAA); see the RFC (https://www.rfc-editor.org/info/rfc9640); 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 AAAA: YANG Data Types and Groupings for Cryptography"; "RFC 9640: YANG Data Types and Groupings for Cryptography";
} }
/****************/ /****************/
/* Features */ /* Features */
/****************/ /****************/
feature one-symmetric-key-format { feature one-symmetric-key-format {
description description
"Indicates that the server supports the "Indicates that the server supports the
'one-symmetric-key-format' identity."; 'one-symmetric-key-format' identity.";
skipping to change at line 1376 skipping to change at line 1319
an RSAPrivateKey (from RFC 8017), encoded using ASN.1 an RSAPrivateKey (from RFC 8017), encoded using ASN.1
distinguished encoding rules (DER), as specified in distinguished encoding rules (DER), as specified in
ITU-T X.690."; ITU-T X.690.";
reference reference
"RFC 8017: "RFC 8017:
PKCS #1: RSA Cryptography Specifications Version 2.2 PKCS #1: RSA Cryptography Specifications Version 2.2
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
identity ec-private-key-format { identity ec-private-key-format {
base private-key-format; base private-key-format;
description description
"Indicates that the private key value is encoded as "Indicates that the private key value is encoded as
an ECPrivateKey (from RFC 5915), encoded using ASN.1 an ECPrivateKey (from RFC 5915), encoded using ASN.1
distinguished encoding rules (DER), as specified in distinguished encoding rules (DER), as specified in
ITU-T X.690."; ITU-T X.690.";
reference reference
"RFC 5915: "RFC 5915:
Elliptic Curve Private Key Structure Elliptic Curve Private Key Structure
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
identity one-asymmetric-key-format { identity one-asymmetric-key-format {
if-feature "one-asymmetric-key-format"; if-feature "one-asymmetric-key-format";
base private-key-format; base private-key-format;
description description
"Indicates that the private key value is a CMS "Indicates that the private key value is a
OneAsymmetricKey structure, as defined in RFC 5958, Cryptographic Message Syntax (CMS) OneAsymmetricKey
encoded using ASN.1 distinguished encoding rules structure, as defined in RFC 5958, encoded using
(DER), as specified in ITU-T X.690."; ASN.1 distinguished encoding rules (DER), as
specified in ITU-T X.690.";
reference reference
"RFC 5958: Asymmetric Key Packages "RFC 5958:
Asymmetric Key Packages
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/***************************************************/ /***************************************************/
/* Identities for Public Key Format Structures */ /* Identities for Public Key Format Structures */
/***************************************************/ /***************************************************/
identity ssh-public-key-format { identity ssh-public-key-format {
base public-key-format; base public-key-format;
description description
"Indicates that the public key value is an SSH public key, "Indicates that the public key value is a Secure Shell (SSH)
as specified by RFC 4253, Section 6.6, i.e.: public key, as specified in RFC 4253, Section 6.6, i.e.:
string certificate or public key format string certificate or public key format
identifier identifier
byte[n] key/certificate data."; byte[n] key/certificate data.";
reference reference
"RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol";
} }
identity subject-public-key-info-format { identity subject-public-key-info-format {
base public-key-format; base public-key-format;
description description
"Indicates that the public key value is a SubjectPublicKeyInfo "Indicates that the public key value is a SubjectPublicKeyInfo
structure, as described in RFC 5280 encoded using ASN.1 structure, as described in RFC 5280, encoded using ASN.1
distinguished encoding rules (DER), as specified in distinguished encoding rules (DER), as specified in
ITU-T X.690."; ITU-T X.690.";
reference reference
"RFC 5280: "RFC 5280:
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile and Certificate Revocation List (CRL) Profile
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/******************************************************/ /******************************************************/
/* Identities for Symmetric Key Format Structures */ /* Identities for Symmetric Key Format Structures */
/******************************************************/ /******************************************************/
identity octet-string-key-format { identity octet-string-key-format {
base symmetric-key-format; base symmetric-key-format;
description description
"Indicates that the key is encoded as a raw octet string. "Indicates that the key is encoded as a raw octet string.
The length of the octet string MUST be appropriate for The length of the octet string MUST be appropriate for
the associated algorithm's block size. the associated algorithm's block size.
The identity of the associated algorithm is outside the The identity of the associated algorithm is outside the
scope of this specification. This is also true when scope of this specification. This is also true when
the octet string has been encrypted."; the octet string has been encrypted.";
} }
identity one-symmetric-key-format { identity one-symmetric-key-format {
if-feature "one-symmetric-key-format"; if-feature "one-symmetric-key-format";
base symmetric-key-format; base symmetric-key-format;
description description
"Indicates that the private key value is a CMS "Indicates that the private key value is a CMS
OneSymmetricKey structure, as defined in RFC 6031, OneSymmetricKey structure, as defined in RFC 6031,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 distinguished encoding rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 6031: Cryptographic Message Syntax (CMS) "RFC 6031:
Symmetric Key Package Content Type Cryptographic Message Syntax (CMS)
Symmetric Key Package Content Type
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/*************************************************/ /*************************************************/
/* Identities for Encrypted Value Structures */ /* Identities for Encrypted Value Structures */
/*************************************************/ /*************************************************/
identity encrypted-value-format { identity encrypted-value-format {
description description
"Base format identity for encrypted values."; "Base format identity for encrypted values.";
} }
skipping to change at line 1515 skipping to change at line 1461
} }
identity cms-encrypted-data-format { identity cms-encrypted-data-format {
if-feature "cms-encrypted-data-format"; if-feature "cms-encrypted-data-format";
base symmetrically-encrypted-value-format; base symmetrically-encrypted-value-format;
description description
"Indicates that the encrypted value conforms to "Indicates that the encrypted value conforms to
the 'encrypted-data-cms' type with the constraint the 'encrypted-data-cms' type with the constraint
that the 'unprotectedAttrs' value is not set."; that the 'unprotectedAttrs' value is not set.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS) "RFC 5652:
Cryptographic Message Syntax (CMS)
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
identity cms-enveloped-data-format { identity cms-enveloped-data-format {
if-feature "cms-enveloped-data-format"; if-feature "cms-enveloped-data-format";
base asymmetrically-encrypted-value-format; base asymmetrically-encrypted-value-format;
description description
"Indicates that the encrypted value conforms to the "Indicates that the encrypted value conforms to the
'enveloped-data-cms' type with the following constraints: 'enveloped-data-cms' type with the following constraints:
The EnvelopedData structure MUST have exactly one The EnvelopedData structure MUST have exactly one
'RecipientInfo'. 'RecipientInfo'.
If the asymmetric key supports public key cryptography If the asymmetric key supports public key cryptography
(e.g., RSA), then the 'RecipientInfo' must be a (e.g., RSA), then the 'RecipientInfo' must be a
'KeyTransRecipientInfo' with the 'RecipientIdentifier' 'KeyTransRecipientInfo' with the 'RecipientIdentifier'
using a 'subjectKeyIdentifier' with the value set using using a 'subjectKeyIdentifier' with the value set using
'method 1' in RFC 7093 over the recipient's public key. 'method 1' in RFC 7093 over the recipient's public key.
Otherwise, if the asymmetric key supports key agreement Otherwise, if the asymmetric key supports key agreement
(e.g., ECC), then the 'RecipientInfo' must be a (e.g., Elliptic Curve Cryptography (ECC)), then the
'KeyAgreeRecipientInfo'. The 'OriginatorIdentifierOrKey' 'RecipientInfo' must be a 'KeyAgreeRecipientInfo'. The
value must use the 'OriginatorPublicKey' alternative. 'OriginatorIdentifierOrKey' value must use the
The 'UserKeyingMaterial' value must not be present. 'OriginatorPublicKey' alternative. The
There must be exactly one 'RecipientEncryptedKeys' value 'UserKeyingMaterial' value must not be present. There
must be exactly one 'RecipientEncryptedKeys' value
having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId' having the 'KeyAgreeRecipientIdentifier' set to 'rKeyId'
with the value set using 'method 1' in RFC 7093 over the with the value set using 'method 1' in RFC 7093 over the
recipient's public key."; recipient's public key.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS) "RFC 5652:
Cryptographic Message Syntax (CMS)
RFC 7093: RFC 7093:
Additional Methods for Generating Key Additional Methods for Generating Key
Identifiers Values Identifiers Values
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/*********************************************************/ /*********************************************************/
/* Identities for Certificate Signing Request Formats */ /* Identities for Certificate Signing Request Formats */
/*********************************************************/ /*********************************************************/
identity csr-format { identity csr-format {
description description
"A base identity for the certificate signing request "A base identity for the certificate signing request
formats. Additional derived identities MAY be defined formats. Additional derived identities MAY be defined
by future efforts."; by future efforts.";
} }
identity p10-csr-format { identity p10-csr-format {
if-feature "p10-csr-format"; if-feature "p10-csr-format";
base csr-format; base csr-format;
description description
"Indicates the 'CertificationRequest' structure "Indicates the CertificationRequest structure
defined in RFC 2986."; defined in RFC 2986.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7"; Specification Version 1.7";
} }
/***************************************************/ /***************************************************/
/* Typedefs for ASN.1 structures from RFC 2986 */ /* Typedefs for ASN.1 structures from RFC 2986 */
/***************************************************/ /***************************************************/
typedef csr-info { typedef csr-info {
type binary; type binary;
description description
"A CertificationRequestInfo structure, as defined in "A CertificationRequestInfo structure, as defined in
RFC 2986, encoded using ASN.1 distinguished encoding RFC 2986, encoded using ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690."; rules (DER), as specified in ITU-T X.690.";
reference reference
"RFC 2986: PKCS #10: Certification Request Syntax "RFC 2986:
Specification Version 1.7 PKCS #10: Certification Request Syntax
Specification Version 1.7
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
typedef p10-csr { typedef p10-csr {
type binary; type binary;
description description
"A CertificationRequest structure, as specified in "A CertificationRequest structure, as specified in
RFC 2986, encoded using ASN.1 distinguished encoding RFC 2986, encoded using ASN.1 distinguished encoding
rules (DER), as specified in ITU-T X.690."; rules (DER), as specified in ITU-T X.690.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax Specification PKCS #10: Certification Request Syntax Specification
Version 1.7 Version 1.7
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/***************************************************/ /***************************************************/
/* Typedefs for ASN.1 structures from RFC 5280 */ /* Typedefs for ASN.1 structures from RFC 5280 */
/***************************************************/ /***************************************************/
typedef x509 { typedef x509 {
type binary; type binary;
description description
"A Certificate structure, as specified in RFC 5280, "A Certificate structure, as specified in RFC 5280,
encoded using ASN.1 distinguished encoding rules (DER), encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690."; as specified in ITU-T X.690.";
reference reference
"RFC 5280: "RFC 5280:
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile and Certificate Revocation List (CRL) Profile
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
typedef crl { typedef crl {
type binary; type binary;
description description
"A CertificateList structure, as specified in RFC 5280, "A CertificateList structure, as specified in RFC 5280,
encoded using ASN.1 distinguished encoding rules (DER), encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690."; as specified in ITU-T X.690.";
reference reference
"RFC 5280: "RFC 5280:
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile and Certificate Revocation List (CRL) Profile
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/***************************************************/ /***************************************************/
/* Typedefs for ASN.1 structures from RFC 6960 */ /* Typedefs for ASN.1 structures from RFC 6960 */
/***************************************************/ /***************************************************/
typedef oscp-request { typedef oscp-request {
type binary; type binary;
description description
"A OCSPRequest structure, as specified in RFC 6960, "A OCSPRequest structure, as specified in RFC 6960,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 distinguished encoding rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 6960: "RFC 6960:
X.509 Internet Public Key Infrastructure Online X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP Certificate Status Protocol - OCSP
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
typedef oscp-response { typedef oscp-response {
type binary; type binary;
description description
"A OCSPResponse structure, as specified in RFC 6960, "A OCSPResponse structure, as specified in RFC 6960,
encoded using ASN.1 distinguished encoding rules encoded using ASN.1 distinguished encoding rules
(DER), as specified in ITU-T X.690."; (DER), as specified in ITU-T X.690.";
reference reference
"RFC 6960: "RFC 6960:
X.509 Internet Public Key Infrastructure Online X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP Certificate Status Protocol - OCSP
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
/***********************************************/ /***********************************************/
/* Typedefs for ASN.1 structures from 5652 */ /* Typedefs for ASN.1 structures from 5652 */
/***********************************************/ /***********************************************/
typedef cms { typedef cms {
type binary; type binary;
description description
"A ContentInfo structure, as specified in RFC 5652, "A ContentInfo structure, as specified in RFC 5652,
encoded using ASN.1 distinguished encoding rules (DER), encoded using ASN.1 distinguished encoding rules (DER),
as specified in ITU-T X.690."; as specified in ITU-T X.690.";
reference reference
"RFC 5652: "RFC 5652:
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
ITU-T X.690: ITU-T X.690:
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) 02/2021."; Encoding Rules (DER) 02/2021";
} }
typedef data-content-cms { typedef data-content-cms {
type cms; type cms;
description description
"A CMS structure whose top-most content type MUST be the "A CMS structure whose top-most content type MUST be the
data content type, as described by Section 4 in RFC 5652."; data content type, as described in Section 4 of RFC 5652.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 5652: Cryptographic Message Syntax (CMS)";
} }
typedef signed-data-cms { typedef signed-data-cms {
type cms; type cms;
description description
"A CMS structure whose top-most content type MUST be the "A CMS structure whose top-most content type MUST be the
signed-data content type, as described by Section 5 in signed-data content type, as described in Section 5 of
RFC 5652."; RFC 5652.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 5652: Cryptographic Message Syntax (CMS)";
} }
typedef enveloped-data-cms { typedef enveloped-data-cms {
type cms; type cms;
description description
"A CMS structure whose top-most content type MUST be the "A CMS structure whose top-most content type MUST be the
enveloped-data content type, as described by Section 6 enveloped-data content type, as described in Section 6
in RFC 5652."; of RFC 5652.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 5652: Cryptographic Message Syntax (CMS)";
} }
typedef digested-data-cms { typedef digested-data-cms {
type cms; type cms;
description description
"A CMS structure whose top-most content type MUST be the "A CMS structure whose top-most content type MUST be the
digested-data content type, as described by Section 7 digested-data content type, as described in Section 7
in RFC 5652."; of RFC 5652.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 5652: Cryptographic Message Syntax (CMS)";
} }
typedef encrypted-data-cms { typedef encrypted-data-cms {
type cms; type cms;
description description
"A CMS structure whose top-most content type MUST be the "A CMS structure whose top-most content type MUST be the
encrypted-data content type, as described by Section 8 encrypted-data content type, as described in Section 8
in RFC 5652."; of RFC 5652.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 5652: Cryptographic Message Syntax (CMS)";
} }
typedef authenticated-data-cms { typedef authenticated-data-cms {
type cms; type cms;
description description
"A CMS structure whose top-most content type MUST be the "A CMS structure whose top-most content type MUST be the
authenticated-data content type, as described by Section 9 authenticated-data content type, as described in Section 9
in RFC 5652."; of RFC 5652.";
reference reference
"RFC 5652: Cryptographic Message Syntax (CMS)"; "RFC 5652: Cryptographic Message Syntax (CMS)";
} }
/*********************************************************/ /*********************************************************/
/* Typedefs for ASN.1 structures related to RFC 5280 */ /* Typedefs for ASN.1 structures related to RFC 5280 */
/*********************************************************/ /*********************************************************/
typedef trust-anchor-cert-x509 { typedef trust-anchor-cert-x509 {
type x509; type x509;
description description
"A Certificate structure that MUST encode a self-signed "A Certificate structure that MUST encode a self-signed
root certificate."; root certificate.";
} }
typedef end-entity-cert-x509 { typedef end-entity-cert-x509 {
type x509; type x509;
description description
"A Certificate structure that MUST encode a certificate "A Certificate structure that MUST encode a certificate
that is neither self-signed nor having Basic constraint that is neither self-signed nor has Basic constraint
CA true."; CA true.";
} }
/*********************************************************/ /*********************************************************/
/* Typedefs for ASN.1 structures related to RFC 5652 */ /* Typedefs for ASN.1 structures related to RFC 5652 */
/*********************************************************/ /*********************************************************/
typedef trust-anchor-cert-cms { typedef trust-anchor-cert-cms {
type signed-data-cms; type signed-data-cms;
description description
"A CMS SignedData structure that MUST contain the chain of "A CMS SignedData structure that MUST contain the chain of
X.509 certificates needed to authenticate the certificate X.509 certificates needed to authenticate the certificate
presented by a client or end-entity. presented by a client or end entity.
The CMS MUST contain only a single chain of certificates. The CMS MUST contain only a single chain of certificates.
The client or end-entity certificate MUST only authenticate The client or end-entity certificate MUST only authenticate
to the last intermediate CA certificate listed in the chain. to the last intermediate CA certificate listed in the chain.
In all cases, the chain MUST include a self-signed root In all cases, the chain MUST include a self-signed root
certificate. In the case where the root certificate is certificate. In the case where the root certificate is
itself the issuer of the client or end-entity certificate, itself the issuer of the client or end-entity certificate,
only one certificate is present. only one certificate is present.
skipping to change at line 1825 skipping to change at line 1775
policy) revocation objects with which the device can policy) revocation objects with which the device can
verify the revocation status of the certificates. verify the revocation status of the certificates.
This CMS encodes the degenerate form of the SignedData This CMS encodes the degenerate form of the SignedData
structure (RFC 5652, Section 5.2) that is commonly used structure (RFC 5652, Section 5.2) that is commonly used
to disseminate X.509 certificates and revocation objects to disseminate X.509 certificates and revocation objects
(RFC 5280)."; (RFC 5280).";
reference reference
"RFC 5280: "RFC 5280:
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile. and Certificate Revocation List (CRL) Profile
RFC 5652: RFC 5652:
Cryptographic Message Syntax (CMS)"; Cryptographic Message Syntax (CMS)";
} }
typedef end-entity-cert-cms { typedef end-entity-cert-cms {
type signed-data-cms; type signed-data-cms;
description description
"A CMS SignedData structure that MUST contain the end "A CMS SignedData structure that MUST contain the end-entity
entity certificate itself, and MAY contain any number certificate itself and MAY contain any number
of intermediate certificates leading up to a trust of intermediate certificates leading up to a trust
anchor certificate. The trust anchor certificate anchor certificate. The trust anchor certificate
MAY be included as well. MAY be included as well.
The CMS MUST contain a single end entity certificate. The CMS MUST contain a single end-entity certificate.
The CMS MUST NOT contain any spurious certificates. The CMS MUST NOT contain any spurious certificates.
This CMS structure MAY (as applicable where this type is This CMS structure MAY (as applicable where this type is
used) also contain suitably fresh (as defined by local used) also contain suitably fresh (as defined by local
policy) revocation objects with which the device can policy) revocation objects with which the device can
verify the revocation status of the certificates. verify the revocation status of the certificates.
This CMS encodes the degenerate form of the SignedData This CMS encodes the degenerate form of the SignedData
structure (RFC 5652, Section 5.2) that is commonly structure (RFC 5652, Section 5.2) that is commonly
used to disseminate X.509 certificates and revocation used to disseminate X.509 certificates and revocation
objects (RFC 5280)."; objects (RFC 5280).";
reference reference
"RFC 5280: "RFC 5280:
Internet X.509 Public Key Infrastructure Certificate Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile. and Certificate Revocation List (CRL) Profile
RFC 5652: RFC 5652:
Cryptographic Message Syntax (CMS)"; Cryptographic Message Syntax (CMS)";
} }
/*****************/ /*****************/
/* Groupings */ /* Groupings */
/*****************/ /*****************/
grouping encrypted-value-grouping { grouping encrypted-value-grouping {
description description
skipping to change at line 1879 skipping to change at line 1829
nacm:default-deny-write; nacm:default-deny-write;
description description
"An empty container enabling a reference to the key that "An empty container enabling a reference to the key that
encrypted the value to be augmented in. The referenced encrypted the value to be augmented in. The referenced
key MUST be a symmetric key or an asymmetric key. key MUST be a symmetric key or an asymmetric key.
A symmetric key MUST be referenced via a leaf node called A symmetric key MUST be referenced via a leaf node called
'symmetric-key-ref'. An asymmetric key MUST be referenced 'symmetric-key-ref'. An asymmetric key MUST be referenced
via a leaf node called 'asymmetric-key-ref'. via a leaf node called 'asymmetric-key-ref'.
The leaf nodes MUST be direct descendants in the data tree, The leaf nodes MUST be direct descendants in the data tree
and MAY be direct descendants in the schema tree (e.g., and MAY be direct descendants in the schema tree (e.g.,
choice/case statements are allowed, but not a container)."; 'choice'/'case' statements are allowed but not a
container).";
} }
leaf encrypted-value-format { leaf encrypted-value-format {
type identityref { type identityref {
base encrypted-value-format; base encrypted-value-format;
} }
mandatory true; mandatory true;
description description
"Identifies the format of the 'encrypted-value' leaf. "Identifies the format of the 'encrypted-value' leaf.
If 'encrypted-by' points to a symmetric key, then a If 'encrypted-by' points to a symmetric key, then an
'symmetrically-encrypted-value-format' based identity identity based on 'symmetrically-encrypted-value-format'
MUST be set (e.g., cms-encrypted-data-format). MUST be set (e.g., 'cms-encrypted-data-format').
If 'encrypted-by' points to an asymmetric key, then an If 'encrypted-by' points to an asymmetric key, then an
'asymmetrically-encrypted-value-format' based identity identity based on 'asymmetrically-encrypted-value-format'
MUST be set (e.g., cms-enveloped-data-format)."; MUST be set (e.g., 'cms-enveloped-data-format').";
} }
leaf encrypted-value { leaf encrypted-value {
nacm:default-deny-write; nacm:default-deny-write;
type binary; type binary;
must '../encrypted-by'; must '../encrypted-by';
mandatory true; mandatory true;
description description
"The value, encrypted using the referenced symmetric "The value, encrypted using the referenced symmetric
or asymmetric key. The value MUST be encoded using or asymmetric key. The value MUST be encoded using
the format associated with the 'encrypted-value-format' the format associated with the 'encrypted-value-format'
leaf."; leaf.";
} }
} }
grouping password-grouping { grouping password-grouping {
description description
"A password used for authenticating to a remote system. "A password used for authenticating to a remote system.
The 'ianach:crypt-hash' typedef from RFC 7317 should be The 'ianach:crypt-hash' typedef from RFC 7317 should be
used instead when needing a password to authencate a used instead when needing a password to authenticate a
local account."; local account.";
choice password-type { choice password-type {
nacm:default-deny-write; nacm:default-deny-write;
mandatory true; mandatory true;
description description
"Choice between password types."; "Choice between password types.";
case cleartext-password { case cleartext-password {
if-feature "cleartext-passwords"; if-feature "cleartext-passwords";
leaf cleartext-password { leaf cleartext-password {
nacm:default-deny-all; nacm:default-deny-all;
skipping to change at line 1959 skipping to change at line 1910
type identityref { type identityref {
base symmetric-key-format; base symmetric-key-format;
} }
description description
"Identifies the symmetric key's format. Implementations "Identifies the symmetric key's format. Implementations
SHOULD ensure that the incoming symmetric key value is SHOULD ensure that the incoming symmetric key value is
encoded in the specified format. encoded in the specified format.
For encrypted keys, the value is the decrypted key's For encrypted keys, the value is the decrypted key's
format (i.e., the 'encrypted-value-format' conveys the format (i.e., the 'encrypted-value-format' conveys the
encrypted key's format."; encrypted key's format).";
} }
choice key-type { choice key-type {
nacm:default-deny-write; nacm:default-deny-write;
mandatory true; mandatory true;
description description
"Choice between key types."; "Choice between key types.";
case cleartext-symmetric-key { case cleartext-symmetric-key {
leaf cleartext-symmetric-key { leaf cleartext-symmetric-key {
if-feature "cleartext-symmetric-keys"; if-feature "cleartext-symmetric-keys";
nacm:default-deny-all; nacm:default-deny-all;
skipping to change at line 1983 skipping to change at line 1934
"The binary value of the key. The interpretation of "The binary value of the key. The interpretation of
the value is defined by the 'key-format' field."; the value is defined by the 'key-format' field.";
} }
} }
case hidden-symmetric-key { case hidden-symmetric-key {
if-feature "hidden-symmetric-keys"; if-feature "hidden-symmetric-keys";
leaf hidden-symmetric-key { leaf hidden-symmetric-key {
type empty; type empty;
must 'not(../key-format)'; must 'not(../key-format)';
description description
"A hidden key is not exportable, and not extractable, "A hidden key is not exportable and not extractable;
and therefore, it is of type 'empty' as its value is therefore, it is of type 'empty' as its value is
inaccessible via management interfaces. Though hidden inaccessible via management interfaces. Though hidden
to users, such keys are not hidden to the server and to users, such keys are not hidden to the server and
may be referenced by configuration to indicate which may be referenced by configuration to indicate which
key a server should use for a cryptographic operation. key a server should use for a cryptographic operation.
How such keys are created is outside the scope of this How such keys are created is outside the scope of this
module."; module.";
} }
} }
case encrypted-symmetric-key { case encrypted-symmetric-key {
if-feature "encrypted-symmetric-keys"; if-feature "encrypted-symmetric-keys";
container encrypted-symmetric-key { container encrypted-symmetric-key {
skipping to change at line 2017 skipping to change at line 1968
grouping public-key-grouping { grouping public-key-grouping {
description description
"A public key."; "A public key.";
leaf public-key-format { leaf public-key-format {
nacm:default-deny-write; nacm:default-deny-write;
type identityref { type identityref {
base public-key-format; base public-key-format;
} }
mandatory true; mandatory true;
description description
"Identifies the public key's format. Implementations SHOULD "Identifies the public key's format. Implementations SHOULD
ensure that the incoming public key value is encoded in the ensure that the incoming public key value is encoded in the
specified format."; specified format.";
} }
leaf public-key { leaf public-key {
nacm:default-deny-write; nacm:default-deny-write;
type binary; type binary;
mandatory true; mandatory true;
description description
"The binary value of the public key. The interpretation "The binary value of the public key. The interpretation
of the value is defined by 'public-key-format' field."; of the value is defined by the 'public-key-format' field.";
} }
} }
grouping private-key-grouping { grouping private-key-grouping {
description description
"A private key."; "A private key.";
leaf private-key-format { leaf private-key-format {
nacm:default-deny-write; nacm:default-deny-write;
type identityref { type identityref {
base private-key-format; base private-key-format;
} }
description description
"Identifies the private key's format. Implementations SHOULD "Identifies the private key's format. Implementations SHOULD
ensure that the incoming private key value is encoded in the ensure that the incoming private key value is encoded in the
specified format. specified format.
For encrypted keys, the value is the decrypted key's For encrypted keys, the value is the decrypted key's
format (i.e., the 'encrypted-value-format' conveys the format (i.e., the 'encrypted-value-format' conveys the
encrypted key's format."; encrypted key's format).";
} }
choice private-key-type { choice private-key-type {
nacm:default-deny-write; nacm:default-deny-write;
mandatory true; mandatory true;
description description
"Choice between key types."; "Choice between key types.";
case cleartext-private-key { case cleartext-private-key {
if-feature "cleartext-private-keys"; if-feature "cleartext-private-keys";
leaf cleartext-private-key { leaf cleartext-private-key {
nacm:default-deny-all; nacm:default-deny-all;
type binary; type binary;
must '../private-key-format'; must '../private-key-format';
description description
"The value of the binary key The key's value is "The value of the binary key. The key's value is
interpreted by the 'private-key-format' field."; interpreted by the 'private-key-format' field.";
} }
} }
case hidden-private-key { case hidden-private-key {
if-feature "hidden-private-keys"; if-feature "hidden-private-keys";
leaf hidden-private-key { leaf hidden-private-key {
type empty; type empty;
must 'not(../private-key-format)'; must 'not(../private-key-format)';
description description
"A hidden key. It is of type 'empty' as its value is "A hidden key. It is of type 'empty' as its value is
inaccessible via management interfaces. Though hidden inaccessible via management interfaces. Though hidden
to users, such keys are not hidden to the server and to users, such keys are not hidden to the server and
and may be referenced by configuration to indicate which may be referenced by configuration to indicate which
key a server should use for a cryptographic operation. key a server should use for a cryptographic operation.
How such keys are created is outside the scope of this How such keys are created is outside the scope of this
module."; module.";
} }
} }
case encrypted-private-key { case encrypted-private-key {
if-feature "encrypted-private-keys"; if-feature "encrypted-private-keys";
container encrypted-private-key { container encrypted-private-key {
must '../private-key-format'; must '../private-key-format';
description description
skipping to change at line 2099 skipping to change at line 2050
} }
} }
} }
grouping asymmetric-key-pair-grouping { grouping asymmetric-key-pair-grouping {
description description
"A private key and, optionally, its associated public key. "A private key and, optionally, its associated public key.
Implementations MUST ensure that the two keys, when both Implementations MUST ensure that the two keys, when both
are specified, are a matching pair."; are specified, are a matching pair.";
uses public-key-grouping { uses public-key-grouping {
refine public-key-format { refine "public-key-format" {
mandatory false; mandatory false;
} }
refine public-key { refine "public-key" {
mandatory false; mandatory false;
} }
} }
uses private-key-grouping; uses private-key-grouping;
} }
grouping certificate-expiration-grouping { grouping certificate-expiration-grouping {
description description
"A notification for when a certificate is about to, or "A notification for when a certificate is about to expire or
already has, expired."; has already expired.";
notification certificate-expiration { notification certificate-expiration {
if-feature "certificate-expiration-notification"; if-feature "certificate-expiration-notification";
description description
"A notification indicating that the configured certificate "A notification indicating that the configured certificate
is either about to expire or has already expired. When to is either about to expire or has already expired. When to
send notifications is an implementation specific decision, send notifications is an implementation-specific decision,
but it is RECOMMENDED that a notification be sent once a but it is RECOMMENDED that a notification be sent once a
month for 3 months, then once a week for four weeks, and month for 3 months, then once a week for four weeks, and
then once a day thereafter until the issue is resolved. then once a day thereafter until the issue is resolved.
If the certificate's Issuer maintains a Certificate If the certificate's issuer maintains a Certificate
Revocation List (CRL), the expiration notification MAY Revocation List (CRL), the expiration notification MAY
be sent if the CRL is about to expire."; be sent if the CRL is about to expire.";
leaf expiration-date { leaf expiration-date {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"Identifies the expiration date on the certificate."; "Identifies the expiration date on the certificate.";
} }
} }
} }
grouping trust-anchor-cert-grouping { grouping trust-anchor-cert-grouping {
description description
"A trust anchor certificate, and a notification for when "A trust anchor certificate and a notification for when
it is about to (or already has) expire."; it is about to expire or has already expired.";
leaf cert-data { leaf cert-data {
nacm:default-deny-all; nacm:default-deny-all;
type trust-anchor-cert-cms; type trust-anchor-cert-cms;
description description
"The binary certificate data for this certificate."; "The binary certificate data for this certificate.";
} }
uses certificate-expiration-grouping; uses certificate-expiration-grouping;
} }
grouping end-entity-cert-grouping { grouping end-entity-cert-grouping {
description description
"An end entity certificate, and a notification for when "An end-entity certificate and a notification for when
it is about to (or already has) expire. Implementations it is about to expire or has already expired. Implementations
SHOULD assert that, where used, the end entity certificate SHOULD assert that, where used, the end-entity certificate
contains the expected public key."; contains the expected public key.";
leaf cert-data { leaf cert-data {
nacm:default-deny-all; nacm:default-deny-all;
type end-entity-cert-cms; type end-entity-cert-cms;
description description
"The binary certificate data for this certificate."; "The binary certificate data for this certificate.";
} }
uses certificate-expiration-grouping; uses certificate-expiration-grouping;
} }
skipping to change at line 2174 skipping to change at line 2125
description description
"Defines the 'generate-csr' action."; "Defines the 'generate-csr' action.";
action generate-csr { action generate-csr {
if-feature "csr-generation"; if-feature "csr-generation";
nacm:default-deny-all; nacm:default-deny-all;
description description
"Generates a certificate signing request structure for "Generates a certificate signing request structure for
the associated asymmetric key using the passed subject the associated asymmetric key using the passed subject
and attribute values. and attribute values.
This action statement is only available when the This 'action' statement is only available when the
associated 'public-key-format' node's value is associated 'public-key-format' node's value is
'subject-public-key-info-format'."; 'subject-public-key-info-format'.";
input { input {
leaf csr-format { leaf csr-format {
type identityref { type identityref {
base csr-format; base csr-format;
} }
mandatory true; mandatory true;
description description
"Specifies the format for the returned certificate."; "Specifies the format for the returned certificate.";
} }
leaf csr-info { leaf csr-info {
type csr-info; type csr-info;
mandatory true; mandatory true;
description description
"A CertificationRequestInfo structure, as defined in "A CertificationRequestInfo structure, as defined in
RFC 2986. RFC 2986.
Enables the client to provide a fully-populated Enables the client to provide a fully populated
CertificationRequestInfo structure that the server CertificationRequestInfo structure that the server
only needs to sign in order to generate the complete only needs to sign in order to generate the complete
'CertificationRequest' structure to return in the CertificationRequest structure to return in the
'output'. 'output'.
The 'AlgorithmIdentifier' field contained inside The 'AlgorithmIdentifier' field contained inside
the 'SubjectPublicKeyInfo' field MUST be one known the 'SubjectPublicKeyInfo' field MUST be one known
to be supported by the device."; to be supported by the device.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax Specification PKCS #10: Certification Request Syntax Specification
RFC AAAA: RFC 9640:
YANG Data Types and Groupings for Cryptography"; YANG Data Types and Groupings for Cryptography";
} }
} }
output { output {
choice csr-type { choice csr-type {
mandatory true; mandatory true;
description description
"A choice amongst certificate signing request formats. "A choice amongst certificate signing request formats.
Additional formats MAY be augmented into this 'choice' Additional formats MAY be augmented into this 'choice'
statement by future efforts."; statement by future efforts.";
skipping to change at line 2227 skipping to change at line 2178
leaf p10-csr { leaf p10-csr {
type p10-csr; type p10-csr;
description description
"A CertificationRequest, as defined in RFC 2986."; "A CertificationRequest, as defined in RFC 2986.";
} }
description description
"A CertificationRequest, as defined in RFC 2986."; "A CertificationRequest, as defined in RFC 2986.";
reference reference
"RFC 2986: "RFC 2986:
PKCS #10: Certification Request Syntax Specification PKCS #10: Certification Request Syntax Specification
RFC AAAA: RFC 9640:
YANG Data Types and Groupings for Cryptography"; YANG Data Types and Groupings for Cryptography";
} }
} }
} }
} }
} // generate-csr-grouping } // generate-csr-grouping
grouping asymmetric-key-pair-with-cert-grouping { grouping asymmetric-key-pair-with-cert-grouping {
description description
"A private/public key pair and an associated certificate. "A private/public key pair and an associated certificate.
skipping to change at line 2275 skipping to change at line 2226
refine "cert-data" { refine "cert-data" {
mandatory true; mandatory true;
} }
} }
} }
} }
uses generate-csr-grouping; uses generate-csr-grouping;
} // asymmetric-key-pair-with-certs-grouping } // asymmetric-key-pair-with-certs-grouping
} }
]]></artwork> ]]></sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
</section> </section>
<section> <section>
<name>Security Considerations</name> <name>Security Considerations</name>
<section> <section>
<name>No Support for CRMF</name> <name>No Support for CRMF</name>
<t>This document uses PKCS #10 <xref target="RFC2986"/> for the <t>This document uses PKCS #10 <xref target="RFC2986"/> for the
"generate-certificate-signing-request" action. The use of Certificate "generate-csr" action. The use of Certificate
Request Message Format (CRMF) <xref target="RFC4211"/> was considered, Request Message Format (CRMF) <xref target="RFC4211"/> was considered,
but it was unclear if there was market demand for it. If it is desire d but it was unclear if there was market demand for it. If it is desire d
to support CRMF in the future, a backwards compatible solution can be to support CRMF in the future, a backwards compatible solution can be
defined at that time.</t> defined at that time.</t>
</section> </section>
<section> <section>
<name>No Support for Key Generation</name> <name>No Support for Key Generation</name>
<t>Early revisions of this document included "rpc" statements for <t>Early revisions of this document included "rpc" statements for
generating symmetric and asymmetric keys. These statements were generating symmetric and asymmetric keys. These statements were
removed due to an inability to obtain consensus for how to removed due to an inability to obtain consensus for how to
generically identify the key-algorithm to use. Hence, the generically identify the key algorithm to use. Hence, the
solution presented in this document only supports keys to be solution presented in this document only supports keys to be
configured via an external client.</t> configured via an external client.</t>
<t>Separate protocol-specific modules can present protocol-specific <t>Separate protocol-specific modules can present protocol-specific
key-generating RPCs (e.g., the "generate-public-key" RPC in key-generating RPCs (e.g., the "generate-asymmetric-key-pair" RPC in
<xref target="I-D.ietf-netconf-ssh-client-server"/> <xref target="RFC9644"/>
and <xref target="I-D.ietf-netconf-tls-client-server"/>).</t> and <xref target="RFC9645"/>).</t>
</section> </section>
<section> <section>
<name>Unconstrained Public Key Usage</name> <name>Unconstrained Public Key Usage</name>
<t>This module defines the "public-key-grouping" grouping, which <t>This module defines the "public-key-grouping" grouping, which
enables the configuration of public keys without constraints on enables the configuration of public keys without constraints on
their usage, e.g., what operations the key is allowed to be used their usage, e.g., what operations the key is allowed to be used
for (encryption, verification, both).</t> for (e.g., encryption, verification, or both).</t>
<t>The "asymmetric-key-pair-grouping" grouping uses the aforementioned <t>The "asymmetric-key-pair-grouping" grouping uses the aforementioned
"public-key-grouping" grouping, and carries the same traits.</t> "public-key-grouping" grouping and carries the same traits.</t>
<t>The "asymmetric-key-pair-with-cert-grouping" grouping uses the <t>The "asymmetric-key-pair-with-cert-grouping" grouping uses the
aforementioned "asymmetric-key-pair-grouping" grouping, whereby aforementioned "asymmetric-key-pair-grouping" grouping, whereby
associated certificates MUST constrain the usage of the public associated certificates <bcp14>MUST</bcp14> constrain the usage of t he public
key according to local policy.</t> key according to local policy.</t>
</section> </section>
<section> <section>
<name>Unconstrained Private Key Usage</name> <name>Unconstrained Private Key Usage</name>
<t>This module defines the "asymmetric-key-pair-grouping" grouping, <t>This module defines the "asymmetric-key-pair-grouping" grouping,
which enables the configuration of private keys without which 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 (e.g., signature, decryption, or both).</t>
<t>The "asymmetric-key-pair-with-cert-grouping" uses the aforementioned <t>The "asymmetric-key-pair-with-cert-grouping" grouping uses the aforem
entioned
"asymmetric-key-pair-grouping" grouping, whereby configured certific ates "asymmetric-key-pair-grouping" grouping, whereby configured certific ates
(e.g., identity certificates) may constrain the use of the public (e.g., identity certificates) may constrain the use of the public
key according to local policy.</t> key according to local policy.</t>
</section> </section>
<section> <section>
<name>Cleartext Passwords and Keys</name> <name>Cleartext Passwords and Keys</name>
<t>The module contained within this document enables, only when <t>The module contained within this document enables, only when
specific "feature" statements are enabled, for the cleartext specific "feature" statements are enabled, for the cleartext
value of passwords and keys to be stored in the configuration value of passwords and keys to be stored in the configuration
database. Storing cleartext values for passwords and keys is database. Storing cleartext values for passwords and keys is
NOT RECOMMENDED.</t> <bcp14>NOT RECOMMENDED</bcp14>.</t>
</section> </section>
<section> <section>
<name>Encrypting Passwords and Keys</name> <name>Encrypting Passwords and Keys</name>
<t>The module contained within this document enables cleartext <t>The module contained within this document enables cleartext
passwords and keys to be encrypted via another key, either passwords and keys to be encrypted via another key, either
symmetric or asymmetric. Both formats use a CMS structure symmetric or asymmetric. Both formats use a CMS structure
(EncryptedData and EnvelopedData respectively), which allows (EncryptedData and EnvelopedData, respectively), which allows
any encryption algorithm to be used.</t> any encryption algorithm to be used.</t>
<t>To securely encrypt a password or key with a symmetric key, a <t>To securely encrypt a password or key with a symmetric key, a
proper block cipher mode such as an AEAD or CBC MUST be used. This proper block cipher mode, such as an Authenticated Encryption with Assoc
ensures that a random IV is part of the input, which guarantees iated Data (AEAD) or Cipher Block Chaining (CBC), <bcp14>MUST</bcp14> be used.
This
ensures that a random Initialization Vector (IV) is part of the inpu
t, which guarantees
that the output for encrypting the same password or key still that the output for encrypting the same password or key still
produces a different unpredictable ciphertext. This avoids leaking produces a different unpredictable ciphertext. This avoids leaking
that some encrypted keys or passwords are the same and makes it that some encrypted keys or passwords are the same and makes it
much harder to pre-generate rainbow tables to brute force attack much harder to pre-generate rainbow tables to brute-force attack
weak passwords. The ECB block cipher mode MUST NOT be used.</t> weak passwords.
The Electronic Codebook (ECB) block cipher mode <bcp14>MUST NOT</bcp14> b
e used.</t>
</section> </section>
<section> <section>
<name>Deletion of Cleartext Key Values</name> <name>Deletion of Cleartext Key Values</name>
<t>This module defines storage for cleartext key values that SHOULD <t>This module defines storage for cleartext key values that <bcp14>SHOU
be zeroized when deleted, so as to prevent the remnants of their LD</bcp14>
be zeroized when deleted so as to prevent the remnants of their
persisted storage locations from being analyzed in any meaningful persisted storage locations from being analyzed in any meaningful
way.</t> way.</t>
<t>The cleartext key values are the "cleartext-symmetric-key" node defin ed in the <t>The cleartext key values are the "cleartext-symmetric-key" node defin ed in the
"symmetric-key-grouping" grouping (<xref target="symmetric-key-group ing"/>) "symmetric-key-grouping" grouping (<xref target="symmetric-key-group ing"/>)
and the "cleartext-private-key" node defined in the "asymmetric-ke y-pair-grouping" and the "cleartext-private-key" node defined in the "asymmetric-ke y-pair-grouping"
grouping ("<xref target="asymmetric-key-pair-grouping"/>).</t> grouping (<xref target="asymmetric-key-pair-grouping"/>).</t>
</section> </section>
<section> <section>
<name>Considerations for the "ietf-crypto-types" YANG Module</name> <name>Considerations for the "ietf-crypto-types" YANG Module</name>
<t>This section follows the template defined in <xref section="3.7.1" ta <t>This section is modeled after the template defined in <xref section="
rget="RFC8407"/>.</t> 3.7.1" target="RFC8407"/>.</t>
<t>The YANG module in this document defines "grouping" statements <t>The "ietf-crypto-types" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management that are designed to be accessed via YANG-based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have <xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS) mandatory-to-implement secure transport layers (e.g., Secure Shell (
with mutual authentication.</t> SSH) <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref targ
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> et="RFC9000"/>) and mandatory-to-implement mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="R
FC8341"/>
provides the means to restrict access for particular users to a provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and preconfigured subset of all available protocol operations and
content.</t> content.</t>
<t>Since the module in this document only defines groupings, <t>Since the module in this document only defines groupings,
these considerations are primarily for the designers of other these considerations are primarily for the designers of other
modules that use these groupings.</t> modules that use these groupings.</t>
<t>Some of the readable data nodes defined in this YANG module <t>Some of the readable data nodes defined 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. The following subtrees and data nodes have particular
sensitivity/vulnerability: sensitivity/vulnerability:
skipping to change at line 2415 skipping to change at line 2367
applied to it.</li> applied to it.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>The "cleartext-private-key" node: <t>The "cleartext-private-key" node:
</t> </t>
<ul empty="true"> <ul empty="true">
<li>The "cleartext-private-key" node defined in the "asymmetric-ke y-pair-grouping" <li>The "cleartext-private-key" node defined in the "asymmetric-ke y-pair-grouping"
grouping is additionally sensitive to read operations such t hat, in grouping is additionally sensitive to read operations such t hat, 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" has been appli ed.</li> reason, the NACM extension "default-deny-all" has been appli ed to it.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>The "cert-data" node: <t>The "cert-data" node:
</t> </t>
<ul empty="true"> <ul empty="true">
<li>The "cert-data" node, defined in both the "trust-anchor-cert-g <li>The "cert-data" node defined in both the "trust-anchor-cert-gr
rouping" ouping"
and "end-entity-cert-grouping" groupings, is additionally se and "end-entity-cert-grouping" groupings is additionally sen
nsitive to sitive to
read operations, as certificates may provide insight into wh ich other read operations, as certificates may provide insight into wh ich other
resources/applications/servers this particular server commun icates with, resources/applications/servers this particular server commun icates with,
as well as potentially divulge personally identifying infor mation (e.g., as well as potentially divulge personally identifying infor mation (e.g.,
end-entity certificates). For this reason, the NACM extensi on end-entity certificates). For this reason, the NACM extensi on
"default-deny-all" has been applied.</li> "default-deny-all" has been applied to it.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>All the writable data nodes defined by all the groupings defined <t>All the writable data nodes defined by all the groupings defined
in this module may be considered sensitive or vulnerable in in this module may be considered sensitive or vulnerable in
some network environments. For instance, even the modification some network environments. For instance, even the modification
of a public key or a certificate can dramatically alter the of a public key or a certificate can dramatically alter the
implemented security policy. For this reason, the NACM extension implemented security policy. For this reason, the NACM extension
"default-deny-write" has been applied to all the data nodes "default-deny-write" has been applied to all the data nodes
defined in the module.</t> defined in the module.</t>
<t>Some of the operations in this YANG module may be considered <t>Some of the operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is sensitive or vulnerable in some network environments. It is
thus important to control access to these operations. These thus important to control access to these operations. These
are the operations and their sensitivity/vulnerability: are the operations and their sensitivity/vulnerability:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>generate-certificate-signing-request: <t>generate-csr:
</t> </t>
<ul empty="true"> <ul empty="true">
<li>This "action" statement SHOULD only be executed by authorized <li>This "action" statement <bcp14>SHOULD</bcp14> only be executed by authorized
users. For this reason, the NACM extension "default-deny-al l" users. For this reason, the NACM extension "default-deny-al l"
has been applied. Note that NACM uses "default-deny-all" has been applied. Note that NACM uses "default-deny-all"
to protect "RPC" and "action" statements; it does not define , to protect "rpc" and "action" statements; it does not define ,
e.g., an extension called "default-deny-execute".</li> e.g., an extension called "default-deny-execute".</li>
<li>For this action, it is RECOMMENDED that implementations assert <li>For this action, it is <bcp14>RECOMMENDED</bcp14> that impleme
channel binding <xref target="RFC5056"/>, so as to ensure ntations assert
channel binding <xref target="RFC5056"/> so as to ensure
that the application layer that sent the request is the same that the application layer that sent the request is the same
as the device authenticated when the secure transport layer as the device authenticated when the secure transport layer
was established.</li> was established.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</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 <t>IANA has registered the following URI in the "ns" registry
of the "IETF XML" registry <xref target="RFC3688"/>. Following of the "IETF XML Registry" <xref target="RFC3688"/>.</t>
the format in <xref target="RFC3688"/>, the following <dl newline="false" spacing="compact">
registration is requested:</t> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-crypto-types</dd>
<artwork><![CDATA[ <dt>Registrant Contact:</dt> <dd>The IESG</dd>
URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types <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 <xref target="RFC6020"/>.
Following the format in <xref target="RFC6020"/>, the </t>
following registration is requested:</t> <dl newline="false" spacing="compact">
<artwork><![CDATA[ <dt>Name:</dt> <dd>ietf-crypto-types</dd>
name: ietf-crypto-types <dt>Namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-crypto-types</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types <dt>Prefix:</dt> <dd>ct</dd>
prefix: ct <dt>Reference:</dt> <dd>RFC 9640</dd>
reference: RFC AAAA </dl>
]]></artwork>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netconf-http-client-server"
to="HTTP-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netconf-netconf-client-server"
to="NETCONF-CLIENT-SERVER"/>
<displayreference target="I-D.ietf-netconf-restconf-client-server"
to="RESTCONF-CLIENT-SERVER"/>
<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.2
le> 986.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month="March" year="1997"/> 252.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
<t>In many standards track documents several words are used to sig 53.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.52
his document defines these words as they should be interpreted in IETF documents 80.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.56
mmunity, and requests discussion and suggestions for improvements.</t> 52.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</front> 915.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<seriesInfo name="RFC" value="2119"/> 58.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
</reference> 31.xml"/>
<!--<?rfc include="reference.RFC.2404.xml"?>--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<!--<?rfc include="reference.RFC.3565.xml"?> 241.xml"/>
<?rfc include="reference.RFC.3686.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
<?rfc include="reference.RFC.4106.xml"?>--> 60.xml"/>
<reference anchor="RFC4253" target="https://www.rfc-editor.org/info/rfc4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
253" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml"> 91.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.70
<title>The Secure Shell (SSH) Transport Layer Protocol</title> 93.xml"/>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
<author fullname="C. Lonvick" initials="C." role="editor" surname="L 50.xml"/>
onvick"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<date month="January" year="2006"/> 17.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>The Secure Shell (SSH) is a protocol for secure remote login an 040.xml"/>
d other secure network services over an insecure network.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<t>This document describes the SSH transport layer protocol, which 74.xml"/>
typically runs on top of TCP/IP. The protocol can be used as a basis for a numb <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
er of secure network services. It provides strong encryption, server authenticat 41.xml"/>
ion, and integrity protection. It may also provide compression.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>Key exchange method, public key algorithm, symmetric encryption 446.xml"/>
algorithm, message authentication algorithm, and hash algorithm are all negotia <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ted.</t> 000.xml"/>
<t>This document also describes the Diffie-Hellman key exchange me
thod and the minimal set of algorithms that are needed to implement the SSH tran
sport layer protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4253"/>
<seriesInfo name="DOI" value="10.17487/RFC4253"/>
</reference>
<!--<?rfc include="reference.RFC.4279.xml"?>
<?rfc include="reference.RFC.4309.xml"?>
<?rfc include="reference.RFC.4494.xml"?>
<?rfc include="reference.RFC.4543.xml"?>
<?rfc include="reference.RFC.4868.xml"?>-->
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5
652" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS).
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
ry message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<!--<?rfc include="reference.RFC.5656.xml"?>-->
<reference anchor="RFC5958" target="https://www.rfc-editor.org/info/rfc5
958" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml">
<front>
<title>Asymmetric Key Packages</title>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="August" year="2010"/>
<abstract>
<t>This document defines the syntax for private-key information an
d a content type for it. Private-key information includes a private key for a sp
ecified public-key algorithm and a set of attributes. The Cryptographic Message
Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, aut
henticate, or encrypt the asymmetric key format content type. This document obso
letes RFC 5208. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5958"/>
<seriesInfo name="DOI" value="10.17487/RFC5958"/>
</reference>
<reference anchor="RFC6031" target="https://www.rfc-editor.org/info/rfc6
031" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6031.xml">
<front>
<title>Cryptographic Message Syntax (CMS) Symmetric Key Package Cont
ent Type</title>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="December" year="2010"/>
<abstract>
<t>This document defines the symmetric key format content type. It
is transport independent. The Cryptographic Message Syntax (CMS) can be used to
digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6031"/>
<seriesInfo name="DOI" value="10.17487/RFC6031"/>
</reference>
<!--<?rfc include="reference.RFC.6187.xml"?>-->
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
960" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S
tatus Protocol - OCSP</title>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="M. Myers" initials="M." surname="Myers"/>
<author fullname="R. Ankney" initials="R." surname="Ankney"/>
<author fullname="A. Malpani" initials="A." surname="Malpani"/>
<author fullname="S. Galperin" initials="S." surname="Galperin"/>
<author fullname="C. Adams" initials="C." surname="Adams"/>
<date month="June" year="2013"/>
<abstract>
<t>This document specifies a protocol useful in determining the cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (CRLs). Additional mechanisms addressing PKIX operational requirements are
specified in separate documents. This document obsoletes RFCs 2560 and 6277. It
also updates RFC 5912.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6960"/>
<seriesInfo name="DOI" value="10.17487/RFC6960"/>
</reference>
<reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6
991" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e used with the YANG data modeling language. This document obsoletes RFC 6021.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC7093" target="https://www.rfc-editor.org/info/rfc7
093" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7093.xml">
<front>
<title>Additional Methods for Generating Key Identifiers Values</tit
le>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="J. Manger" initials="J." surname="Manger"/>
<date month="December" year="2013"/>
<abstract>
<t>This document specifies additional example methods for generati
ng Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (
Subject Key Identifier) certificate extensions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7093"/>
<seriesInfo name="DOI" value="10.17487/RFC7093"/>
</reference>
<!--<?rfc include="reference.RFC.7919.xml"?>-->
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
<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="RFC8017" target="https://www.rfc-editor.org/info/rfc8
017" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="November" year="2016"/>
<abstract>
<t>This document provides recommendations for the implementation o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</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>
<!--<?rfc include="reference.RFC.8268.xml"?>
<?rfc include="reference.RFC.8332.xml"?>-->
<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>
<!--<?rfc include="reference.RFC.8422.xml"?>
<?rfc include="reference.RFC.8446.xml"?>-->
<reference anchor="ITU.X680.2021" target="https://www.itu.int/rec/T-REC- X.680-202102-I"> <reference anchor="ITU.X680.2021" target="https://www.itu.int/rec/T-REC- X.680-202102-I">
<front> <front>
<title>Information technology - Abstract Syntax Notation One (ASN.1) : <title>Information technology - Abstract Syntax Notation One (ASN.1) :
Specification of basic notation Specification of basic notation
</title> </title>
<author> <author>
<organization>International Telecommunication Union</organization> <organization>ITU-T</organization>
</author> </author>
<date month="February" year="2021"/> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation X.680," value="ISO/IEC 8824-1:2 <seriesInfo name="ITU-T Recommendation" value="X.680"/>
021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference> </reference>
<reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC- X.690-202102-I"> <reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC- X.690-202102-I">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic <title>Information Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguish ed Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguish ed
Encoding Rules (DER)</title> Encoding Rules (DER)</title>
<author> <author>
<organization>International Telecommunication Union</organization> <organization>ITU-T</organization>
</author> </author>
<date month="February" year="2021"/> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation X.690," value="ISO/IEC 8825-1:2 <seriesInfo name="ITU-T Recommendation" value="X.690"/>
021"/> <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2
986" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 688.xml"/>
<title>PKCS #10: Certification Request Syntax Specification Version <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
1.7</title> 211.xml"/>
<author fullname="M. Nystrom" initials="M." surname="Nystrom"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> 056.xml"/>
<date month="November" year="2000"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<abstract> 020.xml"/>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
Laboratories' Public-Key Cryptography Standards (PKCS) series, and change contro 317.xml"/>
l is retained within the PKCS process. The body of this document, except for the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
security considerations section, is taken directly from the PKCS #9 v2.0 or the 259.xml"/>
PKCS #10 v1.7 document. This memo provides information for the Internet communi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ty.</t> 340.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 407.xml"/>
<seriesInfo name="RFC" value="2986"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC2986"/> 342.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<!--<?rfc include="reference.RFC.3174.xml"?>--> 792.xml"/>
<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"> <reference anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc96
<front> 41">
<title>The IETF XML Registry</title> <front>
<author fullname="M. Mealling" initials="M." surname="Mealling"/> <title>A YANG Data Model for a Truststore</title>
<date month="January" year="2004"/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<abstract> <organization>Watsen Networks</organization>
<t>This document describes an IANA maintained registry for IETF st </author>
andards which use Extensible Markup Language (XML) related items such as Namespa <date month="October" year="2024"/>
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew </front>
ork (RDF) Schemas.</t> <seriesInfo name="RFC" value="9641"/>
</abstract> <seriesInfo name="DOI" value="10.17487/RFC9641"/>
</front> </reference>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/> <reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9
<seriesInfo name="DOI" value="10.17487/RFC3688"/> 642">
</reference> <front>
<reference anchor="RFC4211" target="https://www.rfc-editor.org/info/rfc4 <title>A YANG Data Model for a Keystore</title>
211" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<front> <organization>Watsen Networks</organization>
<title>Internet X.509 Public Key Infrastructure Certificate Request </author>
Message Format (CRMF)</title> <date month="October" year="2024"/>
<author fullname="J. Schaad" initials="J." surname="Schaad"/> </front>
<date month="September" year="2005"/> <seriesInfo name="RFC" value="9642"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC9642"/>
<t>This document describes the Certificate Request Message Format </reference>
(CRMF) syntax and semantics. This syntax is used to convey a request for a certi
ficate to a Certification Authority (CA), possibly via a Registration Authority <reference anchor="RFC9643" target="https://www.rfc-editor.org/info/rfc9
(RA), for the purposes of X.509 certificate production. The request will typical 643">
ly include a public key and the associated registration information. This docume <front>
nt does not define a certificate request protocol. [STANDARDS-TRACK]</t> <title>YANG Groupings for TCP Clients and TCP Servers</title>
</abstract> <author initials="K." surname="Watsen" fullname="Kent Watsen">
</front> <organization>Watsen Networks</organization>
<seriesInfo name="RFC" value="4211"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC4211"/> <author initials="M." surname="Scharf" fullname="Michael Scharf">
</reference> <organization>Hochschule Esslingen - University of Applied Sciences
<!--<?rfc include="reference.RFC.4493.xml"?>--> </organization>
<reference anchor="RFC5056" target="https://www.rfc-editor.org/info/rfc5 </author>
056" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5056.xml"> <date month="October" year="2024"/>
<front> </front>
<title>On the Use of Channel Bindings to Secure Channels</title> <seriesInfo name="RFC" value="9643"/>
<author fullname="N. Williams" initials="N." surname="Williams"/> <seriesInfo name="DOI" value="10.17487/RFC9643"/>
<date month="November" year="2007"/> </reference>
<abstract>
<t>The concept of channel binding allows applications to establish <reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc96
that the two end-points of a secure channel at one network layer are the same a 44">
s at a higher layer by binding authentication at the higher layer to the channel <front>
at the lower layer. This allows applications to delegate session protection to <title>YANG Groupings for SSH Clients and SSH Servers</title>
lower layers, which has various performance benefits.</t> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<t>This document discusses and formalizes the concept of channel b <organization>Watsen Networks</organization>
inding to secure channels. [STANDARDS-TRACK]</t> </author>
</abstract> <date month="October" year="2024"/>
</front> </front>
<seriesInfo name="RFC" value="5056"/> <seriesInfo name="RFC" value="9644"/>
<seriesInfo name="DOI" value="10.17487/RFC5056"/> <seriesInfo name="DOI" value="10.17487/RFC9644"/>
</reference> </reference>
<reference anchor="RFC5915" target="https://www.rfc-editor.org/info/rfc5
915" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml"> <reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc9
<front> 645">
<title>Elliptic Curve Private Key Structure</title> <front>
<author fullname="S. Turner" initials="S." surname="Turner"/> <title>YANG Groupings for TLS Clients and TLS Servers</title>
<author fullname="D. Brown" initials="D." surname="Brown"/> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<date month="June" year="2010"/> <organization>Watsen Networks</organization>
<abstract> </author>
<t>This document specifies the syntax and semantics for conveying <date month="October" year="2024"/>
Elliptic Curve (EC) private key information. The syntax and semantics defined he </front>
rein are based on similar syntax and semantics defined by the Standards for Effi <seriesInfo name="RFC" value="9645"/>
cient Cryptography Group (SECG). This document is not an Internet Standards Trac <seriesInfo name="DOI" value="10.17487/RFC9645"/>
k specification; it is published for informational purposes.</t> </reference>
</abstract>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
<seriesInfo name="RFC" value="5915"/> conf-http-client-server"/>
<seriesInfo name="DOI" value="10.17487/RFC5915"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6 conf-netconf-client-server"/>
020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net
<title>YANG - A Data Modeling Language for the Network Configuration conf-restconf-client-server"/>
Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= <reference anchor="W3C.REC-xml-20081126"
"Bjorklund"/> target="https://www.w3.org/TR/2008/REC-xml-20081126/">
<date month="October" year="2010"/> <front>
<abstract> <title>Extensible Markup Language (XML) 1.0
<t>YANG is a data modeling language used to model configuration an (Fifth Edition)</title>
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON <author initials="T." surname="Bray" fullname="Tim Bray"/>
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> <author initials="J." surname="Paoli" fullname="Jean Paoli"/>
</abstract> <author initials="C.M." surname="Sperberg-McQueen" fullname="C. M.
</front> Sperberg-McQueen"/>
<seriesInfo name="RFC" value="6020"/> <author initials="E." surname="Maler" fullname="Eve Maler"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/> <author initials="F." surname="Yergeau" fullname="François Yergeau"/>
</reference> <date month="November" year="2008"/>
<!--<?rfc include="reference.RFC.6234.xml"?>--> </front>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 <seriesInfo name="World Wide Web Consortium
241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"> Recommendation" value="REC-xml-20081126"/>
<front> </reference>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns
"/>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract>
<t>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>
<!--<?rfc include="reference.RFC.6239.xml"?>
<?rfc include="reference.RFC.6507.xml"?>
<?rfc include="reference.RFC.8032.xml"?>-->
<reference anchor="RFC7317" target="https://www.rfc-editor.org/info/rfc7
317" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml">
<front>
<title>A YANG Data Model for System Management</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="August" year="2014"/>
<abstract>
<t>This document defines a YANG data model for the configuration a
nd identification of some common system properties within a device containing a
Network Configuration Protocol (NETCONF) server. This document also includes dat
a node definitions for system identification, time-of-day management, user manag
ement, DNS resolver configuration, and some protocol operations for system manag
ement.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7317"/>
<seriesInfo name="DOI" value="10.17487/RFC7317"/>
</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="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="RFC8407" target="https://www.rfc-editor.org/info/rfc8
407" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<date month="October" year="2018"/>
<abstract>
<t>This memo provides guidelines for authors and reviewers of spec
ifications containing YANG modules. Recommendations and procedures are defined,
which are intended to increase interoperability and usability of Network Configu
ration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YAN
G modules. This document obsoletes RFC 6087.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference>
<!--<?rfc include="reference.RFC.8439.xml"?>-->
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s an architectural framework for datastores based on the experience gained with
the initial simpler model, addressing requirements that were not well supported
in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-crypto-types.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-trust-anchors.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-keystore.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-tcp-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-ssh-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-tls-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-http-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-netconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netconf-restconf-client-server.xml"/>
</references> </references>
</references> </references>
<section anchor="change-log">
<name>Change Log</name>
<section>
<name>I-D to 00</name>
<ul spacing="normal">
<li>Removed groupings and notifications.</li>
<li>Added typedefs for identityrefs.</li>
<li>Added typedefs for other RFC 5280 structures.</li>
<li>Added typedefs for other RFC 5652 structures.</li>
<li>Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652.</
li>
</ul>
</section>
<section>
<name>00 to 01</name>
<ul spacing="normal">
<li>Moved groupings from the draft-ietf-netconf-keystore here.</li>
</ul>
</section>
<section>
<name>01 to 02</name>
<ul spacing="normal">
<li>Removed unwanted "mandatory" and "must" statements.</li>
<li>Added many new crypto algorithms (thanks Haiguang!)</li>
<li>Clarified in asymmetric-key-pair-with-certs-grouping,
in certificates/certificate/name/description, that
if the name MUST NOT match the name of a certificate
that exists independently in &lt;operational&gt;, enabling
certs installed by the manufacturer (e.g., an IDevID).</li>
</ul>
</section>
<section>
<name>02 to 03</name>
<ul spacing="normal">
<li>renamed base identity 'asymmetric-key-encryption-algorithm' to 'as
ymmetric-key-algorithm'.</li>
<li>added new 'asymmetric-key-algorithm' identities for secp192r1, sec
p224r1, secp256r1,
secp384r1, and secp521r1.</li>
<li>removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes-19
2-ccm, mac-aes-256-ccm,
mac-aes-128-gcm, mac-aes-192-gcm, mac-aes-256-gcm, and mac-chac
ha20-poly1305.</li>
<li>for all -cbc and -ctr identities, renamed base identity 'symmetric
-key-encryption-algorithm'
to 'encryption-algorithm'.</li>
<li>for all -ccm and -gcm identities, renamed base identity 'symmetric
-key-encryption-algorithm'
to 'encryption-and-mac-algorithm' and renamed the identity to r
emove the "enc-" prefix.</li>
<li>for all the 'signature-algorithm' based identities, renamed from '
rsa-*' to 'rsassa-*'.</li>
<li>removed all of the "x509v3-" prefixed 'signature-algorithm' based
identities.</li>
<li>added 'key-exchange-algorithm' based identities for 'rsaes-oaep' a
nd 'rsaes-pkcs1-v1_5'.</li>
<li>renamed typedef 'symmetric-key-encryption-algorithm-ref' to 'symme
tric-key-algorithm-ref'.</li>
<li>renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 'asym
metric-key-algorithm-ref'.</li>
<li>added typedef 'encryption-and-mac-algorithm-ref'.</li>
<li>Updated copyright date, boilerplate template, affiliation, and fol
ding algorithm.</li>
</ul>
</section>
<section>
<name>03 to 04</name>
<ul spacing="normal">
<li>ran YANG module through formatter.</li>
</ul>
</section>
<section>
<name>04 to 05</name>
<ul spacing="normal">
<li>fixed broken symlink causing reformatted YANG module to not show.<
/li>
</ul>
</section>
<section>
<name>05 to 06</name>
<ul spacing="normal">
<li>Added NACM annotations.</li>
<li>Updated Security Considerations section.</li>
<li>Added 'asymmetric-key-pair-with-cert-grouping' grouping.</li>
<li>Removed text from 'permanently-hidden' enum regarding
such keys not being backed up or restored.</li>
<li>Updated the boilerplate text in module-level "description"
statement to match copyeditor convention.</li>
<li>Added an explanation to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements as for why the
nodes are not mandatory (e.g., because they may exist only
in &lt;operational&gt;.</li>
<li>Added 'must' expressions to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements ensuring sibling
nodes are either all exist or do not all exist.</li>
<li>Added an explanation to the 'permanently-hidden' that the
value cannot be configured directly by clients and servers
MUST fail any attempt to do so.</li>
<li>Added 'trust-anchor-certs-grouping' and 'end-entity-certs-grouping
'
(the plural form of existing groupings).</li>
<li>Now states that keys created in &lt;operational&gt; by the
*-hidden-key actions are bound to the lifetime of the parent
'config true' node, and that subsequent invocations of either
action results in a failure.</li>
</ul>
</section>
<section>
<name>06 to 07</name>
<ul spacing="normal">
<li>Added clarifications that implementations SHOULD assert that
configured certificates contain the matching public key.</li>
<li>Replaced the 'generate-hidden-key' and 'install-hidden-key' action
s
with special 'crypt-hash' -like input/output values.</li>
</ul>
</section>
<section>
<name>07 to 08</name>
<ul spacing="normal">
<li>Removed the 'generate-key and 'hidden-key' features.</li>
<li>Added grouping symmetric-key-grouping</li>
<li>Modified 'asymmetric-key-pair-grouping' to have a 'choice'
statement for the keystone module to augment into, as well
as replacing the 'union' with leafs (having different NACM
settings.</li>
</ul>
</section>
<section>
<name>08 to 09</name>
<ul spacing="normal">
<li>Converting algorithm from identities to enumerations.</li>
</ul>
</section>
<section>
<name>09 to 10</name>
<ul spacing="normal">
<li>All the below changes are to the algorithm enumerations defined in
ietf-crypto-types.</li>
<li>Add in support for key exchange over x.25519 and x.448 based on RF
C 8418.</li>
<li>Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512</l
i>
<li>Revise/add in enum of signature algorithm for x25519 and x448</li>
<li>Add in des3-cbc-sha1 for IPSec</li>
<li>Add in sha1-des3-kd for IPSec</li>
<li>Add in definit for rc4-hmac and rc4-hmac-exp. These two algorithm
s have been deprecated in RFC 8429. But some existing draft in i2nsf may still w
ant to use them.</li>
<li>Add x25519 and x448 curve for asymmetric algorithms</li>
<li>Add signature algorithms ed25519, ed25519-cts, ed25519ph</li>
<li>add signature algorithms ed448, ed448ph</li>
<li>Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332)</
li>
</ul>
</section>
<section>
<name>10 to 11</name>
<ul spacing="normal">
<li>Added a "key-format" identity.</li>
<li>Added symmetric keys to the example in <xref target="crypto-types-
examples"/>.</li>
</ul>
</section>
<section>
<name>11 to 12</name>
<ul spacing="normal">
<li>Removed all non-essential (to NC/RC) algorithm types.</li>
<li>Moved remaining algorithm types each into its own module.</li>
<li>Added a 'config false' "algorithms-supported" list to each of the
algorithm-type modules.</li>
</ul>
</section>
<section>
<name>12 to 13</name>
<ul spacing="normal">
<li>Added the four features: "[encrypted-]one-[a]symmetric-key-format"
, each protecting a 'key-format' identity of the same name.</li>
<li>Added 'must' expressions asserting that the 'key-format' leaf exis
ts whenever a non-hidden key is specified.</li>
<li>Improved the 'description' statements and added 'reference' statem
ents for the 'key-format' identities.</li>
<li>Added a questionable forward reference to "encrypted-*" leafs in a
couple 'when' expressions.</li>
<li>Did NOT move "config false" alg-supported lists to SSH/TLS drafts.
</li>
</ul>
</section>
<section>
<name>13 to 14</name>
<ul spacing="normal">
<li>Resolved the "FIXME: forward ref" issue by modulating 'must', 'whe
n', and 'mandatory' expressions.</li>
<li>Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' ac
tions from ietf-keystore to
ietf-crypto-types, now as RPCs.</li>
<li>Cleaned up various description statements and removed lingering FI
XMEs.</li>
<li>Converted the "iana-&lt;alg-type&gt;-algs" YANG modules to IANA re
gistries with
instructions for how to generate modules from the registries, wh
enever they may
be updated.</li>
</ul>
</section>
<section>
<name>14 to 15</name>
<ul spacing="normal">
<li>Removed the IANA-maintained registries for symmetric, asymmetric,
and hash algorithms.</li>
<li>Removed the "generate-symmetric-key" and "generate-asymmetric-key"
RPCs.</li>
<li>Removed the "algorithm" node in the various symmetric and asymmetr
ic key groupings.</li>
<li>Added 'typedef csr' and 'feature certificate-signing-request-gener
ation'.</li>
<li>Refined a usage of "end-entity-cert-grouping" to make the "cert" n
ode mandatory true.</li>
<li>Added a "Note to Reviewers" note to first page.</li>
</ul>
</section>
<section>
<name>15 to 16</name>
<ul spacing="normal">
<li>Updated draft title (refer to "Groupings" too).</li>
<li>Removed 'end-entity-certs-grouping' as it wasn't being used anywhe
re.</li>
<li>Removed 'trust-anchor-certs-grouping' as it was no longer being us
ed
after modifying 'inline-or-truststore-certs-grouping' to use lis
ts (not
leaf-lists).</li>
<li>Renamed "cert" to "cert-data" in trust-anchor-cert-grouping.</li>
<li>Added "csr-info" typedef, to complement the existing "csr" typedef
.</li>
<li>Added "ocsp-request" and "ocsp-response" typedefs, to complement
the existing "crl" typedef.</li>
<li>Added "encrypted" cases to both symmetric-key-grouping and
asymmetric-key-pair-grouping (Moved from Keystore draft).</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>16 to 17</name>
<ul spacing="normal">
<li>[Re]-added a "Strength of Keys Configured" Security Consideration<
/li>
<li>Prefixed "cleartext-" in the "key" and "private-key" node names.</
li>
</ul>
</section>
<section>
<name>17 to 18</name>
<ul spacing="normal">
<li>Fixed issues found by the SecDir review of the "keystore" draft.</
li>
<li>Added "password-grouping", discussed during the IETF 108 session.<
/li>
</ul>
</section>
<section>
<name>18 to 19</name>
<ul spacing="normal">
<li>Added a "Unconstrained Public Key Usage" Security Consideration to
address
concern raised by SecDir of the 'truststore' draft.</li>
<li>Added a "Unconstrained Private Key Usage" Security Consideration t
o address
concern raised by SecDir of the 'truststore' draft.</li>
<li>Changed the encryption strategy, after conferring with Russ Housle
y.</li>
<li>Added a "password-grouping" example to the "crypto-types-usage" ex
ample.</li>
<li>Added an "Encrypting Passwords" section to Security Consideration.
</li>
<li>Addressed other comments raised by YANG Doctor.</li>
</ul>
</section>
<section>
<name>19 to 20</name>
<ul spacing="normal">
<li>Nits found via YANG Doctors reviews.</li>
<li>Aligned modules with `pyang -f` formatting.</li>
</ul>
</section>
<section>
<name>20 to 21</name>
<ul spacing="normal">
<li>Replaced "base64encodedvalue==" with "BASE64VALUE=".</li>
<li>Accommodated SecDir review by Valery Smyslov.</li>
</ul>
</section>
<section>
<name>21 to 22</name>
<ul spacing="normal">
<li>fixup the 'WG Web' and 'WG List' lines in YANG module(s)</li>
<li>fixup copyright (i.e., s/Simplified/Revised/) in YANG module(s)</l
i>
<li>added 'hidden-keys' feature.</li>
</ul>
</section>
<section>
<name>22 to 23</name>
<ul spacing="normal">
<li>Fixed an example to reference correct key.</li>
<li>Fixed an example to not have line-returns around the encoding for
a binary value.</li>
</ul>
</section>
<section>
<name>23 to 24</name>
<ul spacing="normal">
<li>Added mandatory leaf "csr-format" to action "generate-csr".</li>
<li>s/certificate-signing-request/csr/g in the YANG module.</li>
</ul>
</section>
<section>
<name>24 to 25</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</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 Tom Petch and AD reviews.</li>
<li>Renamed numerous "feature" statements and some "grouping" statemen
ts (in YANG)</li>
<li>Added "csr-format" and "p10-csr-format" identities to doc (they we
re already in YANG)</li>
<li>Clarified that the 'rsa-private-key-format' and 'ec-private-key-fo
rmat' formats must be encoded using DER</li>
<li>Added 'if-feature cleartext-passwords' statement to 'case cleartex
t-password' in grouping 'password-grouping'.</li>
<li>Added 'if-feature cleartext-keys' statement to 'case cleartext-key
' in grouping 'symmetric-key-grouping'.</li>
<li>Added 'if-feature cleartext-cleartext-private-keys' statement to '
case cleartext-private-key' in grouping 'asymmetric-key-grouping'.</li>
<li>Updated Section titles.</li>
<li>Clarified Security Considerations about the "generate-public-key"
RPCs.</li>
</ul>
</section>
<section>
<name>27 to 28</name>
<ul spacing="normal">
<li>Mostly addresses AD review comments.</li>
<li>Also addresses on-list comment regarding public-keys being "mandat
ory true."</li>
<li>Added note to Editor to fix line foldings.</li>
<li>Factored 'private-key-grouping' from 'asymmetric-key-pair-grouping
'.</li>
<li>Made public-key in 'asymmetric-key-pair-grouping' be "mandatory fa
lse".</li>
<li>Renamed 'encrypted-by-choice-grouping' to 'encrypted-by-grouping'.
</li>
</ul>
</section>
<section>
<name>28 to 29</name>
<ul spacing="normal">
<li>Addresses Gen-ART review by Dale Worley.</li>
<li>Addresses review by Tom Petch.</li>
</ul>
</section>
<section>
<name>29 to 30</name>
<ul spacing="normal">
<li>Addresses 1st-round of IESG reviews.</li>
</ul>
</section>
<section>
<name>30 to 32</name>
<ul spacing="normal">
<li>Addresses issues found in OpsDir of the ssh-client-server draft.</
li>
<li>Removed "Strength of Keys Conveyed" section.</li>
<li>Renamed Security Considerations section s/Template for/Considerati
ons for/</li>
<li>Improved Security Consideration for 'cert-data' node.</li>
</ul>
</section>
<section>
<name>32 to 34</name>
<ul spacing="normal">
<li>Nothing changed. Only bumped for automation...</li>
</ul>
</section>
</section>
<section numbered="false"> <section numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors 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):
Balázs Kovács, <contact fullname="Balázs Kovács"/>,
Carsten Bormann, <contact fullname="Carsten Bormann"/>,
Dale Worley, <contact fullname="Dale Worley"/>,
Eric Voit, <contact fullname="Eric Voit"/>,
Éric Vyncke, <contact fullname="Éric Vyncke"/>,
Francesca Palombini, <contact fullname="Francesca Palombini"/>,
Jürgen Schönwälder, <contact fullname="Jürgen Schönwälder"/>,
Lars Eggert, <contact fullname="Lars Eggert"/>,
Liang Xia, <contact fullname="Liang Xia"/>,
Martin Björklund, <contact fullname="Mahesh Jethanandani"/>,
Mahesh Jethanandani, <contact fullname="Martin Björklund"/>,
Murray Kucherawy, <contact fullname="Murray Kucherawy"/>,
Nick Hancock, <contact fullname="Nick Hancock"/>,
Orie Steele, <contact fullname="Orie Steele"/>,
Paul Wouters, <contact fullname="Paul Wouters"/>,
Rich Salz, <contact fullname="Rich Salz"/>,
Rifaat Shekh-Yusef, <contact fullname="Rifaat Shekh-Yusef"/>,
Rob Wilton, <contact fullname="Rob Wilton"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Russ Housley, <contact fullname="Russ Housley"/>,
Sandra Murphy, <contact fullname="Sandra Murphy"/>,
Tom Petch, <contact fullname="Tom Petch"/>,
Valery Smyslov, <contact fullname="Valery Smyslov"/>,
Wang Haiguang, <contact fullname="Wang Haiguang"/>,
Warren Kumari, <contact fullname="Warren Kumari"/>,
and Zaheduzzaman Sarker. and <contact fullname="Zaheduzzaman Sarker"/>.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 219 change blocks. 
1369 lines changed or deleted 557 lines changed or added

This html diff was produced by rfcdiff 1.48.