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 " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?rfc toc="yes"?> | ||||
<?rfc symrefs="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" | |||
<?rfc sortrefs="yes" ?> | 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> | |||
<!--[rfced] FYI, five of the documents in Cluster 463 will move to AUTH48 | ||||
at this time; the rest of the documents as well as any cluster-wide | ||||
questions are expected to be available in the coming week. | ||||
--> | ||||
<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="August" 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> --> 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> --> 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 133 ¶ | skipping to change at line 84 ¶ | |||
| | | | | | | | | | | | | | |||
| +-----------|--------|--------------+ | | | | +-----------|--------|--------------+ | | | |||
| | | | | | | | | | | | | | |||
+-----------+ | | | | | | +-----------+ | | | | | | |||
| | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | |||
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? --> | <!-- 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 142 ¶ | |||
<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 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" target="RFC7950"/>). This | |||
placeholder value is used because real base64 encoded structures | 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> | |||
</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 234 ¶ | |||
| +-- 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 318 ¶ | |||
<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 icate-signing-request" | <li>This grouping's only purpose is to define the "generate-certif icate-signing-request" | |||
action statement, used by the groupings defined in <xref targe | action statement, used by the groupings defined in Sections <x | |||
t="asymmetric-key-pair-with-cert-grouping"/> | ref target="asymmetric-key-pair-with-cert-grouping" format="counter"/> | |||
and <xref target="asymmetric-key-pair-with-certs-grouping"/>.< | and <xref target="asymmetric-key-pair-with-certs-grouping" for | |||
/li> | mat="counter"/>.</li> | |||
<li>This action takes as input a "csr-info" type and returns a | <li>This action takes as input a "csr-info" type and returns a | |||
"csr" type, both of which are discussed in <xref target="typed efs"/>.</li> | "csr" type, both of which are discussed in <xref target="typed efs"/>.</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 779 ¶ | |||
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 803 ¶ | |||
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 845 ¶ | |||
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 924 ¶ | |||
+--:(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 1044 ¶ | |||
<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-certificate-signing-request" Action</name> | |||
<t>The following example illustrates the "generate-certificate-signing -request" | <t>The following example illustrates the "generate-certificate-signing -request" | |||
action, discussed in <xref target="generate-csr-grouping"/>, with the NETCONF protocol.</t> | action, discussed in <xref target="generate-csr-grouping"/>, with 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 1108 ¶ | |||
<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"><CODE BEGINS> 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 1150 ¶ | |||
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 1323 ¶ | |||
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 1465 ¶ | |||
} | } | |||
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 1779 ¶ | |||
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 1833 ¶ | |||
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 1914 ¶ | |||
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 1938 ¶ | |||
"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 1972 ¶ | |||
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 2054 ¶ | |||
} | } | |||
} | } | |||
} | } | |||
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 2129 ¶ | |||
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 2182 ¶ | |||
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 2230 ¶ | |||
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"><CODE ENDS></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-certificate-signing-request" 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 rget="RFC8407"/>.</t> | <t>This section is modeled after the template defined in <xref section=" 3.7.1" target="RFC8407"/>.</t> | |||
<t>The YANG module in this document defines "grouping" statements | <t>The YANG module in this document 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., SSH, TLS) | |||
with mutual authentication.</t> | with mutual authentication.</t> | |||
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> | <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 2372 ¶ | |||
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-certificate-signing-request: | |||
</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. | <!--[rfced] note for IANA: | |||
]]></artwork> | Please update comma to semicolon here. | |||
OLD: N/A, the requested URI is an XML namespace. | ||||
NEW: N/A; the requested URI is an XML namespace. | ||||
--> | ||||
</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.42 | |||
<date month="March" year="1997"/> | 53.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52 | |||
<t>In many standards track documents several words are used to sig | 80.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.56 | |||
his document defines these words as they should be interpreted in IETF documents | 52.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.5 | |||
mmunity, and requests discussion and suggestions for improvements.</t> | 915.xml"/> | |||
</abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59 | |||
</front> | 58.xml"/> | |||
<seriesInfo name="BCP" value="14"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60 | |||
<seriesInfo name="RFC" value="2119"/> | 31.xml"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 | |||
</reference> | 241.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"?> | 242.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 | ||||
ted.</t> | ||||
<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> | |||
<!--[rfced] *AD - Since RFCs 2986 and 5915 are stated as being normatively | ||||
referenced in the YANG module, we have moved their reference entries from | ||||
the Informative References section to the Normative References section. | ||||
Please review and let us know if you approve of these moves. | ||||
Original: | ||||
This module has normative references to [RFC2119], [RFC2986], | ||||
[RFC4253], [RFC5280], [RFC5652], [RFC5915], [RFC5958], [RFC6031], | ||||
[RFC6960], [RFC6991], [RFC7093], [RFC8017], [RFC8174], [RFC8341], and | ||||
[ITU.X690.2021]. | ||||
--> | ||||
<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 | 340.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> | 407.xml"/> | |||
</abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
</front> | 342.xml"/> | |||
<seriesInfo name="RFC" value="2986"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC2986"/> | <!-- [I-D.ietf-netconf-trust-anchors] IESG state: RFC Ed Queue as of 03/21/24--> | |||
</reference> | <reference anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc96 | |||
<!--<?rfc include="reference.RFC.3174.xml"?>--> | 41"> | |||
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 | <front> | |||
688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> | <title>A YANG Data Model for a Truststore</title> | |||
<front> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
<title>The IETF XML Registry</title> | <organization>Watsen Networks</organization> | |||
<author fullname="M. Mealling" initials="M." surname="Mealling"/> | </author> | |||
<date month="January" year="2004"/> | <date month="August" year="2024"/> | |||
<abstract> | </front> | |||
<t>This document describes an IANA maintained registry for IETF st | <seriesInfo name="RFC" value="9641"/> | |||
andards which use Extensible Markup Language (XML) related items such as Namespa | <seriesInfo name="DOI" value="10.17487/RFC9641"/> | |||
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew | </reference> | |||
ork (RDF) Schemas.</t> | ||||
</abstract> | <!-- [I-D.ietf-netconf-keystore] IESG state: RFC Ed Queue as of 03/21/24--> | |||
</front> | <reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9 | |||
<seriesInfo name="BCP" value="81"/> | 642"> | |||
<seriesInfo name="RFC" value="3688"/> | <front> | |||
<seriesInfo name="DOI" value="10.17487/RFC3688"/> | <title>A YANG Data Model for a Keystore and Keystore Operations</titl | |||
</reference> | e> | |||
<reference anchor="RFC4211" target="https://www.rfc-editor.org/info/rfc4 | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
211" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"> | <organization>Watsen Networks</organization> | |||
<front> | </author> | |||
<title>Internet X.509 Public Key Infrastructure Certificate Request | <date month="August" year="2024"/> | |||
Message Format (CRMF)</title> | </front> | |||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | <seriesInfo name="RFC" value="9642"/> | |||
<date month="September" year="2005"/> | <seriesInfo name="DOI" value="10.17487/RFC9642"/> | |||
<abstract> | </reference> | |||
<t>This document describes the Certificate Request Message Format | ||||
(CRMF) syntax and semantics. This syntax is used to convey a request for a certi | <!-- [I-D.ietf-netconf-tcp-client-server] IESG state: RFC Ed Queue as of 03/21/2 | |||
ficate to a Certification Authority (CA), possibly via a Registration Authority | 4--> | |||
(RA), for the purposes of X.509 certificate production. The request will typical | <reference anchor="RFC9643" target="https://www.rfc-editor.org/info/rfc9 | |||
ly include a public key and the associated registration information. This docume | 643"> | |||
nt does not define a certificate request protocol. [STANDARDS-TRACK]</t> | <front> | |||
</abstract> | <title>YANG Groupings for TCP Clients and TCP Servers</title> | |||
</front> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
<seriesInfo name="RFC" value="4211"/> | <organization>Watsen Networks</organization> | |||
<seriesInfo name="DOI" value="10.17487/RFC4211"/> | </author> | |||
</reference> | <author initials="M." surname="Scharf" fullname="Michael Scharf"> | |||
<!--<?rfc include="reference.RFC.4493.xml"?>--> | <organization>Hochschule Esslingen - University of Applied Sciences | |||
<reference anchor="RFC5056" target="https://www.rfc-editor.org/info/rfc5 | </organization> | |||
056" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5056.xml"> | </author> | |||
<front> | <date month="August" year="2024"/> | |||
<title>On the Use of Channel Bindings to Secure Channels</title> | </front> | |||
<author fullname="N. Williams" initials="N." surname="Williams"/> | <seriesInfo name="RFC" value="9643"/> | |||
<date month="November" year="2007"/> | <seriesInfo name="DOI" value="10.17487/RFC9643"/> | |||
<abstract> | </reference> | |||
<t>The concept of channel binding allows applications to establish | ||||
that the two end-points of a secure channel at one network layer are the same a | <!-- [I-D.ietf-netconf-ssh-client-server] IESG state: RFC Ed Queue as of 03/21/2 | |||
s at a higher layer by binding authentication at the higher layer to the channel | 4--> | |||
at the lower layer. This allows applications to delegate session protection to | <reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc96 | |||
lower layers, which has various performance benefits.</t> | 44"> | |||
<t>This document discusses and formalizes the concept of channel b | <front> | |||
inding to secure channels. [STANDARDS-TRACK]</t> | <title>YANG Groupings for SSH Clients and SSH Servers</title> | |||
</abstract> | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
</front> | <organization>Watsen Networks</organization> | |||
<seriesInfo name="RFC" value="5056"/> | </author> | |||
<seriesInfo name="DOI" value="10.17487/RFC5056"/> | <date month="August" year="2024"/> | |||
</reference> | </front> | |||
<reference anchor="RFC5915" target="https://www.rfc-editor.org/info/rfc5 | <seriesInfo name="RFC" value="9644"/> | |||
915" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml"> | <seriesInfo name="DOI" value="10.17487/RFC9644"/> | |||
<front> | </reference> | |||
<title>Elliptic Curve Private Key Structure</title> | ||||
<author fullname="S. Turner" initials="S." surname="Turner"/> | <!-- [I-D.ietf-netconf-tls-client-server] IESG state: RFC Ed Queue as of 03/21/2 | |||
<author fullname="D. Brown" initials="D." surname="Brown"/> | 4--> | |||
<date month="June" year="2010"/> | <reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc9 | |||
<abstract> | 645"> | |||
<t>This document specifies the syntax and semantics for conveying | <front> | |||
Elliptic Curve (EC) private key information. The syntax and semantics defined he | <title>YANG Groupings for TLS Clients and TLS Servers</title> | |||
rein are based on similar syntax and semantics defined by the Standards for Effi | <author initials="K." surname="Watsen" fullname="Kent Watsen"> | |||
cient Cryptography Group (SECG). This document is not an Internet Standards Trac | <organization>Watsen Networks</organization> | |||
k specification; it is published for informational purposes.</t> | </author> | |||
</abstract> | <date month="August" year="2024"/> | |||
</front> | </front> | |||
<seriesInfo name="RFC" value="5915"/> | <seriesInfo name="RFC" value="9645"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC5915"/> | <seriesInfo name="DOI" value="10.17487/RFC9645"/> | |||
</reference> | </reference> | |||
<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6 | ||||
020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"> | <!-- [I-D.ietf-netconf-http-client-server] IESG state: IESG Evaluation::AD Follo | |||
<front> | wup as of 8/15/24--> | |||
<title>YANG - A Data Modeling Language for the Network Configuration | <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net | |||
Protocol (NETCONF)</title> | conf-http-client-server"/> | |||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | <!-- [I-D.ietf-netconf-netconf-client-server] IESG state: AD Evaluation as of 8/ | |||
<date month="October" year="2010"/> | 15/24--> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net | |||
<t>YANG is a data modeling language used to model configuration an | conf-netconf-client-server"/> | |||
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON | ||||
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> | <!-- [I-D.ietf-netconf-restconf-client-server] IESG state: AD Evaluation as of 8 | |||
</abstract> | /15/24--> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-net | |||
<seriesInfo name="RFC" value="6020"/> | conf-restconf-client-server"/> | |||
<seriesInfo name="DOI" value="10.17487/RFC6020"/> | ||||
</reference> | ||||
<!--<?rfc include="reference.RFC.6234.xml"?>--> | ||||
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 | ||||
241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"> | ||||
<front> | ||||
<title>Network Configuration Protocol (NETCONF)</title> | ||||
<author fullname="R. Enns" initials="R." role="editor" surname="Enns | ||||
"/> | ||||
<author fullname="M. Bjorklund" initials="M." role="editor" surname= | ||||
"Bjorklund"/> | ||||
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn | ||||
ame="Schoenwaelder"/> | ||||
<author fullname="A. Bierman" initials="A." role="editor" surname="B | ||||
ierman"/> | ||||
<date month="June" year="2011"/> | ||||
<abstract> | ||||
<t>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 <operational>, 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 <operational>.</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 <operational> 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-<alg-type>-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. 218 change blocks. | ||||
1348 lines changed or deleted | 545 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |