Diff: rfc9641v4.txt - rfc9641.txt

	rfc9641v4.txt	rfc9641.txt

	skipping to change at line 174 ¶	skipping to change at line 174 ¶
	1.3. Adherence to the NMDA	1.3. Adherence to the NMDA

	This document is compliant with the Network Management Datastore	This document is compliant with the Network Management Datastore
	Architecture (NMDA) [RFC8342]. For instance, trust anchors installed	Architecture (NMDA) [RFC8342]. For instance, trust anchors installed
	during manufacturing (e.g., for trusted, well-known services) are	during manufacturing (e.g., for trusted, well-known services) are
	expected to appear in <operational> (see Section 3).	expected to appear in <operational> (see Section 3).

	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 (see Section 4 of	value for binary data that has been base64 encoded (see Section 9.8
	[RFC4648]). 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].

	This document uses the adjective "central" with the word "truststore"	This document uses the adjective "central" with the word "truststore"
	to refer to the top-level instance of the "truststore-grouping"	to refer to the top-level instance of the "truststore-grouping"
	grouping when the "central-truststore-supported" feature is enabled.	grouping when the "central-truststore-supported" feature is enabled.
	Please be aware that consuming YANG modules MAY instantiate the	Please be aware that consuming YANG modules MAY instantiate the
	"truststore-grouping" grouping in other locations. All such other	"truststore-grouping" grouping in other locations. All such other
	instances are not the "central" instance.	instances are not the "central" instance.

	2. The "ietf-truststore" Module	2. The "ietf-truststore" Module

	This section defines a YANG 1.1 [RFC7950] module called "ietf-	This section defines a YANG 1.1 [RFC7950] module called "ietf-

	skipping to change at line 510 ¶	skipping to change at line 517 ¶
	+-- End entity certs for authenticating a set of remote servers	+-- End entity certs for authenticating a set of remote servers
	+-- Trust anchor certs for authenticating a set of remote clients	+-- Trust anchor certs for authenticating a set of remote clients
	+-- End entity certs for authenticating a set of remote clients	+-- End entity certs for authenticating a set of remote clients

	Public Key Bags	Public Key Bags
	+-- SSH keys to authenticate a set of remote SSH servers	+-- SSH keys to authenticate a set of remote SSH servers
	+-- SSH keys to authenticate a set of remote SSH clients	+-- SSH keys to authenticate a set of remote SSH clients
	+-- Raw public keys to authenticate a set of remote SSH servers	+-- Raw public keys to authenticate a set of remote SSH servers
	+-- Raw public keys to authenticate a set of remote SSH clients	+-- Raw public keys to authenticate a set of remote SSH clients


	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 ================

	<truststore	<truststore
	xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"	xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">

	<!-- A bag of Certificate Bags -->	<!-- A bag of Certificate Bags -->
	<certificate-bags>	<certificate-bags>

	<!-- Trust Anchor Certs for Authenticating Servers -->	<!-- Trust Anchor Certs for Authenticating Servers -->

	skipping to change at line 693 ¶	skipping to change at line 695 ¶
	</public-key-bag>	</public-key-bag>
	</public-key-bags>	</public-key-bags>
	</truststore>	</truststore>

	2.2.2. A Certificate Expiration Notification	2.2.2. A Certificate Expiration Notification

	The following example illustrates the "certificate-expiration"	The following example illustrates the "certificate-expiration"
	notification (per Section 2.1.4.7 of [RFC9640]) for a certificate	notification (per Section 2.1.4.7 of [RFC9640]) for a certificate
	configured in the truststore described in Section 2.2.1.	configured in the truststore described in Section 2.2.1.


	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>
	<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">	<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
	<certificate-bags>	<certificate-bags>
	<certificate-bag>	<certificate-bag>
	<name>trusted-client-ee-certs</name>	<name>trusted-client-ee-certs</name>
	<certificate>	<certificate>

	skipping to change at line 788 ¶	skipping to change at line 788 ¶
	ts:central-public-key-bag-ref	ts:central-public-key-bag-ref

	The following example provides two equivalent instances of each	The following example provides two equivalent instances of each
	grouping, the first being a reference to a truststore and the second	grouping, the first being a reference to a truststore and the second
	being defined inline. The instance having a reference to a	being defined inline. The instance having a reference to a
	truststore is consistent with the truststore defined in	truststore is consistent with the truststore defined in
	Section 2.2.1. The two instances are equivalent, as the inlined	Section 2.2.1. The two instances are equivalent, as the inlined
	instance example contains the same values defined by the truststore	instance example contains the same values defined by the truststore
	instance referenced by its sibling example.	instance referenced by its sibling example.


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

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

	<truststore-usage	<truststore-usage
	xmlns="https://example.com/ns/example-truststore-usage"	xmlns="https://example.com/ns/example-truststore-usage"
	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">	xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">

	<!-- The following two equivalent examples illustrate -->	<!-- The following two equivalent examples illustrate -->
	<!-- the "inline-or-truststore-certs-grouping" grouping: -->	<!-- the "inline-or-truststore-certs-grouping" grouping: -->

	<cert>	<cert>

	skipping to change at line 1328 ¶	skipping to change at line 1326 ¶
	The primary characteristic of the built-in trust anchors is that they	The primary characteristic of the built-in trust anchors is that they
	are provided by the server, as opposed to configuration. As such,	are provided by the server, as opposed to configuration. 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 truststore in <operational>	The example below illustrates what the truststore 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 trust anchor bags have the "or:origin" annotation value	the built-in trust anchor bags have the "or:origin" annotation value
	"or:system".	"or:system".


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

	<truststore	<truststore
	xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"	xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore"
	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">
	<certificate-bags>	<certificate-bags>

	<certificate-bag or:origin="or:system">	<certificate-bag or:origin="or:system">
	<name>Built-In Manufacturer Trust Anchor Certificates</name>	<name>Built-In Manufacturer Trust Anchor Certificates</name>
	<description>	<description>

	skipping to change at line 1547 ¶	skipping to change at line 1543 ¶
	Watsen, K., "RESTCONF Client and Server Models", Work in	Watsen, K., "RESTCONF Client and Server Models", Work in
	Progress, Internet-Draft, draft-ietf-netconf-restconf-	Progress, Internet-Draft, draft-ietf-netconf-restconf-
	client-server-38, 14 August 2024,	client-server-38, 14 August 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-	<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	restconf-client-server-38>.	restconf-client-server-38>.

	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,	DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.	<https://www.rfc-editor.org/info/rfc3688>.


	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.

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


		[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

End of changes. 8 change blocks.
	17 lines changed or deleted	14 lines changed or added
This html diff was produced by rfcdiff 1.48.