Diff: rfc9640v4.txt - rfc9640.txt

	rfc9640v4.txt	rfc9640.txt

	Internet Engineering Task Force (IETF) K. Watsen	Internet Engineering Task Force (IETF) K. Watsen
	Request for Comments: 9640 Watsen Networks	Request for Comments: 9640 Watsen Networks

	Category: Standards Track September 2024	Category: Standards Track October 2024
	ISSN: 2070-1721	ISSN: 2070-1721

	YANG Data Types and Groupings for Cryptography	YANG Data Types and Groupings for Cryptography

	Abstract	Abstract

	This document presents a YANG 1.1 (RFC 7950) module defining	This document presents a YANG 1.1 (RFC 7950) module defining
	identities, typedefs, and groupings useful to cryptographic	identities, typedefs, and groupings useful to cryptographic
	applications.	applications.


	skipping to change at line 167 ¶	skipping to change at line 167 ¶
	accessible nodes that are "config false".	accessible nodes that are "config false".

	1.4. Conventions	1.4. Conventions

	Various examples in this document use "BASE64VALUE=" as a placeholder	Various examples in this document use "BASE64VALUE=" as a placeholder
	value for binary data that has been base64 encoded (per Section 9.8	value for binary data that has been base64 encoded (per Section 9.8
	of [RFC7950]). This placeholder value is used because real	of [RFC7950]). This placeholder value is used because real
	base64-encoded structures are often many lines long and hence	base64-encoded structures are often many lines long and hence
	distracting to the example being presented.	distracting to the example being presented.


		Various examples in this document use the XML [W3C.REC-xml-20081126]
		encoding. Other encodings, such as JSON [RFC8259], could
		alternatively be used.

		Various examples in this document contain long lines that may be
		folded, as described in [RFC8792].

	2. The "ietf-crypto-types" Module	2. The "ietf-crypto-types" Module

	This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto-	This section defines a YANG 1.1 [RFC7950] module called "ietf-crypto-
	types". A high-level overview of the module is provided in	types". A high-level overview of the module is provided in
	Section 2.1. Examples illustrating the module's use are provided in	Section 2.1. Examples illustrating the module's use are provided in
	Section 2.2. The YANG module itself is defined in Section 2.3.	Section 2.2. The YANG module itself is defined in Section 2.3.

	2.1. Data Model Overview	2.1. Data Model Overview

	This section provides an overview of the "ietf-crypto-types" module	This section provides an overview of the "ietf-crypto-types" module

	skipping to change at line 606 ¶	skipping to change at line 613 ¶
	+--ro (csr-type)	+--ro (csr-type)
	+--:(p10-csr)	+--:(p10-csr)
	+--ro p10-csr? p10-csr	+--ro p10-csr? p10-csr

	Comments:	Comments:

	* This grouping's only purpose is to define the "generate-csr"	* This grouping's only purpose is to define the "generate-csr"
	action statement, used by the groupings defined in Sections	action statement, used by the groupings defined in Sections
	2.1.4.11 and 2.1.4.12.	2.1.4.11 and 2.1.4.12.


	* This action takes two input parameters: a "csr-info” parameter,	* This action takes two input parameters: a "csr-info" parameter,
	for what content should be in the certificate, and a “csr-format”	for what content should be in the certificate, and a "csr-format"
	parameter, for what CSR format to return. The action returns the	parameter, for what CSR format to return. The action returns the

	CSR in the specified format. Both the “csr-info” and “csr” types	CSR in the specified format. Both the "csr-info" and "csr" types
	are discussed in Section 2.1.3.	are discussed in Section 2.1.3.

	* For an example, please see Section 2.2.2.	* For an example, please see Section 2.2.2.

	2.1.4.11. The "asymmetric-key-pair-with-cert-grouping" Grouping	2.1.4.11. The "asymmetric-key-pair-with-cert-grouping" Grouping

	This section presents a tree diagram [RFC8340] illustrating the	This section presents a tree diagram [RFC8340] illustrating the
	"asymmetric-key-pair-with-cert-grouping" grouping. This tree diagram	"asymmetric-key-pair-with-cert-grouping" grouping. This tree diagram
	does not expand the internally used "grouping" statement(s):	does not expand the internally used "grouping" statement(s):


	skipping to change at line 916 ¶	skipping to change at line 923 ¶
	\| +--:(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

	2.2.1.3. Usage Example for the Example Module	2.2.1.3. Usage Example for the Example Module

	Finally, the following example illustrates various symmetric and	Finally, the following example illustrates various symmetric and
	asymmetric keys as they might appear in configuration.	asymmetric keys as they might appear in configuration.


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	Note that long lines in examples are wrapped as described in
	[RFC8792].

	=============== NOTE: '\' line wrapping per RFC 8792 ================	=============== NOTE: '\' line wrapping per RFC 8792 ================

	<symmetric-keys	<symmetric-keys
	xmlns="https://example.com/ns/example-crypto-types-usage"	xmlns="https://example.com/ns/example-crypto-types-usage"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
	<symmetric-key>	<symmetric-key>
	<name>ex-hidden-symmetric-key</name>	<name>ex-hidden-symmetric-key</name>
	<hidden-symmetric-key/>	<hidden-symmetric-key/>
	</symmetric-key>	</symmetric-key>
	<symmetric-key>	<symmetric-key>

	skipping to change at line 1040 ¶	skipping to change at line 1042 ¶
	<encrypted-value>BASE64VALUE=</encrypted-value>	<encrypted-value>BASE64VALUE=</encrypted-value>
	</encrypted-password>	</encrypted-password>
	</password>	</password>
	</passwords>	</passwords>

	2.2.2. The "generate-csr" Action	2.2.2. The "generate-csr" Action

	The following example illustrates the "generate-csr" action,	The following example illustrates the "generate-csr" action,
	discussed in Section 2.1.4.10, with the NETCONF protocol.	discussed in Section 2.1.4.10, with the NETCONF protocol.


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	REQUEST	REQUEST

	<rpc message-id="101"	<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">
	<action xmlns="urn:ietf:params:xml:ns:yang:1">	<action xmlns="urn:ietf:params:xml:ns:yang:1">
	<asymmetric-keys	<asymmetric-keys
	xmlns="https://example.com/ns/example-crypto-types-usage">	xmlns="https://example.com/ns/example-crypto-types-usage">
	<asymmetric-key>	<asymmetric-key>
	<name>ex-hidden-asymmetric-key</name>	<name>ex-hidden-asymmetric-key</name>
	<generate-csr>	<generate-csr>
	<csr-format>ct:p10-csr-format</csr-format>	<csr-format>ct:p10-csr-format</csr-format>
	<csr-info>BASE64VALUE=</csr-info>	<csr-info>BASE64VALUE=</csr-info>
	</generate-csr>	</generate-csr>
	</asymmetric-key>	</asymmetric-key>
	</asymmetric-keys>	</asymmetric-keys>
	</action>	</action>
	</rpc>	</rpc>


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	RESPONSE	RESPONSE

	=============== NOTE: '\' line wrapping per RFC 8792 ================	=============== NOTE: '\' line wrapping per RFC 8792 ================

	<rpc-reply message-id="101"	<rpc-reply message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\	<p10-csr xmlns="https://example.com/ns/example-crypto-types-usage"\
	>BASE64VALUE=</p10-csr>	>BASE64VALUE=</p10-csr>
	</rpc-reply>	</rpc-reply>

	2.2.3. The "certificate-expiration" Notification	2.2.3. The "certificate-expiration" Notification

	The following example illustrates the "certificate-expiration"	The following example illustrates the "certificate-expiration"
	notification, discussed in Section 2.1.4.7, with the NETCONF	notification, discussed in Section 2.1.4.7, with the NETCONF
	protocol.	protocol.


	The following example uses the XML [W3C.REC-xml-20081126] encoding.

	=============== NOTE: '\' line wrapping per RFC 8792 ================	=============== NOTE: '\' line wrapping per RFC 8792 ================

	<notification	<notification
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<eventTime>2018-05-25T00:01:00Z</eventTime>	<eventTime>2018-05-25T00:01:00Z</eventTime>
	<asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\	<asymmetric-keys xmlns="https://example.com/ns/example-crypto-type\
	s-usage">	s-usage">
	<asymmetric-key>	<asymmetric-key>
	<name>ex-hidden-asymmetric-key</name>	<name>ex-hidden-asymmetric-key</name>
	<certificates>	<certificates>

	skipping to change at line 2315 ¶	skipping to change at line 2311 ¶
	The cleartext key values are the "cleartext-symmetric-key" node	The cleartext key values are the "cleartext-symmetric-key" node
	defined in the "symmetric-key-grouping" grouping (Section 2.1.4.3)	defined in the "symmetric-key-grouping" grouping (Section 2.1.4.3)
	and the "cleartext-private-key" node defined in the "asymmetric-key-	and the "cleartext-private-key" node defined in the "asymmetric-key-
	pair-grouping" grouping (Section 2.1.4.6).	pair-grouping" grouping (Section 2.1.4.6).

	3.8. Considerations for the "ietf-crypto-types" YANG Module	3.8. Considerations for the "ietf-crypto-types" YANG Module

	This section is modeled after the template defined in Section 3.7.1	This section is modeled after the template defined in Section 3.7.1
	of [RFC8407].	of [RFC8407].


	The YANG module in this document defines "grouping" statements that	The "ietf-crypto-types" YANG module defines "grouping" statements
	are designed to be accessed via YANG-based management protocols, such	that are designed to be accessed via YANG-based management protocols,
	as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols	such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these
	have mandatory-to-implement secure transport layers (e.g., Secure	protocols have mandatory-to-implement secure transport layers (e.g.,
	Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and	Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and
	mandatory-to-implement mutual authentication.	mandatory-to-implement mutual authentication.

	The Network Configuration Access Control Model (NACM) [RFC8341]	The Network Configuration Access Control Model (NACM) [RFC8341]
	provides the means to restrict access for particular users to a	provides the means to restrict access for particular users to a
	preconfigured subset of all available protocol operations and	preconfigured subset of all available protocol operations and
	content.	content.

	Since the module in this document only defines groupings, these	Since the module in this document only defines groupings, these
	considerations are primarily for the designers of other modules that	considerations are primarily for the designers of other modules that
	use these groupings.	use these groupings.

	skipping to change at line 2573 ¶	skipping to change at line 2569 ¶

	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,	the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,	DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.	<https://www.rfc-editor.org/info/rfc6020>.

	[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for	[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
	System Management", RFC 7317, DOI 10.17487/RFC7317, August	System Management", RFC 7317, DOI 10.17487/RFC7317, August
	2014, <https://www.rfc-editor.org/info/rfc7317>.	2014, <https://www.rfc-editor.org/info/rfc7317>.


		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
		Interchange Format", STD 90, RFC 8259,
		DOI 10.17487/RFC8259, December 2017,
		<https://www.rfc-editor.org/info/rfc8259>.

	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.	<https://www.rfc-editor.org/info/rfc8340>.

	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture	and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.	<https://www.rfc-editor.org/info/rfc8342>.

	[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of	[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
	Documents Containing YANG Data Models", BCP 216, RFC 8407,	Documents Containing YANG Data Models", BCP 216, RFC 8407,
	DOI 10.17487/RFC8407, October 2018,	DOI 10.17487/RFC8407, October 2018,
	<https://www.rfc-editor.org/info/rfc8407>.	<https://www.rfc-editor.org/info/rfc8407>.

	[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,	[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
	"Handling Long Lines in Content of Internet-Drafts and	"Handling Long Lines in Content of Internet-Drafts and
	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
	<https://www.rfc-editor.org/info/rfc8792>.	<https://www.rfc-editor.org/info/rfc8792>.

	[RFC9641] Watsen, K., "A YANG Data Model for a Truststore",	[RFC9641] Watsen, K., "A YANG Data Model for a Truststore",

	RFC 9641, DOI 10.17487/RFC9641, September 2024,	RFC 9641, DOI 10.17487/RFC9641, October 2024,
	<https://www.rfc-editor.org/info/rfc9641>.	<https://www.rfc-editor.org/info/rfc9641>.

	[RFC9642] Watsen, K., "A YANG Data Model for a Keystore", RFC 9642,	[RFC9642] Watsen, K., "A YANG Data Model for a Keystore", RFC 9642,

	DOI 10.17487/RFC9642, September 2024,	DOI 10.17487/RFC9642, October 2024,
	<https://www.rfc-editor.org/info/rfc9642>.	<https://www.rfc-editor.org/info/rfc9642>.

	[RFC9643] Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients	[RFC9643] Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients

	and TCP Servers", RFC 9643, DOI 10.17487/RFC9643,	and TCP Servers", RFC 9643, DOI 10.17487/RFC9643, October
	September 2024, <https://www.rfc-editor.org/info/rfc9643>.	2024, <https://www.rfc-editor.org/info/rfc9643>.

	[RFC9644] Watsen, K., "YANG Groupings for SSH Clients and SSH	[RFC9644] Watsen, K., "YANG Groupings for SSH Clients and SSH

	Servers", RFC 9644, DOI 10.17487/RFC9644, September 2024,	Servers", RFC 9644, DOI 10.17487/RFC9644, October 2024,
	<https://www.rfc-editor.org/info/rfc9644>.	<https://www.rfc-editor.org/info/rfc9644>.

	[RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS	[RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS

	Servers", RFC 9645, DOI 10.17487/RFC9645, September 2024,	Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024,
	<https://www.rfc-editor.org/info/rfc9645>.	<https://www.rfc-editor.org/info/rfc9645>.

	[W3C.REC-xml-20081126]	[W3C.REC-xml-20081126]
	Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,	Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
	and F. Yergeau, "Extensible Markup Language (XML) 1.0	and F. Yergeau, "Extensible Markup Language (XML) 1.0
	(Fifth Edition)", World Wide Web Consortium	(Fifth Edition)", World Wide Web Consortium
	Recommendation REC-xml-20081126, November 2008,	Recommendation REC-xml-20081126, November 2008,
	<https://www.w3.org/TR/2008/REC-xml-20081126/>.	<https://www.w3.org/TR/2008/REC-xml-20081126/>.

	Acknowledgements	Acknowledgements

End of changes. 15 change blocks.
	26 lines changed or deleted	27 lines changed or added
This html diff was produced by rfcdiff 1.48.