rfc9640.original.xml   rfc9640.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY nbsp "&#160;"> nsus="true" ipr="trust200902" submissionType="IETF" docName="draft-ietf-netconf-
<!ENTITY zwsp "&#8203;"> crypto-types-34" number="9640" obsoletes="" updates="" tocInclude="true" symRefs
<!ENTITY nbhy "&#8209;"> ="true" sortRefs="true" xml:lang="en" prepTime="2024-10-10T10:00:33" indexInclud
<!ENTITY wj "&#8288;"> e="true" scripts="Common,Latin" tocDepth="3">
]> <link href="https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types-3
<?rfc toc="yes"?> 4" rel="prev"/>
<?rfc symrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc9640" rel="alternate"/>
<?rfc sortrefs="yes" ?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<!-- <?rfc-ext allow-markup-in-artwork="yes" ?> what does this do? -->
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<!--<rfc xmlns:xiax="https://watsen.net/xiax" category="std" ipr="trust200902" d
ocName="draft-ietf-netconf-crypto-types-34">-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
ipr="trust200902" submissionType="IETF" docName="draft-ietf-netconf-crypto-types
-34" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="YANG Data Types and Groupings for Crypto">YANG Data Types and Groupings for Cryptography</title> <title abbrev="YANG Data Types and Groupings for Crypto">YANG Data Types and Groupings for Cryptography</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-crypto-types-34" /> <seriesInfo name="RFC" value="9640" stream="IETF"/>
<author initials="K." surname="Watsen" fullname="Kent Watsen"> <author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization>Watsen Networks</organization> <organization showOnFrontPage="true">Watsen Networks</organization>
<address> <address>
<email>kent+ietf@watsen.net</email> <email>kent+ietf@watsen.net</email>
</address> </address>
</author> </author>
<date/> <date month="10" year="2024"/>
<area>Operations</area> <area>OPS</area>
<workgroup>NETCONF Working Group</workgroup> <workgroup>netconf</workgroup>
<abstract> <abstract pn="section-abstract">
<t>This document presents a YANG 1.1 (RFC 7950) module defining identities <t indent="0" pn="section-abstract-1">This document presents a YANG 1.1 (R
, FC 7950) module defining identities,
typedefs, and groupings useful to cryptographic applications.</t> typedefs, and groupings useful to cryptographic applications.</t>
</abstract> </abstract>
<note> <boilerplate>
<name>Editorial Note (To be removed by RFC Editor)</name> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>This draft contains placeholder values that need to be replaced "exclude" pn="section-boilerplate.1">
with finalized values at the time of publication. This note summarizes <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
all of the substitutions that are needed. No other RFC Editor >
instructions are specified elsewhere in this document.</t> <t indent="0" pn="section-boilerplate.1-1">
<t>Artwork in this document contains shorthand references to drafts in This is an Internet Standards Track document.
progress. Please apply the following replacements: </t>
</t> <t indent="0" pn="section-boilerplate.1-2">
<ul spacing="normal"> This document is a product of the Internet Engineering Task Force
<li> (IETF). It represents the consensus of the IETF community. It has
<tt>AAAA</tt> --&gt; the assigned RFC value for this draft</li> received public review and has been approved for publication by
</ul> the Internet Engineering Steering Group (IESG). Further
<t>Artwork in this document contains placeholder values for the date information on Internet Standards is available in Section 2 of
of publication of this draft. Please apply the following replacement: RFC 7841.
</t> </t>
<ul spacing="normal"> <t indent="0" pn="section-boilerplate.1-3">
<li> Information about the current status of this document, any
<tt>2024-03-16</tt> --&gt; the publication date of this draft</li> errata, and how to provide feedback on it may be obtained at
</ul> <eref target="https://www.rfc-editor.org/info/rfc9640" brackets="non
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> e"/>.
contains </t>
the text "one or more YANG modules" and, later, "modules". This text </section>
is sourced <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
from a file in a context where it is unknown how many modules a draft ude" pn="section-boilerplate.2">
defines. <name slugifiedName="name-copyright-notice">Copyright Notice</name>
The text is not wrong as is, but it may be improved by stating more di <t indent="0" pn="section-boilerplate.2-1">
rectly how Copyright (c) 2024 IETF Trust and the persons identified as the
many modules are defined.</t> document authors. All rights reserved.
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> </t>
contains <t indent="0" pn="section-boilerplate.2-2">
a self-reference to this draft, along with a corresponding reference i This document is subject to BCP 78 and the IETF Trust's Legal
n Provisions Relating to IETF Documents
the Appendix. Please replace the self-reference in this section with (<eref target="https://trustee.ietf.org/license-info" brackets="none
"This RFC" "/>) in effect on the date of
(or similar) and remove the self-reference in the "Normative/Informati publication of this document. Please review these documents
ve References" carefully, as they describe your rights and restrictions with
section, whichever it is in.</t> respect to this document. Code Components extracted from this
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined i document must include Revised BSD License text as described in
n RFC 8792. Section 4.e of the Trust Legal Provisions and are provided without
However, nicer-to-the-eye is when the '\\' line-folding mode is used. warranty as described in the Revised BSD License.
The AD suggested </t>
suggested putting a request here for the RFC Editor to help convert "u </section>
gly" '\' folded </boilerplate>
examples to use the '\\' folding mode. "Help convert" may be interpre <toc>
ted as, identify <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
what looks ugly and ask the authors to make the adjustment.</t> n="section-toc.1">
<t>The following Appendix section is to be removed prior to publication: <name slugifiedName="name-table-of-contents">Table of Contents</name>
</t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
<ul spacing="normal"> c.1-1">
<li> <li pn="section-toc.1-1.1">
<xref target="change-log"/>. Change Log</li> <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
</ul> at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
</note> ormat="title" sectionFormat="of" target="name-introduction">Introduction</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
lation-to-other-rfcs">Relation to Other RFCs</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sp
ecification-language">Specification Language</xref></t>
</li>
<li pn="section-toc.1-1.1.2.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><
xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.
3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ad
herence-to-the-nmda">Adherence to the NMDA</xref></t>
</li>
<li pn="section-toc.1-1.1.2.4">
<t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent=
"1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-conventions">Conventio
ns</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-ietf-crypto-types-modul">The "
ietf-crypto-types" Module</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent=
"2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-data-model-overview">D
ata Model Overview</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent=
"2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-example-usage">Example
Usage</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-yang-module">YANG Modu
le</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-no-support-for-crmf">N
o Support for CRMF</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-no-support-for-key-gen
erati">No Support for Key Generation</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-unconstrained-public-k
ey-us">Unconstrained Public Key Usage</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-unconstrained-private-
key-u">Unconstrained Private Key Usage</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5">
<t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent=
"3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cleartext-passwords-an
d-key">Cleartext Passwords and Keys</xref></t>
</li>
<li pn="section-toc.1-1.3.2.6">
<t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent=
"3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-encrypting-passwords-a
nd-ke">Encrypting Passwords and Keys</xref></t>
</li>
<li pn="section-toc.1-1.3.2.7">
<t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent=
"3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-deletion-of-cleartext-
key-v">Deletion of Cleartext Key Values</xref></t>
</li>
<li pn="section-toc.1-1.3.2.8">
<t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent=
"3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-considerations-for-the
-ietf">Considerations for the "ietf-crypto-types" YANG Module</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-ietf-xml-registry"
>The IETF XML Registry</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-the-yang-module-names-
regis">The YANG Module Names Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-authors-address">Author's Addres
s</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
<name>Introduction</name> <name slugifiedName="name-introduction">Introduction</name>
<t>This document presents a YANG 1.1 <xref target="RFC7950"/> <t indent="0" pn="section-1-1">This document presents a YANG 1.1 <xref tar
get="RFC7950" format="default" sectionFormat="of" derivedContent="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" numbered="true" removeInRFC="false" to
<name>Relation to other RFCs</name> c="include" pn="section-1.1">
<t>This document presents one or more YANG modules <xref target="RFC7950 <name slugifiedName="name-relation-to-other-rfcs">Relation to Other RFCs
"/> </name>
that are part of a collection of RFCs that work together <t indent="0" pn="section-1.1-1">This document presents a YANG module <x
ref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950
"/>
that is 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" format="default" sectionFormat="of" derivedContent="RFC6241"
<t> The dependency relationship between the primary YANG groupings /> and
RESTCONF <xref target="RFC8040" format="default" sectionFormat="of"
derivedContent="RFC8040"/>.</t>
<t indent="0" pn="section-1.1-2"> The dependency relationship between th
e primary YANG groupings
defined in the various RFCs is presented in the below diagram. defined in the various RFCs is presented in the below diagram.
In some cases, a draft may define secondary groupings that In some cases, a document may define secondary groupings that
introduce dependencies not illustrated in the diagram. introduce dependencies not illustrated in the diagram.
The labels in the diagram are a shorthand name for the defining The labels in the diagram are shorthand names for the defining
RFC. The citation reference for shorthand name is provided below RFCs. The citation references for 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 indent="0" pn="section-1.1-3">Please note that the arrows in the diag ram point from referencer
to referenced. For example, the "crypto-types" RFC does not to referenced. For example, the "crypto-types" RFC does not
have any dependencies, whilst the "keystore" RFC depends on the have any dependencies, whilst the "keystore" RFC depends on the
"crypto-types" RFC.</t> "crypto-types" RFC.</t>
<artwork><![CDATA[ <artwork align="center" pn="section-1.1-4">
crypto-types crypto-types
^ ^ ^ ^
/ \ / \
/ \ / \
truststore keystore truststore keystore
^ ^ ^ ^ ^ ^ ^ ^
| +---------+ | | | +---------+ | |
| | | | | | | |
| +------------+ | | +------------+ |
tcp-client-server | / | | tcp-client-server | / | |
skipping to change at line 131 skipping to change at line 205
| | | | | ^ | | | | | ^
| | | +-----+ +---------+ | | | | +-----+ +---------+ |
| | | | | | | | | | | |
| +-----------|--------|--------------+ | | | +-----------|--------|--------------+ | |
| | | | | | | | | | | |
+-----------+ | | | | | +-----------+ | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
netconf-client-server restconf-client-server netconf-client-server restconf-client-server
]]></artwork> </artwork>
<!-- RFC Editor: is there anyway to flush-left the table in PDF/HTML vie <table align="center" pn="table-1">
ws? --> <name slugifiedName="name-labels-in-diagram-to-rfc-ma">Labels in Diagr
<table> am to RFC Mapping</name>
<name>Label in Diagram to RFC Mapping</name>
<tbody> <tbody>
<tr> <tr>
<th>Label in Diagram</th> <th align="left" colspan="1" rowspan="1">Label in Diagram</th>
<th>Originating RFC</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
<tr> <tr>
<td>crypto-types</td> <td align="left" colspan="1" rowspan="1">crypto-types</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-crypto-types"/></td> RFC 9640</td>
</tr> </tr>
<tr> <tr>
<td>truststore</td> <td align="left" colspan="1" rowspan="1">truststore</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-trust-anchors"/></td> <xref target="RFC9641" format="default" sectionFormat="of" deriv
edContent="RFC9641"/></td>
</tr> </tr>
<tr> <tr>
<td>keystore</td> <td align="left" colspan="1" rowspan="1">keystore</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-keystore"/></td> <xref target="RFC9642" format="default" sectionFormat="of" deriv
edContent="RFC9642"/></td>
</tr> </tr>
<tr> <tr>
<td>tcp-client-server</td> <td align="left" colspan="1" rowspan="1">tcp-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-tcp-client-server"/></td> <xref target="RFC9643" format="default" sectionFormat="of" deriv
edContent="RFC9643"/></td>
</tr> </tr>
<tr> <tr>
<td>ssh-client-server</td> <td align="left" colspan="1" rowspan="1">ssh-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-ssh-client-server"/></td> <xref target="RFC9644" format="default" sectionFormat="of" deriv
edContent="RFC9644"/></td>
</tr> </tr>
<tr> <tr>
<td>tls-client-server</td> <td align="left" colspan="1" rowspan="1">tls-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-tls-client-server"/></td> <xref target="RFC9645" format="default" sectionFormat="of" deriv
edContent="RFC9645"/></td>
</tr> </tr>
<tr> <tr>
<td>http-client-server</td> <td align="left" colspan="1" rowspan="1">http-client-server</td>
<td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-http-client-server"/></td> <xref target="I-D.ietf-netconf-http-client-server" format="defau
lt" sectionFormat="of" derivedContent="HTTP-CLIENT-SERVER"/></td>
</tr> </tr>
<tr> <tr>
<td>netconf-client-server</td> <td align="left" colspan="1" rowspan="1">netconf-client-server</td
<td> >
<xref target="I-D.ietf-netconf-netconf-client-server"/></td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-netconf-client-server" format="de
fault" sectionFormat="of" derivedContent="NETCONF-CLIENT-SERVER"/></td>
</tr> </tr>
<tr> <tr>
<td>restconf-client-server</td> <td align="left" colspan="1" rowspan="1">restconf-client-server</t
<td> d>
<xref target="I-D.ietf-netconf-restconf-client-server"/></td> <td align="left" colspan="1" rowspan="1">
<xref target="I-D.ietf-netconf-restconf-client-server" format="d
efault" sectionFormat="of" derivedContent="RESTCONF-CLIENT-SERVER"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1.2
<name>Specification Language</name> ">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name slugifiedName="name-specification-language">Specification Language
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", </name>
"MAY", and "OPTIONAL" in this document are to be interpreted as <t indent="0" pn="section-1.2-1">
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/ The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
when, and only when, they appear in all capitals, as shown here.</t> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1.3
<name>Adherence to the NMDA</name> ">
<t>This document is compliant with the Network Management Datastore <name slugifiedName="name-adherence-to-the-nmda">Adherence to the NMDA</
Architecture (NMDA) <xref target="RFC8342"/>. It does not define name>
any protocol accessible nodes that are "config false".</t> <t indent="0" pn="section-1.3-1">This document is compliant with the Net
work Management Datastore
Architecture (NMDA) <xref target="RFC8342" format="default" sectionF
ormat="of" derivedContent="RFC8342"/>. It does not define
any protocol-accessible nodes that are "config false".</t>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-1.4
<name>Conventions</name> ">
<t>Various examples in this document use "BASE64VALUE=" as a <name slugifiedName="name-conventions">Conventions</name>
<t indent="0" pn="section-1.4-1">Various examples in this document use "
BASE64VALUE=" as a
placeholder value for binary data that has been base64 placeholder value for binary data that has been base64
encoded (per <xref section="9.8" target="RFC7950"/>). This encoded (per <xref section="9.8" sectionFormat="of" target="RFC7950"
placeholder value is used because real base64 encoded structures format="default" derivedLink="https://rfc-editor.org/rfc/rfc7950#section-9.8" d
erivedContent="RFC7950"/>). This
placeholder value is used because real base64-encoded structures
are often many lines long and hence distracting to the example are often many lines long and hence distracting to the example
being presented.</t> being presented.</t>
<t indent="0" pn="section-1.4-2">Various examples in this document use t
he XML
<xref target="W3C.REC-xml-20081126" format="default" sectionFormat="of" d
erivedContent="W3C.REC-xml-20081126"/> encoding. Other encodings, such as JSON <
xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC825
9"/>,
could alternatively be used.</t>
<t indent="0" pn="section-1.4-3">Various examples in this document conta
in long lines that may be folded,
as described in <xref target="RFC8792" format="default" sectionFormat="of" de
rivedContent="RFC8792"/>.</t>
</section> </section>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
<name>The "ietf-crypto-types" Module</name> <name slugifiedName="name-the-ietf-crypto-types-modul">The "ietf-crypto-ty
<t>This section defines a YANG 1.1 <xref target="RFC7950"/> module called pes" Module</name>
<t indent="0" pn="section-2-1">This section defines a YANG 1.1 <xref targe
t="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> modul
e called
"ietf-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 <xref target="crypto-types-overview" format="default" sectionFormat="o
le's use f" derivedContent="Section 2.1"/>. Examples illustrating the module's use
are provided in <xref target="crypto-types-examples">Examples</xref>. are provided in <xref target="crypto-types-examples" format="default"
The YANG sectionFormat="of" derivedContent="Section 2.2"/>. The YANG
module itself is defined in <xref target="crypto-types-yang-module"/>. module itself is defined in <xref target="crypto-types-yang-module" fo
</t> rmat="default" sectionFormat="of" derivedContent="Section 2.3"/>.</t>
<section anchor="crypto-types-overview"> <section anchor="crypto-types-overview" numbered="true" removeInRFC="false
<name>Data Model Overview</name> " toc="include" pn="section-2.1">
<t>This section provides an overview of the "ietf-crypto-types" module <name slugifiedName="name-data-model-overview">Data Model Overview</name
>
<t indent="0" pn="section-2.1-1">This section provides an overview of th
e "ietf-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" numbered="true" removeInRFC="fa
<name>Features</name> lse" pn="section-2.1.1">
<t>The following diagram lists all the "feature" statements <name slugifiedName="name-features">Features</name>
<t indent="0" pn="section-2.1.1-1">The following diagram lists all the
"feature" statements
defined in the "ietf-crypto-types" module:</t> defined in the "ietf-crypto-types" module:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.1-2">
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 indent="0" pn="section-2.1.1-3">The diagram above uses syntax that
<t>The diagram above uses syntax that is similar to but not is similar to but not
the same as that in <xref target="RFC8340"/>.</t> the same as that in <xref target="RFC8340" format="default" sect
<!--</aside>--> ionFormat="of" derivedContent="RFC8340"/>.</t>
</section> </section>
<section anchor="identities" toc="exclude"> <section anchor="identities" toc="exclude" numbered="true" removeInRFC="
<name>Identities</name> false" pn="section-2.1.2">
<t>The following diagram illustrates the hierarchical relationship <name slugifiedName="name-identities">Identities</name>
<t indent="0" pn="section-2.1.2-1">The following diagram illustrates t
he 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" markers="false" pn="section-2.1.2-2">
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 359
| +-- 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 indent="0" pn="section-2.1.2-3">The diagram above uses syntax that
<t>The diagram above uses syntax that is similar to but not is similar to but not
the same as that in <xref target="RFC8340"/>.</t> the same as that in <xref target="RFC8340" format="default" sect
<!--</aside>--> ionFormat="of" derivedContent="RFC8340"/>.</t>
<t>Comments:</t> <t indent="0" pn="section-2.1.2-4">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<li>The diagram shows that there are five base identities. The -2.1.2-5">
<li pn="section-2.1.2-5.1">The diagram shows that there are five bas
e 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 pn="section-2.1.2-5.2">The various terminal identities define sp ecific 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" format="default" sectionFormat="of" derivedContent="Section 1.1"/>,
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 pn="section-2.1.2-5.3">Identities used to specify uncommon forma
ts 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" numbered="true" removeInRFC="fa
<name>Typedefs</name> lse" pn="section-2.1.3">
<t>The following diagram illustrates the relationship amongst the <name slugifiedName="name-typedefs">Typedefs</name>
<t indent="0" pn="section-2.1.3-1">The following diagram illustrates t
he 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" markers="false" pn="section-2.1.3-2">
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 indent="0" pn="section-2.1.3-3">The diagram above uses syntax that
<t>The diagram above uses syntax that is similar to but not is similar to but not
the same as that in <xref target="RFC8340"/>.</t> the same as that in <xref target="RFC8340" format="default" sect
<!--</aside>--> ionFormat="of" derivedContent="RFC8340"/>.</t>
<t>Comments:</t> <t indent="0" pn="section-2.1.3-4">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<li>All the typedefs defined in the "ietf-crypto-types" module -2.1.3-5">
extend the "binary" type defined in <xref target="RFC7950"/>.</l <li pn="section-2.1.3-5.1">All the typedefs defined in the "ietf-cry
i> pto-types" module
<li>Additionally, all the typedefs define a type for encoding an ASN extend the "binary" type defined in <xref target="RFC7950" forma
.1 t="default" sectionFormat="of" derivedContent="RFC7950"/>.</li>
<xref target="ITU.X680.2021"/> structure using DER <xref target= <li pn="section-2.1.3-5.2">Additionally, all the typedefs define a t
"ITU.X690.2021"/>.</li> ype for encoding an ASN.1
<li>The "trust-anchor-*" and "end-entity-*" typedefs are syntactical <xref target="ITU.X680.2021" format="default" sectionFormat="of"
ly derivedContent="ITU.X680.2021"/> structure using DER <xref target="ITU.X690.202
1" format="default" sectionFormat="of" derivedContent="ITU.X690.2021"/>.</li>
<li pn="section-2.1.3-5.3">The "trust-anchor-*" and "end-entity-*" t
ypedefs are syntactically
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>
</ul> </ul>
</section> </section>
<section toc="exclude"> <section toc="exclude" numbered="true" removeInRFC="false" pn="section-2
<name>Groupings</name> .1.4">
<t>The "ietf-crypto-types" module defines the following "grouping" sta <name slugifiedName="name-groupings">Groupings</name>
tements:</t> <t indent="0" pn="section-2.1.4-1">The "ietf-crypto-types" module defi
<ul spacing="compact"> nes the following "grouping" statements:</t>
<li>encrypted-value-grouping</li> <ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio
<li>password-grouping</li> n-2.1.4-2">
<li>symmetric-key-grouping</li> <li pn="section-2.1.4-2.1">encrypted-value-grouping</li>
<li>public-key-grouping</li> <li pn="section-2.1.4-2.2">password-grouping</li>
<li>private-key-grouping</li> <li pn="section-2.1.4-2.3">symmetric-key-grouping</li>
<li>asymmetric-key-pair-grouping</li> <li pn="section-2.1.4-2.4">public-key-grouping</li>
<li>certificate-expiration-grouping</li> <li pn="section-2.1.4-2.5">private-key-grouping</li>
<li>trust-anchor-cert-grouping</li> <li pn="section-2.1.4-2.6">asymmetric-key-pair-grouping</li>
<li>end-entity-cert-grouping</li> <li pn="section-2.1.4-2.7">certificate-expiration-grouping</li>
<li>generate-csr-grouping</li> <li pn="section-2.1.4-2.8">trust-anchor-cert-grouping</li>
<li>asymmetric-key-pair-with-cert-grouping</li> <li pn="section-2.1.4-2.9">end-entity-cert-grouping</li>
<li>asymmetric-key-pair-with-certs-grouping</li> <li pn="section-2.1.4-2.10">generate-csr-grouping</li>
<li pn="section-2.1.4-2.11">asymmetric-key-pair-with-cert-grouping</
li>
<li pn="section-2.1.4-2.12">asymmetric-key-pair-with-certs-grouping<
/li>
</ul> </ul>
<t>Each of these groupings are presented in the following subsections. <t indent="0" pn="section-2.1.4-3">Each of these groupings are present
</t> ed in the following subsections.</t>
<section anchor="encrypted-value-grouping"> <section anchor="encrypted-value-grouping" numbered="true" removeInRFC
<name>The "encrypted-value-grouping" Grouping</name> ="false" toc="exclude" pn="section-2.1.4.1">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-encrypted-value-groupin">The "encrypte
he d-value-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.1-1">The following tree diagram <xre
f target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/
> illustrates the
"encrypted-value-grouping" grouping:</t> "encrypted-value-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.4.1-2">
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 indent="0" pn="section-2.1.4.1-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "encrypted-by" node is an empty container (difficult to on-2.1.4.1-4">
see in the diagram) that a consuming module MUST augment key <li pn="section-2.1.4.1-4.1">The "encrypted-by" node is an empty c
ontainer (difficult to
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" format="default" sectionFormat="of" de rivedContent="Section 2.2.1"/> 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 pn="section-2.1.4.1-4.2">
<t>The "encrypted-value" node is the value, encrypted by the <t indent="0" pn="section-2.1.4.1-4.2.1">The "encrypted-value" n
key referenced by the "encrypted-by" node, and encoded in ode is the value encrypted by the
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 bare="false" empty="false" indent="3" spacing="normal" pn="s
<li>If the value is encrypted by a symmetric key, then the ection-2.1.4.1-4.2.2">
<li pn="section-2.1.4.1-4.2.2.1">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 pn="section-2.1.4.1-4.2.2.2">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 indent="0" pn="section-2.1.4.1-4.2.3">See <xref target="ident ities" format="default" sectionFormat="of" derivedContent="Section 2.1.2"/> 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" numbered="true" removeInRFC="false
<name>The "password-grouping" Grouping</name> " toc="exclude" pn="section-2.1.4.2">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-password-grouping-group">The "password
ustrating the -grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.2-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.2-2">
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 indent="0" pn="section-2.1.4.2-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "password-grouping" enables configuration of credentials n on-2.1.4.2-4">
eeded to <li pn="section-2.1.4.2-4.1">The "password-grouping" enables the c
authenticate to a remote system. The 'ianach:crypt-hash' type onfiguration of credentials needed to
def from authenticate to a remote system. The "ianach:crypt-hash" type
<xref target="RFC7317"/> should be used instead when needing t def from
o <xref target="RFC7317" format="default" sectionFormat="of" der
configure a password to authencate a local account.</li> ivedContent="RFC7317"/> should be used instead when needing to
<li> configure a password to authenticate a local account.</li>
<t>For the referenced grouping statement(s): <li pn="section-2.1.4.2-4.2">
<t indent="0" pn="section-2.1.4.2-4.2.1">For the referenced "gro
uping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "encrypted-value-grouping" grouping is discussed in ection-2.1.4.2-4.2.2">
<xref target="encrypted-value-grouping"/>.</li> <li pn="section-2.1.4.2-4.2.2.1">The "encrypted-value-grouping
" grouping is discussed in
<xref target="encrypted-value-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.1"/>.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-2.1.4.2-4.3">
<t>The "choice" statement enables the password data to be cleart <t indent="0" pn="section-2.1.4.2-4.3.1">The "choice" statement
ext or enables the password data to be cleartext or
encrypted, as follows: encrypted, as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "cleartext-password" node can encode any cleartext val ection-2.1.4.2-4.3.2">
ue.</li> <li pn="section-2.1.4.2-4.3.2.1">The "cleartext-password" node
<li>The "encrypted-password" node's structure is discussed in can encode any cleartext value.</li>
<xref target="encrypted-value-grouping"/>.</li> <li pn="section-2.1.4.2-4.3.2.2">The "encrypted-password" node
is an instance of the "encrypted-value-grouping" discussed in
<xref target="encrypted-value-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.1"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="symmetric-key-grouping"> <section anchor="symmetric-key-grouping" numbered="true" removeInRFC="
<name>The "symmetric-key-grouping" Grouping</name> false" toc="exclude" pn="section-2.1.4.3">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-symmetric-key-grouping-">The "symmetri
ustrating the c-key-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.3-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.3-2">
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 indent="0" pn="section-2.1.4.3-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li> on-2.1.4.3-4">
<t>For the referenced grouping statement(s): <li pn="section-2.1.4.3-4.1">
<t indent="0" pn="section-2.1.4.3-4.1.1">For the referenced "gro
uping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "encrypted-value-grouping" grouping is discussed in ection-2.1.4.3-4.1.2">
<xref target="encrypted-value-grouping"/>.</li> <li pn="section-2.1.4.3-4.1.2.1">The "encrypted-value-grouping
" grouping is discussed in
<xref target="encrypted-value-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.1"/>.</li>
</ul> </ul>
</li> </li>
<li>The "key-format" node is an identity-reference to the "symmetr <li pn="section-2.1.4.3-4.2">The "key-format" node is an identity-
ic-key-format" reference to the "symmetric-key-format"
abstract base identity discussed in <xref target="identities"/ abstract base identity discussed in <xref target="identities"
>, format="default" sectionFormat="of" derivedContent="Section 2.1.2"/>,
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 pn="section-2.1.4.3-4.3">
<t>The "choice" statement enables the private key data to be cle <t indent="0" pn="section-2.1.4.3-4.3.1">The "choice" statement
artext, enables the private key data to be cleartext,
encrypted, or hidden, as follows: encrypted, or hidden, as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "cleartext-symmetric-key" node can encode any cleartex ection-2.1.4.3-4.3.2">
t key value.</li> <li pn="section-2.1.4.3-4.3.2.1">The "cleartext-symmetric-key"
<li>The "hidden-symmetric-key" node is of type "empty" as the node can encode any cleartext key value.</li>
real <li pn="section-2.1.4.3-4.3.2.2">The "hidden-symmetric-key" no
de 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 <li pn="section-2.1.4.3-4.3.2.3">The "encrypted-symmetric-key"
d in node's structure is discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.1"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="public-key-grouping"> <section anchor="public-key-grouping" numbered="true" removeInRFC="fal
<name>The "public-key-grouping" Grouping</name> se" toc="exclude" pn="section-2.1.4.4">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-public-key-grouping-gro">The "public-k
ustrating the ey-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.4-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.4-2">
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 indent="0" pn="section-2.1.4.4-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>The "public-key-format" node is an identity-reference to the " on-2.1.4.4-4">
public-key-format" <li pn="section-2.1.4.4-4.1">The "public-key-format" node is an id
abstract base identity discussed in <xref target="identities"/ entity-reference to the "public-key-format"
>, abstract base identity discussed in <xref target="identities"
format="default" sectionFormat="of" derivedContent="Section 2.1.2"/>,
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 pn="section-2.1.4.4-4.2">The "public-key" node is the public k ey data in the selected format.
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" numbered="true" removeInRFC="fa
<name>The "private-key-grouping" Grouping</name> lse" toc="exclude" pn="section-2.1.4.5">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-private-key-grouping-gr">The "private-
ustrating the key-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.5-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.5-2">
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 indent="0" pn="section-2.1.4.5-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li> on-2.1.4.5-4">
<t>For the referenced grouping statement(s): <li pn="section-2.1.4.5-4.1">
<t indent="0" pn="section-2.1.4.5-4.1.1">For the referenced "gro
uping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "encrypted-value-grouping" grouping is discussed in ection-2.1.4.5-4.1.2">
<xref target="encrypted-value-grouping"/>.</li> <li pn="section-2.1.4.5-4.1.2.1">The "encrypted-value-grouping
" grouping is discussed in
<xref target="encrypted-value-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.1"/>.</li>
</ul> </ul>
</li> </li>
<li>The "private-key-format" node is an identity-reference to the <li pn="section-2.1.4.5-4.2">The "private-key-format" node is an i
"private-key-format" dentity-reference to the "private-key-format"
abstract base identity discussed in <xref target="identities abstract base identity discussed in <xref target="identities
"/>, " format="default" sectionFormat="of" derivedContent="Section 2.1.2"/>,
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 pn="section-2.1.4.5-4.3">
<t>The "choice" statement enables the private key data to be cle <t indent="0" pn="section-2.1.4.5-4.3.1">The "choice" statement
artext, enables the private key data to be cleartext,
encrypted, or hidden, as follows: encrypted, or hidden, as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "cleartext-private-key" node can encode any cleartext ection-2.1.4.5-4.3.2">
key value.</li> <li pn="section-2.1.4.5-4.3.2.1">The "cleartext-private-key" n
<li>The "hidden-private-key" node is of type "empty" as the re ode can encode any cleartext key value.</li>
al <li pn="section-2.1.4.5-4.3.2.2">The "hidden-private-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-private-key" node's structure is discussed <li pn="section-2.1.4.5-4.3.2.3">The "encrypted-private-key" n
in ode's structure is discussed in
<xref target="encrypted-value-grouping"/>.</li> <xref target="encrypted-value-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.1"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="asymmetric-key-pair-grouping"> <section anchor="asymmetric-key-pair-grouping" numbered="true" removeI
<name>The "asymmetric-key-pair-grouping" Grouping</name> nRFC="false" toc="exclude" pn="section-2.1.4.6">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-asymmetric-key-pair-gro">The "asymmetr
ustrating the ic-key-pair-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.6-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.6-2">
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 indent="0" pn="section-2.1.4.6-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li> on-2.1.4.6-4">
<t>For the referenced grouping statement(s): <li pn="section-2.1.4.6-4.1">
<t indent="0" pn="section-2.1.4.6-4.1.1">For the referenced "gro
uping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "public-key-grouping" grouping is discussed in ection-2.1.4.6-4.1.2">
<xref target="public-key-grouping"/>.</li> <li pn="section-2.1.4.6-4.1.2.1">The "public-key-grouping" gro
<li>The "private-key-grouping" grouping is discussed in uping is discussed in
<xref target="private-key-grouping"/>.</li> <xref target="public-key-grouping" format="default" sectio
nFormat="of" derivedContent="Section 2.1.4.4"/>.</li>
<li pn="section-2.1.4.6-4.1.2.2">The "private-key-grouping" gr
ouping is discussed in
<xref target="private-key-grouping" format="default" secti
onFormat="of" derivedContent="Section 2.1.4.5"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="certificate-expiration-grouping"> <section anchor="certificate-expiration-grouping" numbered="true" remo
<name>The "certificate-expiration-grouping" Grouping</name> veInRFC="false" toc="exclude" pn="section-2.1.4.7">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-certificate-expiration-">The "certific
he ate-expiration-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.7-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating the
"certificate-expiration-grouping" grouping:</t> "certificate-expiration-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.4.7-2">
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 indent="0" pn="section-2.1.4.7-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>This grouping's only purpose is to define the "certificate-exp on-2.1.4.7-4">
iration" <li pn="section-2.1.4.7-4.1">This grouping's only purpose is to de
notification statement, used by the groupings defined in fine the "certificate-expiration"
<xref target="trust-anchor-cert-grouping"/> and notification statement, used by the groupings defined in Secti
<xref target="end-entity-cert-grouping"/>.</li> ons
<li>The "certificate-expiration" notification enables servers to <xref target="trust-anchor-cert-grouping" format="counter" sec
tionFormat="of" derivedContent="2.1.4.8"/> and
<xref target="end-entity-cert-grouping" format="counter" secti
onFormat="of" derivedContent="2.1.4.9"/>.</li>
<li pn="section-2.1.4.7-4.2">The "certificate-expiration" notifica
tion 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 pn="section-2.1.4.7-4.3">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 pn="section-2.1.4.7-4.4">Identification of the certificate tha t 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" format="default" sectionForma t="of" derivedContent="Section 2.2.3"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="trust-anchor-cert-grouping"> <section anchor="trust-anchor-cert-grouping" numbered="true" removeInR
<name>The "trust-anchor-cert-grouping" Grouping</name> FC="false" toc="exclude" pn="section-2.1.4.8">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-trust-anchor-cert-group">The "trust-an
ustrating the chor-cert-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.8-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.8-2">
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 indent="0" pn="section-2.1.4.8-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li> on-2.1.4.8-4">
<t>For the referenced grouping statement(s): <li pn="section-2.1.4.8-4.1">
<t indent="0" pn="section-2.1.4.8-4.1.1">For the referenced "gro
uping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "certificate-expiration-grouping" grouping is discusse ection-2.1.4.8-4.1.2">
d in <li pn="section-2.1.4.8-4.1.2.1">The "certificate-expiration-g
<xref target="certificate-expiration-grouping"/>.</li> rouping" grouping is discussed in
<xref target="certificate-expiration-grouping" format="def
ault" sectionFormat="of" derivedContent="Section 2.1.4.7"/>.</li>
</ul> </ul>
</li> </li>
<li>The "cert-data" node contains a chain of one or more certifica <li pn="section-2.1.4.8-4.2">The "cert-data" node contains a chain
tes of one or more certificates
containing at most one self-signed certificates (the "root" ce containing at most one self-signed certificate (the "root" cer
rtificate), tificate),
encoded using a "signed-data-cms" typedef discussed in <xref t encoded using a "signed-data-cms" typedef discussed in <xref t
arget="typedefs"/>.</li> arget="typedefs" format="default" sectionFormat="of" derivedContent="Section 2.1
.3"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="end-entity-cert-grouping"> <section anchor="end-entity-cert-grouping" numbered="true" removeInRFC
<name>The "end-entity-cert-grouping" Grouping</name> ="false" toc="exclude" pn="section-2.1.4.9">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-end-entity-cert-groupin">The "end-enti
ustrating the ty-cert-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.9-1">This section presents a tree di
agram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent=
"RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.9-2">
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 indent="0" pn="section-2.1.4.9-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li> on-2.1.4.9-4">
<t>For the referenced grouping statement(s): <li pn="section-2.1.4.9-4.1">
<t indent="0" pn="section-2.1.4.9-4.1.1">For the referenced "gro
uping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "certificate-expiration-grouping" grouping is discusse ection-2.1.4.9-4.1.2">
d in <li pn="section-2.1.4.9-4.1.2.1">The "certificate-expiration-g
<xref target="certificate-expiration-grouping"/>.</li> rouping" grouping is discussed in
<xref target="certificate-expiration-grouping" format="def
ault" sectionFormat="of" derivedContent="Section 2.1.4.7"/>.</li>
</ul> </ul>
</li> </li>
<li>The "cert-data" node contains a chain of one or more certifica <li pn="section-2.1.4.9-4.2">The "cert-data" node contains a chain
tes of one or more certificates
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" format="default"
sectionFormat="of" derivedContent="Section 2.1.3"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="generate-csr-grouping"> <section anchor="generate-csr-grouping" numbered="true" removeInRFC="f
<name>The "generate-csr-grouping" Grouping</name> alse" toc="exclude" pn="section-2.1.4.10">
<t>The following tree diagram <xref target="RFC8340"/> illustrates t <name slugifiedName="name-the-generate-csr-grouping-g">The "generate
he -csr-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.10-1">This section presents a tree d
iagram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent
="RFC8340"/> illustrating the
"generate-csr-grouping" grouping:</t> "generate-csr-grouping" grouping:</t>
<artwork><![CDATA[ <sourcecode type="yangtree" markers="false" pn="section-2.1.4.10-2">
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 indent="0" pn="section-2.1.4.10-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>This grouping's only purpose is to define the "generate-certif on-2.1.4.10-4">
icate-signing-request" <li pn="section-2.1.4.10-4.1">This grouping's only purpose is to d
action statement, used by the groupings defined in <xref targe efine the "generate-csr"
t="asymmetric-key-pair-with-cert-grouping"/> action statement, used by the groupings defined in Sections <x
and <xref target="asymmetric-key-pair-with-certs-grouping"/>.< ref target="asymmetric-key-pair-with-cert-grouping" format="counter" sectionForm
/li> at="of" derivedContent="2.1.4.11"/>
<li>This action takes as input a "csr-info" type and returns a and <xref target="asymmetric-key-pair-with-certs-grouping" for
"csr" type, both of which are discussed in <xref target="typed mat="counter" sectionFormat="of" derivedContent="2.1.4.12"/>.</li>
efs"/>.</li> <li pn="section-2.1.4.10-4.2">This action takes two input paramete
<li>For an example, please see <xref target="gcsr-action"/>.</li> rs: a "csr-info" parameter, for what content should be in the certificate, and a
"csr-format" parameter, for what CSR format to return. The action returns the
CSR in the specified format. Both the "csr-info" and "csr" types are discussed
in <xref target="typedefs" format="default" sectionFormat="of" derivedContent="S
ection 2.1.3"/>.</li>
<li pn="section-2.1.4.10-4.3">For an example, please see <xref tar
get="gcsr-action" format="default" sectionFormat="of" derivedContent="Section 2.
2.2"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="asymmetric-key-pair-with-cert-grouping"> <section anchor="asymmetric-key-pair-with-cert-grouping" numbered="tru
<name>The "asymmetric-key-pair-with-cert-grouping" Grouping</name> e" removeInRFC="false" toc="exclude" pn="section-2.1.4.11">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-asymmetric-key-pair-wit">The "asymmetr
ustrating the ic-key-pair-with-cert-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.11-1">This section presents a tree d
iagram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent
="RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.11-2">
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 indent="0" pn="section-2.1.4.11-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>This grouping defines an asymmetric key with at most one assoc on-2.1.4.11-4">
iated <li pn="section-2.1.4.11-4.1">This grouping defines an asymmetric
key with at most one associated
certificate, a commonly needed combination in protocol models. </li> certificate, a commonly needed combination in protocol models. </li>
<li> <li pn="section-2.1.4.11-4.2">
<t>For the referenced grouping statement(s): <t indent="0" pn="section-2.1.4.11-4.2.1">For the referenced "gr
ouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "asymmetric-key-pair-grouping" grouping is discussed i ection-2.1.4.11-4.2.2">
n <li pn="section-2.1.4.11-4.2.2.1">The "asymmetric-key-pair-gro
<xref target="asymmetric-key-pair-grouping"/>.</li> uping" grouping is discussed in
<li>The "end-entity-cert-grouping" grouping is discussed in <xref target="asymmetric-key-pair-grouping" format="defaul
<xref target="end-entity-cert-grouping"/>.</li> t" sectionFormat="of" derivedContent="Section 2.1.4.6"/>.</li>
<li>The "generate-csr-grouping" grouping is discussed in <li pn="section-2.1.4.11-4.2.2.2">The "end-entity-cert-groupin
<xref target="generate-csr-grouping"/>.</li> g" grouping is discussed in
<xref target="end-entity-cert-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.9"/>.</li>
<li pn="section-2.1.4.11-4.2.2.3">The "generate-csr-grouping"
grouping is discussed in
<xref target="generate-csr-grouping" format="default" sect
ionFormat="of" derivedContent="Section 2.1.4.10"/>.</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" numbered="tr
<name>The "asymmetric-key-pair-with-certs-grouping" Grouping</name> ue" removeInRFC="false" toc="exclude" pn="section-2.1.4.12">
<t>This section presents a tree diagram <xref target="RFC8340"/> ill <name slugifiedName="name-the-asymmetric-key-pair-with">The "asymmet
ustrating the ric-key-pair-with-certs-grouping" Grouping</name>
<t indent="0" pn="section-2.1.4.12-1">This section presents a tree d
iagram <xref target="RFC8340" format="default" sectionFormat="of" derivedContent
="RFC8340"/> illustrating 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" markers="false" pn="section-2.1.4.12-2">
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 indent="0" pn="section-2.1.4.12-3">Comments:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<li>This grouping defines an asymmetric key with one or more on-2.1.4.12-4">
<li pn="section-2.1.4.12-4.1">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 pn="section-2.1.4.12-4.2">
<t>For the referenced grouping statement(s): <t indent="0" pn="section-2.1.4.12-4.2.1">For the referenced "gr
ouping" statement(s):
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="s
<li>The "asymmetric-key-pair-grouping" grouping is discussed i ection-2.1.4.12-4.2.2">
n <li pn="section-2.1.4.12-4.2.2.1">The "asymmetric-key-pair-gro
<xref target="asymmetric-key-pair-grouping"/>.</li> uping" grouping is discussed in
<li>The "end-entity-cert-grouping" grouping is discussed in <xref target="asymmetric-key-pair-grouping" format="defaul
<xref target="end-entity-cert-grouping"/>.</li> t" sectionFormat="of" derivedContent="Section 2.1.4.6"/>.</li>
<li>The "generate-csr-grouping" grouping is discussed in <li pn="section-2.1.4.12-4.2.2.2">The "end-entity-cert-groupin
<xref target="generate-csr-grouping"/>.</li> g" grouping is discussed in
<xref target="end-entity-cert-grouping" format="default" s
ectionFormat="of" derivedContent="Section 2.1.4.9"/>.</li>
<li pn="section-2.1.4.12-4.2.2.3">The "generate-csr-grouping"
grouping is discussed in
<xref target="generate-csr-grouping" format="default" sect
ionFormat="of" derivedContent="Section 2.1.4.10"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section toc="exclude"> <section toc="exclude" numbered="true" removeInRFC="false" pn="section-2
<name>Protocol-accessible Nodes</name> .1.5">
<t>The "ietf-crypto-types" module does not contain any protocol-access <name slugifiedName="name-protocol-accessible-nodes">Protocol-Accessib
ible nodes, le Nodes</name>
but the module needs to be "implemented", as described in <xref se <t indent="0" pn="section-2.1.5-1">The "ietf-crypto-types" module does
ction="5.6.5" target="RFC7950"/>, in order for the identities in not contain any protocol-accessible nodes,
<xref target="identities"/> to be defined.</t> but the module needs to be "implemented", as described in <xref se
ction="5.6.5" target="RFC7950" format="default" sectionFormat="of" derivedLink="
https://rfc-editor.org/rfc/rfc7950#section-5.6.5" derivedContent="RFC7950"/>, in
order for the identities in
<xref target="identities" format="default" sectionFormat="of" deri
vedContent="Section 2.1.2"/> to be defined.</t>
</section> </section>
</section> </section>
<section anchor="crypto-types-examples"> <section anchor="crypto-types-examples" numbered="true" removeInRFC="false
<name>Example Usage</name> " toc="include" pn="section-2.2">
<section anchor="ct-usage" toc="exclude"> <name slugifiedName="name-example-usage">Example Usage</name>
<name>The "symmetric-key-grouping", "asymmetric-key-pair-w <section anchor="ct-usage" toc="exclude" numbered="true" removeInRFC="fa
ith-certs-grouping", and "password-grouping" Groupings</name> lse" pn="section-2.2.1">
<t>The following non-normative module is constructed in order to illus <name slugifiedName="name-the-symmetric-key-grouping-a">The "symmetric
trate the -key-grouping", "asymmetric-key-pair-with-certs-grouping", and "pass
use of the "symmetric-key-grouping" (<xref target="symmetric-key-g word-grouping" Groupings</name>
rouping"/>), the <t indent="0" pn="section-2.2.1-1">The following non-normative module
"asymmetric-key-pair-with-certs-grouping" (<xref target="asymmetri is constructed in order to illustrate the
c-key-pair-with-certs-grouping"/>), use of the "symmetric-key-grouping" (<xref target="symmetric-key-g
and the "password-grouping" (<xref target="password-grouping"/>) g rouping" format="default" sectionFormat="of" derivedContent="Section 2.1.4.3"/>)
rouping statements.</t> , the
<t>Notably, this example module and associated configuration data illu "asymmetric-key-pair-with-certs-grouping" (<xref target="asymmetri
strates that c-key-pair-with-certs-grouping" format="default" sectionFormat="of" derivedConte
nt="Section 2.1.4.12"/>),
and the "password-grouping" (<xref target="password-grouping" form
at="default" sectionFormat="of" derivedContent="Section 2.1.4.2"/>) "grouping" s
tatements.</t>
<t indent="0" pn="section-2.2.1-2">Notably, this example module and as
sociated configuration data illustrates 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" numbered="true" removeInRFC="false" pn="section
<name>Example Module</name> -2.2.1.1">
<artwork><![CDATA[ <name slugifiedName="name-example-module">Example Module</name>
<sourcecode type="yang" markers="false" pn="section-2.2.1.1-1">
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&gt;"; "YANG Designer <mailto:yang.designer@example.com&gt;";
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-10-10 {
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 903
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 927
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 969
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" numbered="true" removeInRFC="false" pn="section
<name>Tree Diagram for the Example Module</name> -2.2.1.2">
<t>The tree diagram <xref target="RFC8340"/> for this example module <name slugifiedName="name-tree-diagram-for-the-exampl">Tree Diagram
follows:</t> for the Example Module</name>
<artwork><![CDATA[ <t indent="0" pn="section-2.2.1.2-1">The tree diagram <xref target="
RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/> for this
example module is as follows:</t>
<sourcecode type="yangtree" markers="false" pn="section-2.2.1.2-2">
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 1048
+--:(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" numbered="true" removeInRFC="false" pn="section
<name>Usage Example for the Example Module</name> -2.2.1.3">
<t>Finally, the following example illustrates various symmetric and <name slugifiedName="name-usage-example-for-the-examp">Usage Example
asymmetric keys for the Example Module</name>
as they might appear in configuration:</t> <t indent="0" pn="section-2.2.1.3-1">Finally, the following example
<artwork><![CDATA[ illustrates various symmetric and asymmetric keys
as they might appear in configuration.</t>
<sourcecode type="xml" markers="false" pn="section-2.2.1.3-2">
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<symmetric-keys &lt;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"&gt;
<symmetric-key> &lt;symmetric-key&gt;
<name>ex-hidden-symmetric-key</name> &lt;name&gt;ex-hidden-symmetric-key&lt;/name&gt;
<hidden-symmetric-key/> &lt;hidden-symmetric-key/&gt;
</symmetric-key> &lt;/symmetric-key&gt;
<symmetric-key> &lt;symmetric-key&gt;
<name>ex-octet-string-based-symmetric-key</name> &lt;name&gt;ex-octet-string-based-symmetric-key&lt;/name&gt;
<key-format>ct:octet-string-key-format</key-format> &lt;key-format&gt;ct:octet-string-key-format&lt;/key-format&gt;
<cleartext-symmetric-key>BASE64VALUE=</cleartext-symmetric-key> &lt;cleartext-symmetric-key&gt;BASE64VALUE=&lt;/cleartext-symmetric-key&gt;
</symmetric-key> &lt;/symmetric-key&gt;
<symmetric-key> &lt;symmetric-key&gt;
<name>ex-one-symmetric-based-symmetric-key</name> &lt;name&gt;ex-one-symmetric-based-symmetric-key&lt;/name&gt;
<key-format>ct:one-symmetric-key-format</key-format> &lt;key-format&gt;ct:one-symmetric-key-format&lt;/key-format&gt;
<cleartext-symmetric-key>BASE64VALUE=</cleartext-symmetric-key> &lt;cleartext-symmetric-key&gt;BASE64VALUE=&lt;/cleartext-symmetric-key&gt;
</symmetric-key> &lt;/symmetric-key&gt;
<symmetric-key> &lt;symmetric-key&gt;
<name>ex-encrypted-one-symmetric-based-symmetric-key</name> &lt;name&gt;ex-encrypted-one-symmetric-based-symmetric-key&lt;/name&gt;
<key-format>ct:one-symmetric-key-format</key-format> &lt;key-format&gt;ct:one-symmetric-key-format&lt;/key-format&gt;
<encrypted-symmetric-key> &lt;encrypted-symmetric-key&gt;
<encrypted-by> &lt;encrypted-by&gt;
<asymmetric-key-ref>ex-hidden-asymmetric-key</asymmetric-key\ &lt;asymmetric-key-ref&gt;ex-hidden-asymmetric-key&lt;/asymmetric-key\
-ref> -ref&gt;
</encrypted-by> &lt;/encrypted-by&gt;
<encrypted-value-format>ct:cms-enveloped-data-format</encrypte\ &lt;encrypted-value-format&gt;ct:cms-enveloped-data-format&lt;/encrypte\
d-value-format> d-value-format&gt;
<encrypted-value>BASE64VALUE=</encrypted-value> &lt;encrypted-value&gt;BASE64VALUE=&lt;/encrypted-value&gt;
</encrypted-symmetric-key> &lt;/encrypted-symmetric-key&gt;
</symmetric-key> &lt;/symmetric-key&gt;
</symmetric-keys> &lt;/symmetric-keys&gt;
<asymmetric-keys &lt;asymmetric-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"&gt;
<asymmetric-key> &lt;asymmetric-key&gt;
<name>ex-hidden-asymmetric-key</name> &lt;name&gt;ex-hidden-asymmetric-key&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public-key\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public-key\
-format> -format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
<hidden-private-key/> &lt;hidden-private-key/&gt;
<certificates> &lt;certificates&gt;
<certificate> &lt;certificate&gt;
<name>ex-hidden-asymmetric-key-cert</name> &lt;name&gt;ex-hidden-asymmetric-key-cert&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificates> &lt;/certificates&gt;
</asymmetric-key> &lt;/asymmetric-key&gt;
<asymmetric-key> &lt;asymmetric-key&gt;
<name>ex-rsa-based-asymmetric-key</name> &lt;name&gt;ex-rsa-based-asymmetric-key&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public-key\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public-key\
-format> -format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
<private-key-format>ct:rsa-private-key-format</private-key-forma\ &lt;private-key-format&gt;ct:rsa-private-key-format&lt;/private-key-forma\
t> t&gt;
<cleartext-private-key>BASE64VALUE=</cleartext-private-key> &lt;cleartext-private-key&gt;BASE64VALUE=&lt;/cleartext-private-key&gt;
<certificates> &lt;certificates&gt;
<certificate> &lt;certificate&gt;
<name>ex-cert</name> &lt;name&gt;ex-cert&lt;/name&gt;
<cert-data>BASE64VALUE=</cert-data> &lt;cert-data&gt;BASE64VALUE=&lt;/cert-data&gt;
</certificate> &lt;/certificate&gt;
</certificates> &lt;/certificates&gt;
</asymmetric-key> &lt;/asymmetric-key&gt;
<asymmetric-key> &lt;asymmetric-key&gt;
<name>ex-one-asymmetric-based-asymmetric-key</name> &lt;name&gt;ex-one-asymmetric-based-asymmetric-key&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public-key\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public-key\
-format> -format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
<private-key-format>ct:one-asymmetric-key-format</private-key-fo\ &lt;private-key-format&gt;ct:one-asymmetric-key-format&lt;/private-key-fo\
rmat> rmat&gt;
<cleartext-private-key>BASE64VALUE=</cleartext-private-key> &lt;cleartext-private-key&gt;BASE64VALUE=&lt;/cleartext-private-key&gt;
</asymmetric-key> &lt;/asymmetric-key&gt;
<asymmetric-key> &lt;asymmetric-key&gt;
<name>ex-encrypted-rsa-based-asymmetric-key</name> &lt;name&gt;ex-encrypted-rsa-based-asymmetric-key&lt;/name&gt;
<public-key-format>ct:subject-public-key-info-format</public-key\ &lt;public-key-format&gt;ct:subject-public-key-info-format&lt;/public-key\
-format> -format&gt;
<public-key>BASE64VALUE=</public-key> &lt;public-key&gt;BASE64VALUE=&lt;/public-key&gt;
<private-key-format>ct:rsa-private-key-format</private-key-forma\ &lt;private-key-format&gt;ct:rsa-private-key-format&lt;/private-key-forma\
t> t&gt;
<encrypted-private-key> &lt;encrypted-private-key&gt;
<encrypted-by> &lt;encrypted-by&gt;
<symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ &lt;symmetric-key-ref&gt;ex-encrypted-one-symmetric-based-symmetri\
c-key</symmetric-key-ref> c-key&lt;/symmetric-key-ref&gt;
</encrypted-by> &lt;/encrypted-by&gt;
<encrypted-value-format>ct:cms-encrypted-data-format</encrypte\ &lt;encrypted-value-format&gt;ct:cms-encrypted-data-format&lt;/encrypte\
d-value-format> d-value-format&gt;
<encrypted-value>BASE64VALUE=</encrypted-value> &lt;encrypted-value&gt;BASE64VALUE=&lt;/encrypted-value&gt;
</encrypted-private-key> &lt;/encrypted-private-key&gt;
</asymmetric-key> &lt;/asymmetric-key&gt;
</asymmetric-keys> &lt;/asymmetric-keys&gt;
<passwords &lt;passwords
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"&gt;
<password> &lt;password&gt;
<name>ex-cleartext-password</name> &lt;name&gt;ex-cleartext-password&lt;/name&gt;
<cleartext-password>super-secret</cleartext-password> &lt;cleartext-password&gt;super-secret&lt;/cleartext-password&gt;
</password> &lt;/password&gt;
<password> &lt;password&gt;
<name>ex-encrypted-password</name> &lt;name&gt;ex-encrypted-password&lt;/name&gt;
<encrypted-password> &lt;encrypted-password&gt;
<encrypted-by> &lt;encrypted-by&gt;
<symmetric-key-ref>ex-encrypted-one-symmetric-based-symmetri\ &lt;symmetric-key-ref&gt;ex-encrypted-one-symmetric-based-symmetri\
c-key</symmetric-key-ref> c-key&lt;/symmetric-key-ref&gt;
</encrypted-by> &lt;/encrypted-by&gt;
<encrypted-value-format>ct:cms-encrypted-data-format</encrypte\ &lt;encrypted-value-format&gt;ct:cms-encrypted-data-format&lt;/encrypte\
d-value-format> d-value-format&gt;
<encrypted-value>BASE64VALUE=</encrypted-value> &lt;encrypted-value&gt;BASE64VALUE=&lt;/encrypted-value&gt;
</encrypted-password> &lt;/encrypted-password&gt;
</password> &lt;/password&gt;
</passwords> &lt;/passwords&gt;
]]></artwork> </sourcecode>
</section> </section>
</section> </section>
<section anchor="gcsr-action" toc="exclude"> <section anchor="gcsr-action" toc="exclude" numbered="true" removeInRFC=
<name>The "generate-certificate-signing-request" Action</name> "false" pn="section-2.2.2">
<t>The following example illustrates the "generate-certificate-signing <name slugifiedName="name-the-generate-csr-action">The "generate-csr"
-request" Action</name>
action, discussed in <xref target="generate-csr-grouping"/>, with <t indent="0" pn="section-2.2.2-1">The following example illustrates t
the NETCONF protocol.</t> he "generate-csr"
<t keepWithNext="true">REQUEST</t> action, discussed in <xref target="generate-csr-grouping" format="defa
<artwork><![CDATA[ ult" sectionFormat="of" derivedContent="Section 2.1.4.10"/>, with the NETCONF pr
<rpc message-id="101" otocol.</t>
<t keepWithNext="true" indent="0" pn="section-2.2.2-2">REQUEST</t>
<sourcecode type="xml" markers="false" pn="section-2.2.2-3">
&lt;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"&gt;
<action xmlns="urn:ietf:params:xml:ns:yang:1"> &lt;action xmlns="urn:ietf:params:xml:ns:yang:1"&gt;
<asymmetric-keys &lt;asymmetric-keys
xmlns="https://example.com/ns/example-crypto-types-usage"> xmlns="https://example.com/ns/example-crypto-types-usage"&gt;
<asymmetric-key> &lt;asymmetric-key&gt;
<name>ex-hidden-asymmetric-key</name> &lt;name&gt;ex-hidden-asymmetric-key&lt;/name&gt;
<generate-csr> &lt;generate-csr&gt;
<csr-format>ct:p10-csr-format</csr-format> &lt;csr-format&gt;ct:p10-csr-format&lt;/csr-format&gt;
<csr-info>BASE64VALUE=</csr-info> &lt;csr-info&gt;BASE64VALUE=&lt;/csr-info&gt;
</generate-csr> &lt;/generate-csr&gt;
</asymmetric-key> &lt;/asymmetric-key&gt;
</asymmetric-keys> &lt;/asymmetric-keys&gt;
</action> &lt;/action&gt;
</rpc> &lt;/rpc&gt;
]]></artwork> </sourcecode>
<t keepWithNext="true">RESPONSE</t> <t keepWithNext="true" indent="0" pn="section-2.2.2-4">RESPONSE</t>
<artwork><![CDATA[ <sourcecode type="xml" markers="false" pn="section-2.2.2-5">
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<rpc-reply message-id="101" &lt;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"&gt;
<p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\ &lt;p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\
>BASE64VALUE=</p10-csr> &gt;BASE64VALUE=&lt;/p10-csr&gt;
</rpc-reply> &lt;/rpc-reply&gt;
]]></artwork> </sourcecode>
</section> </section>
<section anchor="cert-exp-notif-ex" toc="exclude"> <section anchor="cert-exp-notif-ex" toc="exclude" numbered="true" remove
<name>The "certificate-expiration" Notification</name> InRFC="false" pn="section-2.2.3">
<t>The following example illustrates the "certificate-expiration" <name slugifiedName="name-the-certificate-expiration-n">The "certifica
notification, discussed in <xref target="certificate-expiration-gr te-expiration" Notification</name>
ouping"/>, <t indent="0" pn="section-2.2.3-1">The following example illustrates t
with the NETCONF protocol.</t> he "certificate-expiration"
<artwork><![CDATA[ notification, discussed in <xref target="certificate-expiration-gr
ouping" format="default" sectionFormat="of" derivedContent="Section 2.1.4.7"/>,
with the NETCONF protocol.</t>
<sourcecode type="xml" markers="false" pn="section-2.2.3-2">
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<notification &lt;notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"&gt;
<eventTime>2018-05-25T00:01:00Z</eventTime> &lt;eventTime&gt;2018-05-25T00:01:00Z&lt;/eventTime&gt;
<asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\ &lt;asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\
s-usage"> s-usage"&gt;
<asymmetric-key> &lt;asymmetric-key&gt;
<name>ex-hidden-asymmetric-key</name> &lt;name&gt;ex-hidden-asymmetric-key&lt;/name&gt;
<certificates> &lt;certificates&gt;
<certificate> &lt;certificate&gt;
<name>ex-hidden-asymmetric-key-cert</name> &lt;name&gt;ex-hidden-asymmetric-key-cert&lt;/name&gt;
<certificate-expiration> &lt;certificate-expiration&gt;
<expiration-date>2018-08-05T14:18:53-05:00</expiration-d\ &lt;expiration-date&gt;2018-08-05T14:18:53-05:00&lt;/expiration-d\
ate> ate&gt;
</certificate-expiration> &lt;/certificate-expiration&gt;
</certificate> &lt;/certificate&gt;
</certificates> &lt;/certificates&gt;
</asymmetric-key> &lt;/asymmetric-key&gt;
</asymmetric-keys> &lt;/asymmetric-keys&gt;
</notification> &lt;/notification&gt;
]]></artwork> </sourcecode>
</section> </section>
</section> </section>
<section anchor="crypto-types-yang-module"> <section anchor="crypto-types-yang-module" numbered="true" removeInRFC="fa
<name>YANG Module</name> lse" toc="include" pn="section-2.3">
<t>This module has normative references to <xref target="RFC2119"/>, <name slugifiedName="name-yang-module">YANG Module</name>
<xref target="RFC2986"/>, <xref target="RFC4253"/>, <xref target="RFC5 <t indent="0" pn="section-2.3-1">This module has normative references to
280"/>, <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2
<xref target="RFC5652"/>, <xref target="RFC5915"/>, <xref target="RFC5 119"/>,
958"/>, <xref target="RFC2986" format="default" sectionFormat="of" derivedCont
<xref target="RFC6031"/>, <xref target="RFC6960"/>, ent="RFC2986"/>, <xref target="RFC4253" format="default" sectionFormat="of" deri
<xref target="RFC6991"/>, <xref target="RFC7093"/>, <xref target="RFC8 vedContent="RFC4253"/>, <xref target="RFC5280" format="default" sectionFormat="o
017"/>, f" derivedContent="RFC5280"/>,
<xref target="RFC8174"/>, <xref target="RFC8341"/>, <xref target="RFC5652" format="default" sectionFormat="of" derivedCont
and <xref target="ITU.X690.2021"/>.</t> ent="RFC5652"/>, <xref target="RFC5915" format="default" sectionFormat="of" deri
<t keepWithNext="true">&lt;CODE BEGINS&gt; file "ietf-crypto-types@2024- vedContent="RFC5915"/>, <xref target="RFC5958" format="default" sectionFormat="o
03-16.yang"</t> f" derivedContent="RFC5958"/>,
<artwork><![CDATA[ <xref target="RFC6031" format="default" sectionFormat="of" derivedCont
ent="RFC6031"/>, <xref target="RFC6960" format="default" sectionFormat="of" deri
vedContent="RFC6960"/>,
<xref target="RFC6991" format="default" sectionFormat="of" derivedCont
ent="RFC6991"/>, <xref target="RFC7093" format="default" sectionFormat="of" deri
vedContent="RFC7093"/>, <xref target="RFC8017" format="default" sectionFormat="o
f" derivedContent="RFC8017"/>,
<xref target="RFC8174" format="default" sectionFormat="of" derivedCont
ent="RFC8174"/>, <xref target="RFC8341" format="default" sectionFormat="of" deri
vedContent="RFC8341"/>,
and <xref target="ITU.X690.2021" format="default" sectionFormat="of" d
erivedContent="ITU.X690.2021"/>.</t>
<sourcecode name="ietf-crypto-types@2024-10-10.yang" type="yang" markers
="true" pn="section-2.3-2">
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 1196 skipping to change at line 1267
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control Model"; "RFC 8341: Network Configuration Access Control Model";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: https://datatracker.ietf.org/wg/netconf "WG Web: https://datatracker.ietf.org/wg/netconf
WG List: NETCONF WG list <mailto:netconf@ietf.org> WG List: NETCONF WG list &lt;mailto:netconf@ietf.org&gt;
Author: Kent Watsen <mailto:kent+ietf@watsen.net>"; Author: Kent Watsen &lt;mailto:kent+ietf@watsen.net&gt;";
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-10-10 {
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 1447
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 1589
} }
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 1903
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 1957
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 2038
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 2062
"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 2096
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 2178
} }
} }
} }
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 2253
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 2306
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 2354
refine "cert-data" { refine "cert-data" {
mandatory true; mandatory true;
} }
} }
} }
} }
uses generate-csr-grouping; uses generate-csr-grouping;
} // asymmetric-key-pair-with-certs-grouping } // asymmetric-key-pair-with-certs-grouping
} }
]]></artwork> </sourcecode>
<t keepWithPrevious="true">&lt;CODE ENDS&gt;</t>
</section> </section>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-3">
<name>Security Considerations</name> <name slugifiedName="name-security-considerations">Security Considerations
<section> </name>
<name>No Support for CRMF</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.1
<t>This document uses PKCS #10 <xref target="RFC2986"/> for the ">
"generate-certificate-signing-request" action. The use of Certificate <name slugifiedName="name-no-support-for-crmf">No Support for CRMF</name
Request Message Format (CRMF) <xref target="RFC4211"/> was considered, >
<t indent="0" pn="section-3.1-1">This document uses PKCS #10 <xref targe
t="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/> for t
he
"generate-csr" action. The use of Certificate
Request Message Format (CRMF) <xref target="RFC4211" format="default"
sectionFormat="of" derivedContent="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 numbered="true" removeInRFC="false" toc="include" pn="section-3.2
<name>No Support for Key Generation</name> ">
<t>Early revisions of this document included "rpc" statements for <name slugifiedName="name-no-support-for-key-generati">No Support for Ke
y Generation</name>
<t indent="0" pn="section-3.2-1">Early revisions of this document includ
ed "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 indent="0" pn="section-3.2-2">Separate protocol-specific modules can
key-generating RPCs (e.g., the "generate-public-key" RPC in present protocol-specific
<xref target="I-D.ietf-netconf-ssh-client-server"/> key-generating RPCs (e.g., the "generate-asymmetric-key-pair" RPC in
and <xref target="I-D.ietf-netconf-tls-client-server"/>).</t> <xref target="RFC9644" format="default" sectionFormat="of" derivedCo
ntent="RFC9644"/>
and <xref target="RFC9645" format="default" sectionFormat="of" deriv
edContent="RFC9645"/>).</t>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.3
<name>Unconstrained Public Key Usage</name> ">
<t>This module defines the "public-key-grouping" grouping, which <name slugifiedName="name-unconstrained-public-key-us">Unconstrained Pub
lic Key Usage</name>
<t indent="0" pn="section-3.3-1">This module defines the "public-key-gro
uping" 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 indent="0" pn="section-3.3-2">The "asymmetric-key-pair-grouping" grou
"public-key-grouping" grouping, and carries the same traits.</t> ping uses the aforementioned
<t>The "asymmetric-key-pair-with-cert-grouping" grouping uses the "public-key-grouping" grouping and carries the same traits.</t>
<t indent="0" pn="section-3.3-3">The "asymmetric-key-pair-with-cert-grou
ping" 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 numbered="true" removeInRFC="false" toc="include" pn="section-3.4
<name>Unconstrained Private Key Usage</name> ">
<t>This module defines the "asymmetric-key-pair-grouping" grouping, <name slugifiedName="name-unconstrained-private-key-u">Unconstrained Pri
vate Key Usage</name>
<t indent="0" pn="section-3.4-1">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 indent="0" pn="section-3.4-2">The "asymmetric-key-pair-with-cert-grou
ping" grouping uses the aforementioned
"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 numbered="true" removeInRFC="false" toc="include" pn="section-3.5
<name>Cleartext Passwords and Keys</name> ">
<t>The module contained within this document enables, only when <name slugifiedName="name-cleartext-passwords-and-key">Cleartext Passwor
ds and Keys</name>
<t indent="0" pn="section-3.5-1">The module contained within this docume
nt 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 numbered="true" removeInRFC="false" toc="include" pn="section-3.6
<name>Encrypting Passwords and Keys</name> ">
<t>The module contained within this document enables cleartext <name slugifiedName="name-encrypting-passwords-and-ke">Encrypting Passwo
rds and Keys</name>
<t indent="0" pn="section-3.6-1">The module contained within this docume
nt 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 indent="0" pn="section-3.6-2">To securely encrypt a password or key w
proper block cipher mode such as an AEAD or CBC MUST be used. This ith a symmetric key, a
ensures that a random IV is part of the input, which guarantees proper block cipher mode, such as an Authenticated Encryption with Assoc
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 numbered="true" removeInRFC="false" toc="include" pn="section-3.7
<name>Deletion of Cleartext Key Values</name> ">
<t>This module defines storage for cleartext key values that SHOULD <name slugifiedName="name-deletion-of-cleartext-key-v">Deletion of Clear
be zeroized when deleted, so as to prevent the remnants of their text Key Values</name>
<t indent="0" pn="section-3.7-1">This module defines storage for clearte
xt key values that <bcp14>SHOULD</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 <t indent="0" pn="section-3.7-2">The cleartext key values are the "clear
ed in the text-symmetric-key" node defined in the
"symmetric-key-grouping" grouping (<xref target="symmetric-key-group "symmetric-key-grouping" grouping (<xref target="symmetric-key-group
ing"/>) ing" format="default" sectionFormat="of" derivedContent="Section 2.1.4.3"/>)
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" format="defa ult" sectionFormat="of" derivedContent="Section 2.1.4.6"/>).</t>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-3.8
<name>Considerations for the "ietf-crypto-types" YANG Module</name> ">
<t>This section follows the template defined in <xref section="3.7.1" ta <name slugifiedName="name-considerations-for-the-ietf">Considerations fo
rget="RFC8407"/>.</t> r the "ietf-crypto-types" YANG Module</name>
<t>The YANG module in this document defines "grouping" statements <t indent="0" pn="section-3.8-1">This section is modeled after the templ
that are designed to be accessed via YANG based management ate defined in <xref section="3.7.1" target="RFC8407" format="default" sectionFo
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF rmat="of" derivedLink="https://rfc-editor.org/rfc/rfc8407#section-3.7.1" derived
<xref target="RFC8040"/>. Both of these protocols have Content="RFC8407"/>.</t>
mandatory-to-implement secure transport layers (e.g., SSH, TLS) <t indent="0" pn="section-3.8-2">The "ietf-crypto-types" YANG module def
with mutual authentication.</t> ines "grouping" statements
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/> that are designed to be accessed via YANG-based management
protocols, such as NETCONF <xref target="RFC6241" format="default" s
ectionFormat="of" derivedContent="RFC6241"/> and RESTCONF
<xref target="RFC8040" format="default" sectionFormat="of" derivedCo
ntent="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., Secure Shell (
SSH) <xref target="RFC4252" format="default" sectionFormat="of" derivedContent="
RFC4252"/>, TLS <xref target="RFC8446" format="default" sectionFormat="of" deriv
edContent="RFC8446"/>, and QUIC <xref target="RFC9000" format="default" sectionF
ormat="of" derivedContent="RFC9000"/>) and mandatory-to-implement mutual authent
ication.</t>
<t indent="0" pn="section-3.8-3">The Network Configuration Access Contro
l Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derive
dContent="RFC8341"/>
provides the means to restrict access for particular users to a 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 indent="0" pn="section-3.8-4">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 indent="0" pn="section-3.8-5">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:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<li> .8-6">
<t>The "cleartext-password" node: <li pn="section-3.8-6.1">
<t indent="0" pn="section-3.8-6.1.1">The "cleartext-password" node:
</t> </t>
<ul empty="true"> <ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio
<li>The "cleartext-password" node defined in the "password-groupin n-3.8-6.1.2">
g" <li pn="section-3.8-6.1.2.1">The "cleartext-password" node defined
in the "password-grouping"
grouping is additionally sensitive to read operations such t hat, grouping is additionally sensitive to read operations such t hat,
in normal use cases, it should never be returned to a client . in normal use cases, it should never be returned to a client .
For this reason, the NACM extension "default-deny-all" has b een For this reason, the NACM extension "default-deny-all" has b een
applied to it.</li> applied to it.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-3.8-6.2">
<t>The "cleartext-symmetric-key" node: <t indent="0" pn="section-3.8-6.2.1">The "cleartext-symmetric-key" n
ode:
</t> </t>
<ul empty="true"> <ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio
<li>The "cleartext-symmetric-key" node defined in the "symmetric-k n-3.8-6.2.2">
ey-grouping" <li pn="section-3.8-6.2.2.1">The "cleartext-symmetric-key" node de
fined in the "symmetric-key-grouping"
grouping is additionally sensitive to read operations such t hat, grouping is additionally sensitive to read operations such t hat,
in normal use cases, it should never be returned to a client . in normal use cases, it should never be returned to a client .
For this reason, the NACM extension "default-deny-all" has b een For this reason, the NACM extension "default-deny-all" has b een
applied to it.</li> applied to it.</li>
</ul> </ul>
</li> </li>
<li> <li pn="section-3.8-6.3">
<t>The "cleartext-private-key" node: <t indent="0" pn="section-3.8-6.3.1">The "cleartext-private-key" nod
e:
</t> </t>
<ul empty="true"> <ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio
<li>The "cleartext-private-key" node defined in the "asymmetric-ke n-3.8-6.3.2">
y-pair-grouping" <li pn="section-3.8-6.3.2.1">The "cleartext-private-key" node defi
ned in the "asymmetric-key-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 pn="section-3.8-6.4">
<t>The "cert-data" node: <t indent="0" pn="section-3.8-6.4.1">The "cert-data" node:
</t> </t>
<ul empty="true"> <ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio
<li>The "cert-data" node, defined in both the "trust-anchor-cert-g n-3.8-6.4.2">
rouping" <li pn="section-3.8-6.4.2.1">The "cert-data" node defined in both
and "end-entity-cert-grouping" groupings, is additionally se the "trust-anchor-cert-grouping"
nsitive to and "end-entity-cert-grouping" groupings is additionally sen
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 indent="0" pn="section-3.8-7">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 indent="0" pn="section-3.8-8">Some of the operations in this YANG mod ule 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" bare="false" empty="false" indent="3" pn="section-3
<li> .8-9">
<t>generate-certificate-signing-request: <li pn="section-3.8-9.1">
<t indent="0" pn="section-3.8-9.1.1">generate-csr:
</t> </t>
<ul empty="true"> <ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio
<li>This "action" statement SHOULD only be executed by authorized n-3.8-9.1.2">
<li pn="section-3.8-9.1.2.1">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 pn="section-3.8-9.1.2.2">For this action, it is <bcp14>RECOMME
channel binding <xref target="RFC5056"/>, so as to ensure NDED</bcp14> that implementations assert
channel binding <xref target="RFC5056" format="default" sect
ionFormat="of" derivedContent="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 numbered="true" removeInRFC="false" toc="include" pn="section-4">
<name>IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.1
<name>The "IETF XML" Registry</name> ">
<t>This document registers one URI in the "ns" subregistry <name slugifiedName="name-the-ietf-xml-registry">The IETF XML Registry</
of the "IETF XML" registry <xref target="RFC3688"/>. Following name>
the format in <xref target="RFC3688"/>, the following <t indent="0" pn="section-4.1-1">IANA has registered the following URI i
registration is requested:</t> n the "ns" registry
<artwork><![CDATA[ of the "IETF XML Registry" <xref target="RFC3688" format="default" sec
URI: urn:ietf:params:xml:ns:yang:ietf-crypto-types tionFormat="of" derivedContent="RFC3688"/>.</t>
Registrant Contact: The IESG <dl newline="false" spacing="compact" indent="3" pn="section-4.1-2">
XML: N/A, the requested URI is an XML namespace. <dt pn="section-4.1-2.1">URI:</dt>
]]></artwork> <dd pn="section-4.1-2.2">urn:ietf:params:xml:ns:yang:ietf-crypto-types
</dd>
<dt pn="section-4.1-2.3">Registrant Contact:</dt>
<dd pn="section-4.1-2.4">The IESG</dd>
<dt pn="section-4.1-2.5">XML:</dt>
<dd pn="section-4.1-2.6">N/A; the requested URI is an XML namespace.</
dd>
</dl>
</section> </section>
<section> <section numbered="true" removeInRFC="false" toc="include" pn="section-4.2
<name>The "YANG Module Names" Registry</name> ">
<t>This document registers one YANG module in the <name slugifiedName="name-the-yang-module-names-regis">The YANG Module N
"YANG Module Names" registry <xref target="RFC6020"/>. ames Registry</name>
Following the format in <xref target="RFC6020"/>, the <t indent="0" pn="section-4.2-1">IANA has registered the following YANG
following registration is requested:</t> module in the
<artwork><![CDATA[ "YANG Module Names" registry <xref target="RFC6020" format="default" s
name: ietf-crypto-types ectionFormat="of" derivedContent="RFC6020"/>.
namespace: urn:ietf:params:xml:ns:yang:ietf-crypto-types </t>
prefix: ct <dl newline="false" spacing="compact" indent="3" pn="section-4.2-2">
reference: RFC AAAA <dt pn="section-4.2-2.1">Name:</dt>
]]></artwork> <dd pn="section-4.2-2.2">ietf-crypto-types</dd>
<dt pn="section-4.2-2.3">Namespace:</dt>
<dd pn="section-4.2-2.4">urn:ietf:params:xml:ns:yang:ietf-crypto-types
</dd>
<dt pn="section-4.2-2.5">Prefix:</dt>
<dd pn="section-4.2-2.6">ct</dd>
<dt pn="section-4.2-2.7">Reference:</dt>
<dd pn="section-4.2-2.8">RFC 9640</dd>
</dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <displayreference target="I-D.ietf-netconf-http-client-server" to="HTTP-CLIE
<name>References</name> NT-SERVER"/>
<references> <displayreference target="I-D.ietf-netconf-netconf-client-server" to="NETCON
<name>Normative References</name> F-CLIENT-SERVER"/>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <displayreference target="I-D.ietf-netconf-restconf-client-server" to="RESTC
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> ONF-CLIENT-SERVER"/>
<references pn="section-5">
<name slugifiedName="name-references">References</name>
<references pn="section-5.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="ITU.X680.2021" target="https://www.itu.int/rec/T-REC-
X.680-202102-I" quoteTitle="true" derivedAnchor="ITU.X680.2021">
<front>
<title>Information technology - Abstract Syntax Notation One (ASN.1)
: Specification of basic notation</title>
<author>
<organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference>
<reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-
X.690-202102-I" quoteTitle="true" derivedAnchor="ITU.X690.2021">
<front>
<title>Information Technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)</title>
<author>
<organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="February" year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2021"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit le> <title>Key words for use in RFCs to Indicate Requirement Levels</tit le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/> <date month="March" year="1997"/>
<abstract> <abstract>
<t>In many standards track documents several words are used to sig nify the requirements in the specification. These words are often capitalized. T his document defines these words as they should be interpreted in IETF documents . This document specifies an Internet Best Current Practices for the Internet Co mmunity, and requests discussion and suggestions for improvements.</t> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often cap italized. This document defines these words as they should be interpreted in IET F documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t >
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.2404.xml"?>--> <reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2
<!--<?rfc include="reference.RFC.3565.xml"?> 986" quoteTitle="true" derivedAnchor="RFC2986">
<?rfc include="reference.RFC.3686.xml"?> <front>
<?rfc include="reference.RFC.4106.xml"?>--> <title>PKCS #10: Certification Request Syntax Specification Version
<reference anchor="RFC4253" target="https://www.rfc-editor.org/info/rfc4 1.7</title>
253" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml"> <author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<date month="November" year="2000"/>
<abstract>
<t indent="0">This memo represents a republication of PKCS #10 v1.
7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and ch
ange control is retained within the PKCS process. The body of this document, exc
ept for the security considerations section, is taken directly from the PKCS #9
v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Inter
net community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2986"/>
<seriesInfo name="DOI" value="10.17487/RFC2986"/>
</reference>
<reference anchor="RFC4252" target="https://www.rfc-editor.org/info/rfc4
252" quoteTitle="true" derivedAnchor="RFC4252">
<front>
<title>The Secure Shell (SSH) Authentication Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L
onvick"/>
<date month="January" year="2006"/>
<abstract>
<t indent="0">The Secure Shell Protocol (SSH) is a protocol for se
cure remote login and other secure network services over an insecure network. Th
is document describes the SSH authentication protocol framework and public key,
password, and host-based client authentication methods. Additional authenticatio
n methods are described in separate documents. The SSH authentication protocol r
uns on top of the SSH transport layer protocol and provides a single authenticat
ed tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>
<reference anchor="RFC4253" target="https://www.rfc-editor.org/info/rfc4
253" quoteTitle="true" derivedAnchor="RFC4253">
<front> <front>
<title>The Secure Shell (SSH) Transport Layer Protocol</title> <title>The Secure Shell (SSH) Transport Layer Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/> <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L onvick"/> <author fullname="C. Lonvick" initials="C." role="editor" surname="L onvick"/>
<date month="January" year="2006"/> <date month="January" year="2006"/>
<abstract> <abstract>
<t>The Secure Shell (SSH) is a protocol for secure remote login an <t indent="0">The Secure Shell (SSH) is a protocol for secure remo
d other secure network services over an insecure network.</t> te login and other secure network services over an insecure network.</t>
<t>This document describes the SSH transport layer protocol, which <t indent="0">This document describes the SSH transport layer prot
typically runs on top of TCP/IP. The protocol can be used as a basis for a numb ocol, which typically runs on top of TCP/IP. The protocol can be used as a basis
er of secure network services. It provides strong encryption, server authenticat for a number of secure network services. It provides strong encryption, server
ion, and integrity protection. It may also provide compression.</t> authentication, and integrity protection. It may also provide compression.</t>
<t>Key exchange method, public key algorithm, symmetric encryption <t indent="0">Key exchange method, public key algorithm, symmetric
algorithm, message authentication algorithm, and hash algorithm are all negotia encryption algorithm, message authentication algorithm, and hash algorithm are
ted.</t> all negotiated.</t>
<t>This document also describes the Diffie-Hellman key exchange me <t indent="0">This document also describes the Diffie-Hellman key
thod and the minimal set of algorithms that are needed to implement the SSH tran exchange method and the minimal set of algorithms that are needed to implement t
sport layer protocol. [STANDARDS-TRACK]</t> he SSH transport layer protocol. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4253"/> <seriesInfo name="RFC" value="4253"/>
<seriesInfo name="DOI" value="10.17487/RFC4253"/> <seriesInfo name="DOI" value="10.17487/RFC4253"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.4279.xml"?> <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
<?rfc include="reference.RFC.4309.xml"?> 280" quoteTitle="true" derivedAnchor="RFC5280">
<?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> <front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert ificate Revocation List (CRL) Profile</title> <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="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/> <author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/> <date month="May" year="2008"/>
<abstract> <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> <t indent="0">This memo profiles the X.509 v3 certificate and X.50 9 v2 certificate revocation list (CRL) for use in the Internet. An overview of t his approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are descri bed and two Internet-specific extensions are defined. A set of required certific ate extensions is specified. The X.509 v2 CRL format is described in detail alon g with standard and Internet-specific extensions. An algorithm for X.509 certifi cation path validation is described. An ASN.1 module and examples are provided i n the appendices. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5280"/> <seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference> </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"> <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5 652" quoteTitle="true" derivedAnchor="RFC5652">
<front> <front>
<title>Cryptographic Message Syntax (CMS)</title> <title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/> <date month="September" year="2009"/>
<abstract> <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> <t indent="0">This document describes the Cryptographic Message Sy ntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encr ypt arbitrary message content. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="STD" value="70"/> <seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/> <seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/> <seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.5656.xml"?>--> <reference anchor="RFC5915" target="https://www.rfc-editor.org/info/rfc5
<reference anchor="RFC5958" target="https://www.rfc-editor.org/info/rfc5 915" quoteTitle="true" derivedAnchor="RFC5915">
958" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"> <front>
<title>Elliptic Curve Private Key Structure</title>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="D. Brown" initials="D." surname="Brown"/>
<date month="June" year="2010"/>
<abstract>
<t indent="0">This document specifies the syntax and semantics for
conveying Elliptic Curve (EC) private key information. The syntax and semantics
defined herein are based on similar syntax and semantics defined by the Standar
ds for Efficient Cryptography Group (SECG). This document is not an Internet Sta
ndards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5915"/>
<seriesInfo name="DOI" value="10.17487/RFC5915"/>
</reference>
<reference anchor="RFC5958" target="https://www.rfc-editor.org/info/rfc5
958" quoteTitle="true" derivedAnchor="RFC5958">
<front> <front>
<title>Asymmetric Key Packages</title> <title>Asymmetric Key Packages</title>
<author fullname="S. Turner" initials="S." surname="Turner"/> <author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="August" year="2010"/> <date month="August" year="2010"/>
<abstract> <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> <t indent="0">This document defines the syntax for private-key inf ormation and a content type for it. Private-key information includes a private k ey for a specified public-key algorithm and a set of attributes. The Cryptograph ic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This do cument obsoletes RFC 5208. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5958"/> <seriesInfo name="RFC" value="5958"/>
<seriesInfo name="DOI" value="10.17487/RFC5958"/> <seriesInfo name="DOI" value="10.17487/RFC5958"/>
</reference> </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"> <reference anchor="RFC6031" target="https://www.rfc-editor.org/info/rfc6 031" quoteTitle="true" derivedAnchor="RFC6031">
<front> <front>
<title>Cryptographic Message Syntax (CMS) Symmetric Key Package Cont ent Type</title> <title>Cryptographic Message Syntax (CMS) Symmetric Key Package Cont ent Type</title>
<author fullname="S. Turner" initials="S." surname="Turner"/> <author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="December" year="2010"/> <date month="December" year="2010"/>
<abstract> <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> <t indent="0">This document defines the symmetric key format conte nt 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> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6031"/> <seriesInfo name="RFC" value="6031"/>
<seriesInfo name="DOI" value="10.17487/RFC6031"/> <seriesInfo name="DOI" value="10.17487/RFC6031"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.6187.xml"?>--> <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6 241" quoteTitle="true" derivedAnchor="RFC6241">
960" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6960.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 indent="0">The Network Configuration Protocol (NETCONF) defined
in this document provides mechanisms to install, manipulate, and delete the con
figuration of network devices. It uses an Extensible Markup Language (XML)-based
data encoding for the configuration data as well as the protocol messages. The
NETCONF protocol operations are realized as remote procedure calls (RPCs). This
document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
960" quoteTitle="true" derivedAnchor="RFC6960">
<front> <front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S tatus Protocol - OCSP</title> <title>X.509 Internet Public Key Infrastructure Online Certificate S tatus Protocol - OCSP</title>
<author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="M. Myers" initials="M." surname="Myers"/> <author fullname="M. Myers" initials="M." surname="Myers"/>
<author fullname="R. Ankney" initials="R." surname="Ankney"/> <author fullname="R. Ankney" initials="R." surname="Ankney"/>
<author fullname="A. Malpani" initials="A." surname="Malpani"/> <author fullname="A. Malpani" initials="A." surname="Malpani"/>
<author fullname="S. Galperin" initials="S." surname="Galperin"/> <author fullname="S. Galperin" initials="S." surname="Galperin"/>
<author fullname="C. Adams" initials="C." surname="Adams"/> <author fullname="C. Adams" initials="C." surname="Adams"/>
<date month="June" year="2013"/> <date month="June" year="2013"/>
<abstract> <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> <t indent="0">This document specifies a protocol useful in determi ning the current status of a digital certificate without requiring Certificate R evocation Lists (CRLs). Additional mechanisms addressing PKIX operational requir ements are specified in separate documents. This document obsoletes RFCs 2560 an d 6277. It also updates RFC 5912.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6960"/> <seriesInfo name="RFC" value="6960"/>
<seriesInfo name="DOI" value="10.17487/RFC6960"/> <seriesInfo name="DOI" value="10.17487/RFC6960"/>
</reference> </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"> <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6 991" quoteTitle="true" derivedAnchor="RFC6991">
<front> <front>
<title>Common YANG Data Types</title> <title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn ame="Schoenwaelder"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surn ame="Schoenwaelder"/>
<date month="July" year="2013"/> <date month="July" year="2013"/>
<abstract> <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> <t indent="0">This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6991"/> <seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/> <seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference> </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"> <reference anchor="RFC7093" target="https://www.rfc-editor.org/info/rfc7 093" quoteTitle="true" derivedAnchor="RFC7093">
<front> <front>
<title>Additional Methods for Generating Key Identifiers Values</tit le> <title>Additional Methods for Generating Key Identifiers Values</tit le>
<author fullname="S. Turner" initials="S." surname="Turner"/> <author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="S. Kent" initials="S." surname="Kent"/> <author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="J. Manger" initials="J." surname="Manger"/> <author fullname="J. Manger" initials="J." surname="Manger"/>
<date month="December" year="2013"/> <date month="December" year="2013"/>
<abstract> <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> <t indent="0">This document specifies additional example methods f or generating Key Identifier values for use in the AKI (Authority Key Identifier ) and SKI (Subject Key Identifier) certificate extensions.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7093"/> <seriesInfo name="RFC" value="7093"/>
<seriesInfo name="DOI" value="10.17487/RFC7093"/> <seriesInfo name="DOI" value="10.17487/RFC7093"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.7919.xml"?>--> <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7 950" quoteTitle="true" derivedAnchor="RFC7950">
950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
<front> <front>
<title>The YANG 1.1 Data Modeling Language</title> <title>The YANG 1.1 Data Modeling Language</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/>
<date month="August" year="2016"/> <date month="August" year="2016"/>
<abstract> <abstract>
<t>YANG is a data modeling language used to model configuration da ta, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of t he YANG language. YANG version 1.1 is a maintenance release of the YANG language , addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document al so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).< /t> <t indent="0">YANG is a data modeling language used to model confi guration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of versi on 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YA NG language, addressing ambiguities and defects in the original specification. T here are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7950"/> <seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/> <seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference> </reference>
<reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8 017" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"> <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8 017" quoteTitle="true" derivedAnchor="RFC8017">
<front> <front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title> <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname=" Moriarty"/> <author fullname="K. Moriarty" initials="K." role="editor" surname=" Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/> <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/> <author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="November" year="2016"/> <date month="November" year="2016"/>
<abstract> <abstract>
<t>This document provides recommendations for the implementation o <t indent="0">This document provides recommendations for the imple
f public-key cryptography based on the RSA algorithm, covering cryptographic pri mentation of public-key cryptography based on the RSA algorithm, covering crypto
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f graphic primitives, encryption schemes, signature schemes with appendix, and ASN
or representing keys and for identifying the schemes.</t> .1 syntax for representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R <t indent="0">This document represents a republication of PKCS #1
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By
this RFC, change control is transferred to the IETF.</t> publishing this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t> <t indent="0">This document also obsoletes RFC 3447.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8017"/> <seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/> <seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference> </reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> 040" quoteTitle="true" derivedAnchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<date month="January" year="2017"/>
<abstract>
<t indent="0">This document describes an HTTP-based protocol that
provides a programmatic interface for accessing data defined in YANG, using the
datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/> <date month="May" year="2017"/>
<abstract> <abstract>
<t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clari fying that only UPPERCASE usage of the key words have the defined special meanin gs.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.8268.xml"?> <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8
<?rfc include="reference.RFC.8332.xml"?>--> 341" quoteTitle="true" derivedAnchor="RFC8341">
<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> <front>
<title>Network Configuration Access Control Model</title> <title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/> <date month="March" year="2018"/>
<abstract> <abstract>
<t>The standardization of network configuration interfaces for use <t indent="0">The standardization of network configuration interfa
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ ces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF pr
ires a structured and secure operating environment that promotes human usability otocol requires a structured and secure operating environment that promotes huma
and multi-vendor interoperability. There is a need for standard mechanisms to r n usability and multi-vendor interoperability. There is a need for standard mech
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu anisms to restrict NETCONF or RESTCONF protocol access for particular users to a
red subset of all available NETCONF or RESTCONF protocol operations and content. preconfigured subset of all available NETCONF or RESTCONF protocol operations a
This document defines such an access control model.</t> nd content. This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t> <t indent="0">This document obsoletes RFC 6536.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="STD" value="91"/> <seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/> <seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/> <seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.8422.xml"?> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
<?rfc include="reference.RFC.8446.xml"?>--> 446" quoteTitle="true" derivedAnchor="RFC8446">
<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>The Transport Layer Security (TLS) Protocol Version 1.3</titl
: e>
Specification of basic notation <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
</title> <date month="August" year="2018"/>
<author> <abstract>
<organization>International Telecommunication Union</organization> <t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to communi
cate over the Internet in a way that is designed to prevent eavesdropping, tampe
ring, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9
000" quoteTitle="true" derivedAnchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t indent="0">This document defines the core of the QUIC transport
protocol. QUIC provides applications with flow-controlled streams for structure
d communication, low-latency connection establishment, and network path migratio
n. QUIC includes security measures that ensure confidentiality, integrity, and a
vailability in a range of deployment circumstances. Accompanying documents descr
ibe the integration of TLS for key negotiation, loss detection, and an exemplary
congestion control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
</references>
<references pn="section-5.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.ietf-netconf-http-client-server" target="https://
datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-23" quoteTit
le="true" derivedAnchor="HTTP-CLIENT-SERVER">
<front>
<title>YANG Groupings for HTTP Clients and HTTP Servers</title>
<author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author> </author>
<date month="February" year="2021"/> <date day="15" month="August" year="2024"/>
<abstract>
<t indent="0">This document presents two YANG modules: the first d
efines a minimal grouping for configuring an HTTP client, and the second defines
a minimal grouping for configuring an HTTP server. It is intended that these gr
oupings will be used to help define the configuration for simple HTTP-based prot
ocols (not for complete web servers or browsers). Support is provided for HTTP/1
.1, HTTP/2, and HTTP/3.</t>
</abstract>
</front> </front>
<seriesInfo name="ITU-T Recommendation X.680," value="ISO/IEC 8824-1:2 <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-http-clien
021"/> t-server-23"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC- X.690-202102-I"> <reference anchor="I-D.ietf-netconf-netconf-client-server" target="https ://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-37" qu oteTitle="true" derivedAnchor="NETCONF-CLIENT-SERVER">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification <title>NETCONF Client and Server Models</title>
of Basic <author fullname="Kent Watsen" initials="K." surname="Watsen">
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguish <organization showOnFrontPage="true">Watsen Networks</organization
ed >
Encoding Rules (DER)</title>
<author>
<organization>International Telecommunication Union</organization>
</author> </author>
<date month="February" year="2021"/> <date day="14" month="August" year="2024"/>
<abstract>
<t indent="0">This document presents two YANG modules, one module
to configure a NETCONF client and the other module to configure a NETCONF server
. Both modules support both the SSH and TLS transport protocols, and support bot
h standard NETCONF and NETCONF Call Home connections. Editorial Note (To be remo
ved by RFC Editor) This draft contains placeholder values that need to be replac
ed with finalized values at the time of publication. This note summarizes all of
the substitutions that are needed. No other RFC Editor instructions are specifi
ed elsewhere in this document. Artwork in this document contains shorthand refer
ences to drafts in progress. Please apply the following replacements (note: not
all may be present): * AAAA --&gt; the assigned RFC value for draft-ietf-netconf
-crypto- types * BBBB --&gt; the assigned RFC value for draft-ietf-netconf-trust
- anchors * CCCC --&gt; the assigned RFC value for draft-ietf-netconf-keystore *
DDDD --&gt; the assigned RFC value for draft-ietf-netconf-tcp-client- server *
EEEE --&gt; the assigned RFC value for draft-ietf-netconf-ssh-client- server * F
FFF --&gt; the assigned RFC value for draft-ietf-netconf-tls-client- server * GG
GG --&gt; the assigned RFC value for draft-ietf-netconf-http- client-server * HH
HH --&gt; the assigned RFC value for this draft Artwork in this document contain
s placeholder values for the date of publication of this draft. Please apply the
following replacement: * 2024-08-14 --&gt; the publication date of this draft T
he "Relation to other RFCs" section Section 1.1 contains the text "one or more Y
ANG modules" and, later, "modules". This text is sourced from a file in a contex
t where it is unknown how many modules a draft defines. The text is not wrong as
is, but it may be improved by stating more directly how many modules are define
d. The "Relation to other RFCs" section Section 1.1 contains a self- reference t
o this draft, along with a corresponding reference in the Appendix. Please repla
ce the self-reference in this section with "This RFC" (or similar) and remove th
e self-reference in the "Normative/Informative References" section, whichever it
is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in
RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used.
The AD suggested suggested putting a request here for the RFC Editor to help co
nvert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" ma
y be interpreted as, identify what looks ugly and ask the authors to make the ad
justment. The following Appendix section is to be removed prior to publication:
* Appendix A. Change Log</t>
</abstract>
</front> </front>
<seriesInfo name="ITU-T Recommendation X.690," value="ISO/IEC 8825-1:2 <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-netconf-cl
021"/> ient-server-37"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
</references> <reference anchor="I-D.ietf-netconf-restconf-client-server" target="http
<references> s://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-38"
<name>Informative References</name> quoteTitle="true" derivedAnchor="RESTCONF-CLIENT-SERVER">
<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">
<front> <front>
<title>PKCS #10: Certification Request Syntax Specification Version <title>RESTCONF Client and Server Models</title>
1.7</title> <author fullname="Kent Watsen" initials="K." surname="Watsen">
<author fullname="M. Nystrom" initials="M." surname="Nystrom"/> <organization showOnFrontPage="true">Watsen Networks</organization
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> >
<date month="November" year="2000"/> </author>
<date day="14" month="August" year="2024"/>
<abstract> <abstract>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change contro l is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet communi ty.</t> <t indent="0">This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF serv er. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in th is document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present ): * AAAA --&gt; the assigned RFC value for draft-ietf-netconf-crypto- types * B BBB --&gt; the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC - -&gt; the assigned RFC value for draft-ietf-netconf-keystore * DDDD --&gt; the a ssigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --&gt; the as signed RFC value for draft-ietf-netconf-ssh-client- server * FFFF --&gt; the ass igned RFC value for draft-ietf-netconf-tls-client- server * GGGG --&gt; the assi gned RFC value for draft-ietf-netconf-http- client-server * HHHH --&gt; the assi gned RFC value for draft-ietf-netconf-netconf- client-server * IIII --&gt; the a ssigned RFC value for this draft Artwork in this document contains placeholder v alues for the date of publication of this draft. Please apply the following repl acement: * 2024-08-14 --&gt; the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" an d, later, "modules". This text is sourced from a file in a context where it is u nknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relatio n to other RFCs" section Section 1.1 contains a self- reference to this draft, a long with a corresponding reference in the Appendix. Please replace the self-ref erence in this section with "This RFC" (or similar) and remove the self-referenc e in the "Normative/Informative References" section, whichever it is in. Tree-di agrams in this draft may use the '\' line-folding mode defined in RFC 8792. Howe ver, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggest ed suggested putting a request here for the RFC Editor to help convert "ugly" '\ ' folded examples to use the '\\' folding mode. "Help convert" may be interprete d as, identify what looks ugly and ask the authors to make the adjustment. The f ollowing Appendix section is to be removed prior to publication: * Appendix A. C hange Log</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="2986"/> <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-restconf-c
<seriesInfo name="DOI" value="10.17487/RFC2986"/> lient-server-38"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<!--<?rfc include="reference.RFC.3174.xml"?>--> <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3 688" quoteTitle="true" derivedAnchor="RFC3688">
688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
<front> <front>
<title>The IETF XML Registry</title> <title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/> <author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/> <date month="January" year="2004"/>
<abstract> <abstract>
<t>This document describes an IANA maintained registry for IETF st andards which use Extensible Markup Language (XML) related items such as Namespa ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew ork (RDF) Schemas.</t> <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip tion Framework (RDF) Schemas.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="81"/> <seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/> <seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/> <seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference> </reference>
<reference anchor="RFC4211" target="https://www.rfc-editor.org/info/rfc4 211" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"> <reference anchor="RFC4211" target="https://www.rfc-editor.org/info/rfc4 211" quoteTitle="true" derivedAnchor="RFC4211">
<front> <front>
<title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title> <title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/> <author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="September" year="2005"/> <date month="September" year="2005"/>
<abstract> <abstract>
<t>This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certi ficate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typical ly include a public key and the associated registration information. This docume nt does not define a certificate request protocol. [STANDARDS-TRACK]</t> <t indent="0">This document describes the Certificate Request Mess age Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request w ill typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]< /t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4211"/> <seriesInfo name="RFC" value="4211"/>
<seriesInfo name="DOI" value="10.17487/RFC4211"/> <seriesInfo name="DOI" value="10.17487/RFC4211"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.4493.xml"?>--> <reference anchor="RFC5056" target="https://www.rfc-editor.org/info/rfc5
<reference anchor="RFC5056" target="https://www.rfc-editor.org/info/rfc5 056" quoteTitle="true" derivedAnchor="RFC5056">
056" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5056.xml">
<front> <front>
<title>On the Use of Channel Bindings to Secure Channels</title> <title>On the Use of Channel Bindings to Secure Channels</title>
<author fullname="N. Williams" initials="N." surname="Williams"/> <author fullname="N. Williams" initials="N." surname="Williams"/>
<date month="November" year="2007"/> <date month="November" year="2007"/>
<abstract> <abstract>
<t>The concept of channel binding allows applications to establish <t indent="0">The concept of channel binding allows applications t
that the two end-points of a secure channel at one network layer are the same a o establish that the two end-points of a secure channel at one network layer are
s at a higher layer by binding authentication at the higher layer to the channel the same as at a higher layer by binding authentication at the higher layer to
at the lower layer. This allows applications to delegate session protection to the channel at the lower layer. This allows applications to delegate session pro
lower layers, which has various performance benefits.</t> tection to lower layers, which has various performance benefits.</t>
<t>This document discusses and formalizes the concept of channel b <t indent="0">This document discusses and formalizes the concept o
inding to secure channels. [STANDARDS-TRACK]</t> f channel binding to secure channels. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5056"/> <seriesInfo name="RFC" value="5056"/>
<seriesInfo name="DOI" value="10.17487/RFC5056"/> <seriesInfo name="DOI" value="10.17487/RFC5056"/>
</reference> </reference>
<reference anchor="RFC5915" target="https://www.rfc-editor.org/info/rfc5 <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6
915" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml"> 020" quoteTitle="true" derivedAnchor="RFC6020">
<front>
<title>Elliptic Curve Private Key Structure</title>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="D. Brown" initials="D." surname="Brown"/>
<date month="June" year="2010"/>
<abstract>
<t>This document specifies the syntax and semantics for conveying
Elliptic Curve (EC) private key information. The syntax and semantics defined he
rein are based on similar syntax and semantics defined by the Standards for Effi
cient Cryptography Group (SECG). This document is not an Internet Standards Trac
k specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5915"/>
<seriesInfo name="DOI" value="10.17487/RFC5915"/>
</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">
<front> <front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title> <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname= "Bjorklund"/>
<date month="October" year="2010"/> <date month="October" year="2010"/>
<abstract> <abstract>
<t>YANG is a data modeling language used to model configuration an d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> <t indent="0">YANG is a data modeling language used to model confi guration and state data manipulated by the Network Configuration Protocol (NETCO NF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK ]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6020"/> <seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/> <seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.6234.xml"?>--> <reference anchor="RFC7317" target="https://www.rfc-editor.org/info/rfc7
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 317" quoteTitle="true" derivedAnchor="RFC7317">
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> <front>
<title>A YANG Data Model for System Management</title> <title>A YANG Data Model for System Management</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="August" year="2014"/> <date month="August" year="2014"/>
<abstract> <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> <t indent="0">This document defines a YANG data model for the conf iguration and identification of some common system properties within a device co ntaining a Network Configuration Protocol (NETCONF) server. This document also i ncludes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for s ystem management.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7317"/> <seriesInfo name="RFC" value="7317"/>
<seriesInfo name="DOI" value="10.17487/RFC7317"/> <seriesInfo name="DOI" value="10.17487/RFC7317"/>
</reference> </reference>
<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8 040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"> <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8 259" quoteTitle="true" derivedAnchor="RFC8259">
<front> <front>
<title>RESTCONF Protocol</title> <title>The JavaScript Object Notation (JSON) Data Interchange Format
<author fullname="A. Bierman" initials="A." surname="Bierman"/> </title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="T. Bray" initials="T." role="editor" surname="Bray
<author fullname="K. Watsen" initials="K." surname="Watsen"/> "/>
<date month="January" year="2017"/> <date month="December" year="2017"/>
<abstract> <abstract>
<t>This document describes an HTTP-based protocol that provides a <t indent="0">JavaScript Object Notation (JSON) is a lightweight,
programmatic interface for accessing data defined in YANG, using the datastore c text-based, language-independent data interchange format. It was derived from th
oncepts defined in the Network Configuration Protocol (NETCONF).</t> e ECMAScript Programming Language Standard. JSON defines a small set of formatti
ng rules for the portable representation of structured data.</t>
<t indent="0">This document removes inconsistencies with other spe
cifications of JSON, repairs specification errors, and offers experience-based i
nteroperability guidance.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8040"/> <seriesInfo name="STD" value="90"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/> <seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference> </reference>
<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8 340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"> <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8 340" quoteTitle="true" derivedAnchor="RFC8340">
<front> <front>
<title>YANG Tree Diagrams</title> <title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be rger"/> <author fullname="L. Berger" initials="L." role="editor" surname="Be rger"/>
<date month="March" year="2018"/> <date month="March" year="2018"/>
<abstract> <abstract>
<t>This document captures the current syntax used in YANG module t ree diagrams. The purpose of this document is to provide a single location for t his definition. This syntax may be updated from time to time based on the evolut ion of the YANG language.</t> <t indent="0">This document captures the current syntax used in YA NG module tree diagrams. The purpose of this document is to provide a single loc ation for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="215"/> <seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/> <seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/> <seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference> </reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8 <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
407" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml"> 342" quoteTitle="true" derivedAnchor="RFC8342">
<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 indent="0">Datastores are a fundamental concept binding the dat
a models written in the YANG data modeling language to network management protoc
ols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This docu
ment defines an architectural framework for datastores based on the experience g
ained with the initial simpler model, addressing requirements that were not well
supported in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC8407" target="https://www.rfc-editor.org/info/rfc8
407" quoteTitle="true" derivedAnchor="RFC8407">
<front> <front>
<title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="A. Bierman" initials="A." surname="Bierman"/>
<date month="October" year="2018"/> <date month="October" year="2018"/>
<abstract> <abstract>
<t>This memo provides guidelines for authors and reviewers of spec ifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configu ration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YAN G modules. This document obsoletes RFC 6087.</t> <t indent="0">This memo provides guidelines for authors and review ers of specifications containing YANG modules. Recommendations and procedures ar e defined, which are intended to increase interoperability and usability of Netw ork Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="216"/> <seriesInfo name="BCP" value="216"/>
<seriesInfo name="RFC" value="8407"/> <seriesInfo name="RFC" value="8407"/>
<seriesInfo name="DOI" value="10.17487/RFC8407"/> <seriesInfo name="DOI" value="10.17487/RFC8407"/>
</reference> </reference>
<!--<?rfc include="reference.RFC.8439.xml"?>--> <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8
<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8 792" quoteTitle="true" derivedAnchor="RFC8792">
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml">
<front> <front>
<title>Network Management Datastore Architecture (NMDA)</title> <title>Handling Long Lines in Content of Internet-Drafts and RFCs</t
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> itle>
<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="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/> <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
<date month="March" year="2018"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<date month="June" year="2020"/>
<abstract> <abstract>
<t>Datastores are a fundamental concept binding the data models wr itten in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document define s an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t> <t indent="0">This document defines two strategies for handling lo ng lines in width-bounded text content. One strategy, called the "single backsla sh" strategy, is based on the historical use of a single backslash ('\') charact er to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. T he second strategy, called the "double backslash" strategy, extends the first st rategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8342"/> <seriesInfo name="RFC" value="8792"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/> <seriesInfo name="DOI" value="10.17487/RFC8792"/>
</reference>
<reference anchor="RFC9641" target="https://www.rfc-editor.org/info/rfc9
641" quoteTitle="true" derivedAnchor="RFC9641">
<front>
<title>A YANG Data Model for a Truststore</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9641"/>
<seriesInfo name="DOI" value="10.17487/RFC9641"/>
</reference>
<reference anchor="RFC9642" target="https://www.rfc-editor.org/info/rfc9
642" quoteTitle="true" derivedAnchor="RFC9642">
<front>
<title>A YANG Data Model for a Keystore</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9642"/>
<seriesInfo name="DOI" value="10.17487/RFC9642"/>
</reference>
<reference anchor="RFC9643" target="https://www.rfc-editor.org/info/rfc9
643" quoteTitle="true" derivedAnchor="RFC9643">
<front>
<title>YANG Groupings for TCP Clients and TCP Servers</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<author initials="M." surname="Scharf" fullname="Michael Scharf">
<organization showOnFrontPage="true">Hochschule Esslingen - Univer
sity of Applied Sciences</organization>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9643"/>
<seriesInfo name="DOI" value="10.17487/RFC9643"/>
</reference>
<reference anchor="RFC9644" target="https://www.rfc-editor.org/info/rfc9
644" quoteTitle="true" derivedAnchor="RFC9644">
<front>
<title>YANG Groupings for SSH Clients and SSH Servers</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9644"/>
<seriesInfo name="DOI" value="10.17487/RFC9644"/>
</reference>
<reference anchor="RFC9645" target="https://www.rfc-editor.org/info/rfc9
645" quoteTitle="true" derivedAnchor="RFC9645">
<front>
<title>YANG Groupings for TLS Clients and TLS Servers</title>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization
>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9645"/>
<seriesInfo name="DOI" value="10.17487/RFC9645"/>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"/>
<author initials="J." surname="Paoli" fullname="Jean Paoli"/>
<author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. S
perberg-McQueen"/>
<author initials="E." surname="Maler" fullname="Eve Maler"/>
<author initials="F." surname="Yergeau" fullname="François Yergeau"/
>
<date month="November" year="2008"/>
</front>
<seriesInfo name="World Wide Web Consortium Recomm
endation" value="REC-xml-20081126"/>
</reference> </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"> <section numbered="false" removeInRFC="false" toc="include" pn="section-appe
<name>Change Log</name> ndix.a">
<section> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<name>I-D to 00</name> <t indent="0" pn="section-appendix.a-1">The authors would like to thank th
<ul spacing="normal"> e following for
<li>Removed groupings and notifications.</li>
<li>Added typedefs for identityrefs.</li>
<li>Added typedefs for other RFC 5280 structures.</li>
<li>Added typedefs for other RFC 5652 structures.</li>
<li>Added convenience typedefs for RFC 4253, RFC 5280, and RFC 5652.</
li>
</ul>
</section>
<section>
<name>00 to 01</name>
<ul spacing="normal">
<li>Moved groupings from the draft-ietf-netconf-keystore here.</li>
</ul>
</section>
<section>
<name>01 to 02</name>
<ul spacing="normal">
<li>Removed unwanted "mandatory" and "must" statements.</li>
<li>Added many new crypto algorithms (thanks Haiguang!)</li>
<li>Clarified in asymmetric-key-pair-with-certs-grouping,
in certificates/certificate/name/description, that
if the name MUST NOT match the name of a certificate
that exists independently in &lt;operational&gt;, enabling
certs installed by the manufacturer (e.g., an IDevID).</li>
</ul>
</section>
<section>
<name>02 to 03</name>
<ul spacing="normal">
<li>renamed base identity 'asymmetric-key-encryption-algorithm' to 'as
ymmetric-key-algorithm'.</li>
<li>added new 'asymmetric-key-algorithm' identities for secp192r1, sec
p224r1, secp256r1,
secp384r1, and secp521r1.</li>
<li>removed 'mac-algorithm' identities for mac-aes-128-ccm, mac-aes-19
2-ccm, mac-aes-256-ccm,
mac-aes-128-gcm, mac-aes-192-gcm, mac-aes-256-gcm, and mac-chac
ha20-poly1305.</li>
<li>for all -cbc and -ctr identities, renamed base identity 'symmetric
-key-encryption-algorithm'
to 'encryption-algorithm'.</li>
<li>for all -ccm and -gcm identities, renamed base identity 'symmetric
-key-encryption-algorithm'
to 'encryption-and-mac-algorithm' and renamed the identity to r
emove the "enc-" prefix.</li>
<li>for all the 'signature-algorithm' based identities, renamed from '
rsa-*' to 'rsassa-*'.</li>
<li>removed all of the "x509v3-" prefixed 'signature-algorithm' based
identities.</li>
<li>added 'key-exchange-algorithm' based identities for 'rsaes-oaep' a
nd 'rsaes-pkcs1-v1_5'.</li>
<li>renamed typedef 'symmetric-key-encryption-algorithm-ref' to 'symme
tric-key-algorithm-ref'.</li>
<li>renamed typedef 'asymmetric-key-encryption-algorithm-ref' to 'asym
metric-key-algorithm-ref'.</li>
<li>added typedef 'encryption-and-mac-algorithm-ref'.</li>
<li>Updated copyright date, boilerplate template, affiliation, and fol
ding algorithm.</li>
</ul>
</section>
<section>
<name>03 to 04</name>
<ul spacing="normal">
<li>ran YANG module through formatter.</li>
</ul>
</section>
<section>
<name>04 to 05</name>
<ul spacing="normal">
<li>fixed broken symlink causing reformatted YANG module to not show.<
/li>
</ul>
</section>
<section>
<name>05 to 06</name>
<ul spacing="normal">
<li>Added NACM annotations.</li>
<li>Updated Security Considerations section.</li>
<li>Added 'asymmetric-key-pair-with-cert-grouping' grouping.</li>
<li>Removed text from 'permanently-hidden' enum regarding
such keys not being backed up or restored.</li>
<li>Updated the boilerplate text in module-level "description"
statement to match copyeditor convention.</li>
<li>Added an explanation to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements as for why the
nodes are not mandatory (e.g., because they may exist only
in &lt;operational&gt;.</li>
<li>Added 'must' expressions to the 'public-key-grouping' and
'asymmetric-key-pair-grouping' statements ensuring sibling
nodes are either all exist or do not all exist.</li>
<li>Added an explanation to the 'permanently-hidden' that the
value cannot be configured directly by clients and servers
MUST fail any attempt to do so.</li>
<li>Added 'trust-anchor-certs-grouping' and 'end-entity-certs-grouping
'
(the plural form of existing groupings).</li>
<li>Now states that keys created in &lt;operational&gt; by the
*-hidden-key actions are bound to the lifetime of the parent
'config true' node, and that subsequent invocations of either
action results in a failure.</li>
</ul>
</section>
<section>
<name>06 to 07</name>
<ul spacing="normal">
<li>Added clarifications that implementations SHOULD assert that
configured certificates contain the matching public key.</li>
<li>Replaced the 'generate-hidden-key' and 'install-hidden-key' action
s
with special 'crypt-hash' -like input/output values.</li>
</ul>
</section>
<section>
<name>07 to 08</name>
<ul spacing="normal">
<li>Removed the 'generate-key and 'hidden-key' features.</li>
<li>Added grouping symmetric-key-grouping</li>
<li>Modified 'asymmetric-key-pair-grouping' to have a 'choice'
statement for the keystone module to augment into, as well
as replacing the 'union' with leafs (having different NACM
settings.</li>
</ul>
</section>
<section>
<name>08 to 09</name>
<ul spacing="normal">
<li>Converting algorithm from identities to enumerations.</li>
</ul>
</section>
<section>
<name>09 to 10</name>
<ul spacing="normal">
<li>All the below changes are to the algorithm enumerations defined in
ietf-crypto-types.</li>
<li>Add in support for key exchange over x.25519 and x.448 based on RF
C 8418.</li>
<li>Add in SHAKE-128, SHAKE-224, SHAKE-256, SHAKE-384 and SHAKE 512</l
i>
<li>Revise/add in enum of signature algorithm for x25519 and x448</li>
<li>Add in des3-cbc-sha1 for IPSec</li>
<li>Add in sha1-des3-kd for IPSec</li>
<li>Add in definit for rc4-hmac and rc4-hmac-exp. These two algorithm
s have been deprecated in RFC 8429. But some existing draft in i2nsf may still w
ant to use them.</li>
<li>Add x25519 and x448 curve for asymmetric algorithms</li>
<li>Add signature algorithms ed25519, ed25519-cts, ed25519ph</li>
<li>add signature algorithms ed448, ed448ph</li>
<li>Add in rsa-sha2-256 and rsa-sha2-512 for SSH protocols (rfc8332)</
li>
</ul>
</section>
<section>
<name>10 to 11</name>
<ul spacing="normal">
<li>Added a "key-format" identity.</li>
<li>Added symmetric keys to the example in <xref target="crypto-types-
examples"/>.</li>
</ul>
</section>
<section>
<name>11 to 12</name>
<ul spacing="normal">
<li>Removed all non-essential (to NC/RC) algorithm types.</li>
<li>Moved remaining algorithm types each into its own module.</li>
<li>Added a 'config false' "algorithms-supported" list to each of the
algorithm-type modules.</li>
</ul>
</section>
<section>
<name>12 to 13</name>
<ul spacing="normal">
<li>Added the four features: "[encrypted-]one-[a]symmetric-key-format"
, each protecting a 'key-format' identity of the same name.</li>
<li>Added 'must' expressions asserting that the 'key-format' leaf exis
ts whenever a non-hidden key is specified.</li>
<li>Improved the 'description' statements and added 'reference' statem
ents for the 'key-format' identities.</li>
<li>Added a questionable forward reference to "encrypted-*" leafs in a
couple 'when' expressions.</li>
<li>Did NOT move "config false" alg-supported lists to SSH/TLS drafts.
</li>
</ul>
</section>
<section>
<name>13 to 14</name>
<ul spacing="normal">
<li>Resolved the "FIXME: forward ref" issue by modulating 'must', 'whe
n', and 'mandatory' expressions.</li>
<li>Moved the 'generatesymmetric-key' and 'generate-asymmetric-key' ac
tions from ietf-keystore to
ietf-crypto-types, now as RPCs.</li>
<li>Cleaned up various description statements and removed lingering FI
XMEs.</li>
<li>Converted the "iana-&lt;alg-type&gt;-algs" YANG modules to IANA re
gistries with
instructions for how to generate modules from the registries, wh
enever they may
be updated.</li>
</ul>
</section>
<section>
<name>14 to 15</name>
<ul spacing="normal">
<li>Removed the IANA-maintained registries for symmetric, asymmetric,
and hash algorithms.</li>
<li>Removed the "generate-symmetric-key" and "generate-asymmetric-key"
RPCs.</li>
<li>Removed the "algorithm" node in the various symmetric and asymmetr
ic key groupings.</li>
<li>Added 'typedef csr' and 'feature certificate-signing-request-gener
ation'.</li>
<li>Refined a usage of "end-entity-cert-grouping" to make the "cert" n
ode mandatory true.</li>
<li>Added a "Note to Reviewers" note to first page.</li>
</ul>
</section>
<section>
<name>15 to 16</name>
<ul spacing="normal">
<li>Updated draft title (refer to "Groupings" too).</li>
<li>Removed 'end-entity-certs-grouping' as it wasn't being used anywhe
re.</li>
<li>Removed 'trust-anchor-certs-grouping' as it was no longer being us
ed
after modifying 'inline-or-truststore-certs-grouping' to use lis
ts (not
leaf-lists).</li>
<li>Renamed "cert" to "cert-data" in trust-anchor-cert-grouping.</li>
<li>Added "csr-info" typedef, to complement the existing "csr" typedef
.</li>
<li>Added "ocsp-request" and "ocsp-response" typedefs, to complement
the existing "crl" typedef.</li>
<li>Added "encrypted" cases to both symmetric-key-grouping and
asymmetric-key-pair-grouping (Moved from Keystore draft).</li>
<li>Expanded "Data Model Overview section(s) [remove "wall" of tree di
agrams].</li>
<li>Updated the Security Considerations section.</li>
</ul>
</section>
<section>
<name>16 to 17</name>
<ul spacing="normal">
<li>[Re]-added a "Strength of Keys Configured" Security Consideration<
/li>
<li>Prefixed "cleartext-" in the "key" and "private-key" node names.</
li>
</ul>
</section>
<section>
<name>17 to 18</name>
<ul spacing="normal">
<li>Fixed issues found by the SecDir review of the "keystore" draft.</
li>
<li>Added "password-grouping", discussed during the IETF 108 session.<
/li>
</ul>
</section>
<section>
<name>18 to 19</name>
<ul spacing="normal">
<li>Added a "Unconstrained Public Key Usage" Security Consideration to
address
concern raised by SecDir of the 'truststore' draft.</li>
<li>Added a "Unconstrained Private Key Usage" Security Consideration t
o address
concern raised by SecDir of the 'truststore' draft.</li>
<li>Changed the encryption strategy, after conferring with Russ Housle
y.</li>
<li>Added a "password-grouping" example to the "crypto-types-usage" ex
ample.</li>
<li>Added an "Encrypting Passwords" section to Security Consideration.
</li>
<li>Addressed other comments raised by YANG Doctor.</li>
</ul>
</section>
<section>
<name>19 to 20</name>
<ul spacing="normal">
<li>Nits found via YANG Doctors reviews.</li>
<li>Aligned modules with `pyang -f` formatting.</li>
</ul>
</section>
<section>
<name>20 to 21</name>
<ul spacing="normal">
<li>Replaced "base64encodedvalue==" with "BASE64VALUE=".</li>
<li>Accommodated SecDir review by Valery Smyslov.</li>
</ul>
</section>
<section>
<name>21 to 22</name>
<ul spacing="normal">
<li>fixup the 'WG Web' and 'WG List' lines in YANG module(s)</li>
<li>fixup copyright (i.e., s/Simplified/Revised/) in YANG module(s)</l
i>
<li>added 'hidden-keys' feature.</li>
</ul>
</section>
<section>
<name>22 to 23</name>
<ul spacing="normal">
<li>Fixed an example to reference correct key.</li>
<li>Fixed an example to not have line-returns around the encoding for
a binary value.</li>
</ul>
</section>
<section>
<name>23 to 24</name>
<ul spacing="normal">
<li>Added mandatory leaf "csr-format" to action "generate-csr".</li>
<li>s/certificate-signing-request/csr/g in the YANG module.</li>
</ul>
</section>
<section>
<name>24 to 25</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</li>
</ul>
</section>
<section>
<name>25 to 26</name>
<ul spacing="normal">
<li>Updated per Shepherd reviews impacting the suite of drafts.</li>
</ul>
</section>
<section>
<name>26 to 27</name>
<ul spacing="normal">
<li>Updated per Tom Petch and AD reviews.</li>
<li>Renamed numerous "feature" statements and some "grouping" statemen
ts (in YANG)</li>
<li>Added "csr-format" and "p10-csr-format" identities to doc (they we
re already in YANG)</li>
<li>Clarified that the 'rsa-private-key-format' and 'ec-private-key-fo
rmat' formats must be encoded using DER</li>
<li>Added 'if-feature cleartext-passwords' statement to 'case cleartex
t-password' in grouping 'password-grouping'.</li>
<li>Added 'if-feature cleartext-keys' statement to 'case cleartext-key
' in grouping 'symmetric-key-grouping'.</li>
<li>Added 'if-feature cleartext-cleartext-private-keys' statement to '
case cleartext-private-key' in grouping 'asymmetric-key-grouping'.</li>
<li>Updated Section titles.</li>
<li>Clarified Security Considerations about the "generate-public-key"
RPCs.</li>
</ul>
</section>
<section>
<name>27 to 28</name>
<ul spacing="normal">
<li>Mostly addresses AD review comments.</li>
<li>Also addresses on-list comment regarding public-keys being "mandat
ory true."</li>
<li>Added note to Editor to fix line foldings.</li>
<li>Factored 'private-key-grouping' from 'asymmetric-key-pair-grouping
'.</li>
<li>Made public-key in 'asymmetric-key-pair-grouping' be "mandatory fa
lse".</li>
<li>Renamed 'encrypted-by-choice-grouping' to 'encrypted-by-grouping'.
</li>
</ul>
</section>
<section>
<name>28 to 29</name>
<ul spacing="normal">
<li>Addresses Gen-ART review by Dale Worley.</li>
<li>Addresses review by Tom Petch.</li>
</ul>
</section>
<section>
<name>29 to 30</name>
<ul spacing="normal">
<li>Addresses 1st-round of IESG reviews.</li>
</ul>
</section>
<section>
<name>30 to 32</name>
<ul spacing="normal">
<li>Addresses issues found in OpsDir of the ssh-client-server draft.</
li>
<li>Removed "Strength of Keys Conveyed" section.</li>
<li>Renamed Security Considerations section s/Template for/Considerati
ons for/</li>
<li>Improved Security Consideration for 'cert-data' node.</li>
</ul>
</section>
<section>
<name>32 to 34</name>
<ul spacing="normal">
<li>Nothing changed. Only bumped for automation...</li>
</ul>
</section>
</section>
<section numbered="false">
<name>Acknowledgements</name>
<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>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="K." surname="Watsen" fullname="Kent Watsen">
<organization showOnFrontPage="true">Watsen Networks</organization>
<address>
<email>kent+ietf@watsen.net</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 313 change blocks. 
1607 lines changed or deleted 1923 lines changed or added

This html diff was produced by rfcdiff 1.48.