Diff: rfc9646v4.txt - rfc9646.txt

	rfc9646v4.txt	rfc9646.txt

	Internet Engineering Task Force (IETF) K. Watsen	Internet Engineering Task Force (IETF) K. Watsen
	Request for Comments: 9646 Watsen Networks	Request for Comments: 9646 Watsen Networks
	Updates: 8572 R. Housley	Updates: 8572 R. Housley
	Category: Standards Track Vigil Security	Category: Standards Track Vigil Security
	ISSN: 2070-1721 S. Turner	ISSN: 2070-1721 S. Turner
	sn3rd	sn3rd

	September 2024	October 2024

	Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch	Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch
	Provisioning (SZTP) Bootstrapping Request	Provisioning (SZTP) Bootstrapping Request

	Abstract	Abstract

	This document extends the input to the "get-bootstrapping-data" RPC	This document extends the input to the "get-bootstrapping-data" RPC
	defined in RFC 8572 to include an optional certificate signing	defined in RFC 8572 to include an optional certificate signing
	request (CSR), enabling a bootstrapping device to additionally obtain	request (CSR), enabling a bootstrapping device to additionally obtain
	an identity certificate (e.g., a Local Device Identifier (LDevID)	an identity certificate (e.g., a Local Device Identifier (LDevID)

	skipping to change at line 145 ¶	skipping to change at line 145 ¶
	1.3. Requirements Language	1.3. Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	1.4. Conventions	1.4. Conventions


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

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

	2. The "ietf-sztp-csr" Module	2. The "ietf-sztp-csr" Module

	The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that	The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that
	augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572]	augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572]
	and defines a YANG "structure" that is to be conveyed in the "error-	and defines a YANG "structure" that is to be conveyed in the "error-
	info" node defined in Section 7.1 of [RFC8040].	info" node defined in Section 7.1 of [RFC8040].

	2.1. Data Model Overview	2.1. Data Model Overview


	skipping to change at line 200 ¶	skipping to change at line 203 ¶
	\| +-- format-identifier identityref	\| +-- format-identifier identityref
	+-- cert-req-info? ct:csr-info	+-- cert-req-info? ct:csr-info

	The augmentation defines two kinds of parameters that an SZTP-client	The augmentation defines two kinds of parameters that an SZTP-client
	can send to an SZTP-server. The YANG structure defines one	can send to an SZTP-server. The YANG structure defines one
	collection of parameters that an SZTP-server can send to an SZTP-	collection of parameters that an SZTP-server can send to an SZTP-
	client.	client.

	In the order of their intended use:	In the order of their intended use:


	1. The SZTP-client sends a "csr-support” node, encoded in a first	1. The SZTP-client sends a "csr-support" node, encoded in a first
	“get-bootstrapping-data” request to the SZTP-server, to indicate	"get-bootstrapping-data" request to the SZTP-server, to indicate
	that it supports the ability to generate CSRs. This input	that it supports the ability to generate CSRs. This input
	parameter conveys if the SZTP-client is able to generate a new	parameter conveys if the SZTP-client is able to generate a new
	asymmetric key and, if so, which key algorithms it supports, as	asymmetric key and, if so, which key algorithms it supports, as
	well as what kinds of CSR structures the SZTP-client is able to	well as what kinds of CSR structures the SZTP-client is able to
	generate.	generate.

	2. The SZTP-server responds with an error, containing the "csr-	2. The SZTP-server responds with an error, containing the "csr-

	request” structure, to request the SZTP-client to generate a CSR.	request" structure, to request the SZTP-client to generate a CSR.
	This structure is used to select the key algorithm the SZTP-	This structure is used to select the key algorithm the SZTP-
	client should use to generate a new asymmetric key (if	client should use to generate a new asymmetric key (if
	supported), the kind of CSR structure the SZTP-client should	supported), the kind of CSR structure the SZTP-client should
	generate, and optionally the content for the CSR itself.	generate, and optionally the content for the CSR itself.


	3. The SZTP-client sends one of the "*-csr” nodes, encoded in a	3. The SZTP-client sends one of the "*-csr" nodes, encoded in a
	second “get-bootstrapping-data” request to the SZTP-server. This	second "get-bootstrapping-data" request to the SZTP-server. This
	node encodes the server-requested CSR.	node encodes the server-requested CSR.

	4. The SZTP-server responds with onboarding information to	4. The SZTP-server responds with onboarding information to
	communicate the signed certificate to the SZTP-client. How to do	communicate the signed certificate to the SZTP-client. How to do
	this is discussed in Section 2.2.	this is discussed in Section 2.2.

	To further illustrate how the augmentation and structure defined by	To further illustrate how the augmentation and structure defined by
	the "ietf-sztp-csr" module are used, below are two additional tree	the "ietf-sztp-csr" module are used, below are two additional tree
	diagrams showing these nodes placed where they are used.	diagrams showing these nodes placed where they are used.


	skipping to change at line 1208 ¶	skipping to change at line 1211 ¶
	It is RECOMMENDED that devices are manufactured with a hardware	It is RECOMMENDED that devices are manufactured with a hardware
	security module (HSM), such as a trusted platform module (TPM), to	security module (HSM), such as a trusted platform module (TPM), to
	generate and contain the private key within the security perimeter of	generate and contain the private key within the security perimeter of
	the HSM. In such cases, the private key and its associated	the HSM. In such cases, the private key and its associated
	certificates MAY have long validity periods.	certificates MAY have long validity periods.

	In cases where the SZTP-client does not possess an HSM or is unable	In cases where the SZTP-client does not possess an HSM or is unable
	to use an HSM to protect the private key, it is RECOMMENDED to	to use an HSM to protect the private key, it is RECOMMENDED to
	periodically reset the private key (and associated identity	periodically reset the private key (and associated identity
	certificates) in order to minimize the lifetime of unprotected	certificates) in order to minimize the lifetime of unprotected

	private keys. For instance, an Network Management System (NMS)	private keys. For instance, a Network Management System (NMS)
	controller/orchestrator application could periodically prompt the	controller/orchestrator application could periodically prompt the
	SZTP-client to generate a new private key and provide a certificate	SZTP-client to generate a new private key and provide a certificate
	signing request (CSR) or, alternatively, push both the key and an	signing request (CSR) or, alternatively, push both the key and an
	identity certificate to the SZTP-client using, e.g., a PKCS#12	identity certificate to the SZTP-client using, e.g., a PKCS#12
	message [RFC7292]. In another example, the SZTP-client could be	message [RFC7292]. In another example, the SZTP-client could be
	configured to periodically reset the configuration to its factory	configured to periodically reset the configuration to its factory
	default, thus causing removal of the private key and associated	default, thus causing removal of the private key and associated
	identity certificates and re-execution of the SZTP protocol.	identity certificates and re-execution of the SZTP protocol.

	4.1.2. Reuse of a Manufacturer-Generated Private Key	4.1.2. Reuse of a Manufacturer-Generated Private Key

	skipping to change at line 1495 ¶	skipping to change at line 1498 ¶
	[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data	[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
	Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,	Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
	June 2020, <https://www.rfc-editor.org/info/rfc8791>.	June 2020, <https://www.rfc-editor.org/info/rfc8791>.

	[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,	[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,	Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,	DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.	<https://www.rfc-editor.org/info/rfc9110>.

	[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, September	Cryptography", RFC 9640, DOI 10.17487/RFC9640, October
	2024, <https://www.rfc-editor.org/info/rfc9640>.	2024, <https://www.rfc-editor.org/info/rfc9640>.

	6.2. Informative References	6.2. Informative References

	[AIS31] Killmann, W. and W. Schindler, "A proposal for:	[AIS31] Killmann, W. and W. Schindler, "A proposal for:
	Functionality classes for random number generators -	Functionality classes for random number generators -
	Version 2.0", September 2011,	Version 2.0", September 2011,
	<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/	<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
	Zertifizierung/Interpretationen/AIS_31_Functionality_class	Zertifizierung/Interpretationen/AIS_31_Functionality_class
	es_for_random_number_generators_e.pdf>.	es_for_random_number_generators_e.pdf>.

	skipping to change at line 1555 ¶	skipping to change at line 1558 ¶

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

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

	[RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for	[RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
	Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808,	Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808,
	August 2020, <https://www.rfc-editor.org/info/rfc8808>.	August 2020, <https://www.rfc-editor.org/info/rfc8808>.

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

	[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", August 2018,	Networks - Secure Device Identity", August 2018,
	<https://standards.ieee.org/ieee/802.1AR/6995/>.	<https://standards.ieee.org/ieee/802.1AR/6995/>.

	Acknowledgements	Acknowledgements

	The authors would like to thank for following for lively discussions	The authors would like to thank for following for lively discussions

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