Diff: rfc9642v2.txt - rfc9642.txt

	rfc9642v2.txt	rfc9642.txt

	skipping to change at line 490 ¶	skipping to change at line 490 ¶
	grouping" grouping discussed in Section 2.1.3.2.	grouping" grouping discussed in Section 2.1.3.2.

	2.1.3.7. The "keystore-grouping" Grouping	2.1.3.7. The "keystore-grouping" Grouping

	The following tree diagram [RFC8340] illustrates the "keystore-	The following tree diagram [RFC8340] illustrates the "keystore-
	grouping" grouping:	grouping" grouping:

	grouping keystore-grouping:	grouping keystore-grouping:
	+-- asymmetric-keys {asymmetric-keys}?	+-- asymmetric-keys {asymmetric-keys}?
	\| +-- asymmetric-key* [name]	\| +-- asymmetric-key* [name]

	\| +-- name? string	\| +-- name string
	\| +---u ct:asymmetric-key-pair-with-certs-grouping	\| +---u ct:asymmetric-key-pair-with-certs-grouping
	+-- symmetric-keys {symmetric-keys}?	+-- symmetric-keys {symmetric-keys}?
	+-- symmetric-key* [name]	+-- symmetric-key* [name]

	+-- name? string	+-- name string
	+---u ct:symmetric-key-grouping	+---u ct:symmetric-key-grouping

	Comments:	Comments:

	* The "keystore-grouping" grouping defines a keystore instance as	* The "keystore-grouping" grouping defines a keystore instance as
	being composed of symmetric and asymmetric keys. The structure	being composed of symmetric and asymmetric keys. The structure
	for the symmetric and asymmetric keys is essentially the same: a	for the symmetric and asymmetric keys is essentially the same: a
	"list" inside a "container".	"list" inside a "container".

	* For asymmetric keys, each "asymmetric-key" uses the "asymmetric-	* For asymmetric keys, each "asymmetric-key" uses the "asymmetric-

	skipping to change at line 524 ¶	skipping to change at line 524 ¶
	accessible nodes defined in the "ietf-keystore" module without	accessible nodes defined in the "ietf-keystore" module without
	expanding the "grouping" statements:	expanding the "grouping" statements:

	module: ietf-keystore	module: ietf-keystore
	+--rw keystore {central-keystore-supported}?	+--rw keystore {central-keystore-supported}?
	+---u keystore-grouping	+---u keystore-grouping

	The following tree diagram [RFC8340] lists all the protocol-	The following tree diagram [RFC8340] lists all the protocol-
	accessible nodes defined in the "ietf-keystore" module, with all	accessible nodes defined in the "ietf-keystore" module, with all
	"grouping" statements expanded, enabling the keystore's full	"grouping" statements expanded, enabling the keystore's full

	structure to be seen:	structure to be seen.

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

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

	module: ietf-keystore	module: ietf-keystore
	+--rw keystore {central-keystore-supported}?	+--rw keystore {central-keystore-supported}?
	+--rw asymmetric-keys {asymmetric-keys}?	+--rw asymmetric-keys {asymmetric-keys}?
	\| +--rw asymmetric-key* [name]	\| +--rw asymmetric-key* [name]
	\| +--rw name string	\| +--rw name string
	\| +--rw public-key-format? identityref	\| +--rw public-key-format? identityref
	\| +--rw public-key? binary	\| +--rw public-key? binary

	skipping to change at line 622 ¶	skipping to change at line 625 ¶

	* The "keystore-grouping" grouping is discussed in Section 2.1.3.7.	* The "keystore-grouping" grouping is discussed in Section 2.1.3.7.

	* The reason for why "keystore-grouping" exists separate from the	* The reason for why "keystore-grouping" exists separate from the
	protocol-accessible nodes definition is to enable instances of the	protocol-accessible nodes definition is to enable instances of the
	keystore to be instantiated in other locations, as may be needed	keystore to be instantiated in other locations, as may be needed
	or desired by some modules.	or desired by some modules.

	2.2. Example Usage	2.2. Example Usage


	The examples in this section are encoded using XML, such as might be	The examples in this section are encoded using XML
	the case when using the NETCONF protocol. Other encodings MAY be	[W3C.REC-xml-20081126], such as might be the case when using the
	used, such as JSON when using the RESTCONF protocol.	NETCONF protocol. Other encodings MAY be used, such as JSON when
		using the RESTCONF protocol.

	2.2.1. A Keystore Instance	2.2.1. A Keystore Instance

	The following example illustrates keys in <running>. Please see	The following example illustrates keys in <running>. Please see
	Section 3 for an example illustrating built-in values in	Section 3 for an example illustrating built-in values in
	<operational>.	<operational>.

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

	<keystore	<keystore

	skipping to change at line 776 ¶	skipping to change at line 780 ¶
	<expiration-date>2018-08-05T14:18:53-05:00</expiration\	<expiration-date>2018-08-05T14:18:53-05:00</expiration\
	-date>	-date>
	</certificate-expiration>	</certificate-expiration>
	</certificate>	</certificate>
	</certificates>	</certificates>
	</asymmetric-key>	</asymmetric-key>
	</asymmetric-keys>	</asymmetric-keys>
	</keystore>	</keystore>
	</notification>	</notification>


	2.2.3. The "Local or Keystore" Groupings	2.2.3. The "Inline or Keystore" Groupings

	This section illustrates the various "inline-or-keystore" groupings	This section illustrates the various "inline-or-keystore" groupings
	defined in the "ietf-keystore" module, specifically the "inline-or-	defined in the "ietf-keystore" module, specifically the "inline-or-
	keystore-symmetric-key-grouping" (Section 2.1.3.3), "inline-or-	keystore-symmetric-key-grouping" (Section 2.1.3.3), "inline-or-
	keystore-asymmetric-key-grouping" (Section 2.1.3.4), "inline-or-	keystore-asymmetric-key-grouping" (Section 2.1.3.4), "inline-or-
	keystore-asymmetric-key-with-certs-grouping" (Section 2.1.3.5), and	keystore-asymmetric-key-with-certs-grouping" (Section 2.1.3.5), and
	"inline-or-keystore-end-entity-cert-with-key-grouping"	"inline-or-keystore-end-entity-cert-with-key-grouping"
	(Section 2.1.3.6) groupings.	(Section 2.1.3.6) groupings.

	These examples assume the existence of an example module called "ex-	These examples assume the existence of an example module called "ex-

	skipping to change at line 1591 ¶	skipping to change at line 1595 ¶

	The primary characteristic of the built-in keys is that they are	The primary characteristic of the built-in keys is that they are
	provided by the server, as opposed to being configured. As such,	provided by the server, as opposed to being configured. As such,
	they are present in <operational> (Section 5.3 of [RFC8342]) and	they are present in <operational> (Section 5.3 of [RFC8342]) and
	<system> [NETMOD-SYSTEM-CONFIG], if implemented.	<system> [NETMOD-SYSTEM-CONFIG], if implemented.

	The example below illustrates what the keystore in <operational>	The example below illustrates what the keystore in <operational>
	might look like for a server in its factory default state. Note that	might look like for a server in its factory default state. Note that
	the built-in keys have the "or:origin" annotation value "or:system".	the built-in keys have the "or:origin" annotation value "or:system".


		Note: the following examples use XML [W3C.REC-xml-20081126] encoding.

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

	<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"	<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types"
	xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"	xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
	or:origin="or:intended">	or:origin="or:intended">
	<asymmetric-keys>	<asymmetric-keys>
	<asymmetric-key or:origin="or:system">	<asymmetric-key or:origin="or:system">
	<name>Manufacturer-Generated Hidden Key</name>	<name>Manufacturer-Generated Hidden Key</name>
	<public-key-format>ct:subject-public-key-info-format</public-k\	<public-key-format>ct:subject-public-key-info-format</public-k\

	skipping to change at line 1876 ¶	skipping to change at line 1882 ¶
	This module also does not constrain the usage of the associated	This module also does not constrain the usage of the associated
	public keys other than in the context of a configured certificate	public keys other than in the context of a configured certificate
	(e.g., an identity certificate), in which case the key usage is	(e.g., an identity certificate), in which case the key usage is
	constrained by the certificate.	constrained by the certificate.

	5.3. Security Considerations for the "ietf-keystore" YANG Module	5.3. Security Considerations for the "ietf-keystore" YANG Module

	This section follows the template defined in Section 3.7.1 of	This section follows the template defined in Section 3.7.1 of
	[RFC8407].	[RFC8407].


	The YANG module specified in this document defines a schema for data	The ietf-keystore YANG module defines a data model that is designed
	that is designed to be accessed via network management protocols such	to be accessed via YANG-based management protocols, such as NETCONF
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. Both of these protocols	[RFC6241] and RESTCONF [RFC8040]. These protocols have mandatory-to-
	have mandatory-to-implement secure transport layers (e.g., Secure	implement secure transport layers (e.g., SSH [RFC4252], TLS
	Shell (SSH), TLS) with mutual authentication.	[RFC8446], and QUIC [RFC9000]) and mandatory-to-implement mutal
		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.

	Please be aware that this YANG module uses groupings from other YANG	Please be aware that this YANG module uses groupings from other YANG
	modules that define nodes that may be considered sensitive or	modules that define nodes that may be considered sensitive or
	vulnerable in network environments. Please review the Security	vulnerable in network environments. Please review the Security
	Considerations for dependent YANG modules for information as to which	Considerations for dependent YANG modules for information as to which

	skipping to change at line 1962 ¶	skipping to change at line 1969 ¶

	7. References	7. References

	7.1. Normative References	7.1. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.


		[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
		Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
		January 2006, <https://www.rfc-editor.org/info/rfc4252>.

	[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>.

	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol	and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.	<https://www.rfc-editor.org/info/rfc6241>.


	skipping to change at line 1989 ¶	skipping to change at line 2000 ¶

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
	Access Control Model", STD 91, RFC 8341,	Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018,	DOI 10.17487/RFC8341, March 2018,
	<https://www.rfc-editor.org/info/rfc8341>.	<https://www.rfc-editor.org/info/rfc8341>.


		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
		<https://www.rfc-editor.org/info/rfc8446>.

		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
		Multiplexed and Secure Transport", RFC 9000,
		DOI 10.17487/RFC9000, May 2021,
		<https://www.rfc-editor.org/info/rfc9000>.

	[RFC9640] Watsen, K., "YANG Data Types and Groupings for	[RFC9640] Watsen, K., "YANG Data Types and Groupings for
	Cryptography", RFC 9640, DOI 10.17487/RFC9640, August	Cryptography", RFC 9640, DOI 10.17487/RFC9640, August
	2024, <https://www.rfc-editor.org/info/rfc9640>.	2024, <https://www.rfc-editor.org/info/rfc9640>.

	7.2. Informative References	7.2. Informative References

	[HTTP-CLIENT-SERVER]	[HTTP-CLIENT-SERVER]
	Watsen, K., "YANG Groupings for HTTP Clients and HTTP	Watsen, K., "YANG Groupings for HTTP Clients and HTTP
	Servers", Work in Progress, Internet-Draft, draft-ietf-	Servers", Work in Progress, Internet-Draft, draft-ietf-
	netconf-http-client-server-23, 15 August 2024,	netconf-http-client-server-23, 15 August 2024,

	skipping to change at line 2041 ¶	skipping to change at line 2061 ¶
	[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,
		"Handling Long Lines in Content of Internet-Drafts and
		RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
		<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, August 2024,	RFC 9641, DOI 10.17487/RFC9641, August 2024,
	<https://www.rfc-editor.org/info/rfc9641>.	<https://www.rfc-editor.org/info/rfc9641>.

	[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, August	and TCP Servers", RFC 9643, DOI 10.17487/RFC9643, August
	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, August 2024,	Servers", RFC 9644, DOI 10.17487/RFC9644, August 2024,

	skipping to change at line 2063 ¶	skipping to change at line 2088 ¶
	[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, August 2024,	Servers", RFC 9645, DOI 10.17487/RFC9645, August 2024,
	<https://www.rfc-editor.org/info/rfc9645>.	<https://www.rfc-editor.org/info/rfc9645>.

	[Std-802.1AR-2018]	[Std-802.1AR-2018]
	IEEE, "IEEE Standard for Local and Metropolitan Area	IEEE, "IEEE Standard for Local and Metropolitan Area
	Networks - Secure Device Identity", IEEE Std 802.1AR-2018,	Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
	DOI 10.1109/IEEESTD.2018.8423794, August 2018,	DOI 10.1109/IEEESTD.2018.8423794, August 2018,
	<https://standards.ieee.org/standard/802_1AR-2018.html>.	<https://standards.ieee.org/standard/802_1AR-2018.html>.


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

	Acknowledgements	Acknowledgements

	The authors would like to thank the following for lively discussions	The authors would like to thank the following for lively discussions
	on list and in the halls (ordered by first name): Alan Luchuk, Andy	on list and in the halls (ordered by first name): Alan Luchuk, Andy
	Bierman, Balázs Kovács, Benoit Claise, Bert Wijnen, David Lamparter,	Bierman, Balázs Kovács, Benoit Claise, Bert Wijnen, David Lamparter,
	Eric Voit, Éric Vyncke, Francesca Palombini, Jürgen Schönwälder,	Eric Voit, Éric Vyncke, Francesca Palombini, Jürgen Schönwälder,
	Ladislav Lhotka, Liang Xia, Magnus Nyström, Mahesh Jethanandani,	Ladislav Lhotka, Liang Xia, Magnus Nyström, Mahesh Jethanandani,
	Martin Björklund, Mehmet Ersue, Murray Kucherawy, Paul Wouters, Phil	Martin Björklund, Mehmet Ersue, Murray Kucherawy, Paul Wouters, Phil
	Shafer, Qin Wu, Radek Krejci, Ramkumar Dhanapal, Reese Enghardt,	Shafer, Qin Wu, Radek Krejci, Ramkumar Dhanapal, Reese Enghardt,
	Reshad Rahman, Rob Wilton, Roman Danyliw, Sandra Murphy, Sean Turner,	Reshad Rahman, Rob Wilton, Roman Danyliw, Sandra Murphy, Sean Turner,

End of changes. 11 change blocks.
	12 lines changed or deleted	43 lines changed or added
This html diff was produced by rfcdiff 1.48.