draft-ietf-netconf-sztp-csr-09.txt		draft-ietf-netconf-sztp-csr-10.txt
	NETCONF Working Group K. Watsen		NETCONF Working Group K. Watsen
	Internet-Draft Watsen Networks		Internet-Draft Watsen Networks
	Updates: 8572 (if approved) R. Housley		Updates: 8572 (if approved) R. Housley
	Intended status: Standards Track Vigil Security, LLC		Intended status: Standards Track Vigil Security, LLC
	Expires: 25 April 2022 S. Turner		Expires: 28 April 2022 S. Turner
	sn3rd		sn3rd
	22 October 2021		25 October 2021
	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
	draft-ietf-netconf-sztp-csr-09		draft-ietf-netconf-sztp-csr-10
	Abstract		Abstract
	This draft extends the "get-bootstrapping-data" RPC defined in RFC		This draft extends the "get-bootstrapping-data" RPC defined in RFC
	8572 to include an optional certificate signing request (CSR),		8572 to include an optional certificate signing request (CSR),
	enabling a bootstrapping device to additionally obtain an identity		enabling a bootstrapping device to additionally obtain an identity
	certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the		certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
	"onboarding information" response provided in the RPC-reply.		"onboarding information" response provided in the RPC-reply.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	progress. Please apply the following replacements:		progress. Please apply the following replacements:
	* XXXX --> the assigned numerical RFC value for this draft		* XXXX --> the assigned numerical RFC value for this draft
	* AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types		* AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types
	Artwork in this document contains a placeholder value for the		Artwork in this document contains a placeholder value for the
	publication date of this draft. Please apply the following		publication date of this draft. Please apply the following
	replacement:		replacement:
	* 2021-10-22 --> the publication date of this draft		* 2021-10-25 --> the publication date of this draft
	This document contains references to other drafts in progress, both		This document contains references to other drafts in progress, both
	in the Normative References section, as well as in body text		in the Normative References section, as well as in body text
	throughout. Please update the following references to reflect their		throughout. Please update the following references to reflect their
	final RFC assignments:		final RFC assignments:
	* I-D.ietf-netconf-crypto-types		* I-D.ietf-netconf-crypto-types
	* I-D.ietf-netconf-keystore		* I-D.ietf-netconf-keystore
	* I-D.ietf-netconf-trust-anchors		* I-D.ietf-netconf-trust-anchors
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 25 April 2022.		This Internet-Draft will expire on 28 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	[I-D.ietf-netconf-trust-anchors].		[I-D.ietf-netconf-trust-anchors].
	2.3. YANG Module		2.3. YANG Module
	This module augments an RPC defined in [RFC8572]. The module uses a		This module augments an RPC defined in [RFC8572]. The module uses a
	data types and groupings defined in [RFC8572], [RFC8791], and		data types and groupings defined in [RFC8572], [RFC8791], and
	[I-D.ietf-netconf-crypto-types]. The module has additional normative		[I-D.ietf-netconf-crypto-types]. The module has additional normative
	references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015],		references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015],
	and an informative reference to [Std-802.1AR-2018].		and an informative reference to [Std-802.1AR-2018].
	<CODE BEGINS> file "ietf-sztp-csr@2021-10-22.yang"		<CODE BEGINS> file "ietf-sztp-csr@2021-10-25.yang"
	module ietf-sztp-csr {		module ietf-sztp-csr {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";		namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr";
	prefix sztp-csr;		prefix sztp-csr;
	import ietf-sztp-bootstrap-server {		import ietf-sztp-bootstrap-server {
	prefix sztp-svr;		prefix sztp-svr;
	reference		reference
	"RFC 8572: Secure Zero Touch Provisioning (SZTP)";		"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
	itself for full legal notices.		itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
	'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',		'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
	'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this		'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
	document are to be interpreted as described in BCP 14		document are to be interpreted as described in BCP 14
	(RFC 2119) (RFC 8174) when, and only when, they appear		(RFC 2119) (RFC 8174) when, and only when, they appear
	in all capitals, as shown here.";		in all capitals, as shown here.";
	revision 2021-10-22 {		revision 2021-10-25 {
	description		description
	"Initial version";		"Initial version";
	reference		reference
	"RFC XXXX: Conveying a Certificate Signing Request (CSR)		"RFC XXXX: Conveying a Certificate Signing Request (CSR)
	in a Secure Zero Touch Provisioning (SZTP)		in a Secure Zero Touch Provisioning (SZTP)
	Bootstrapping Request";		Bootstrapping Request";
	}		}
	// Protocol-accessible nodes		// Protocol-accessible nodes
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 12 ¶
	+--:(cmp-csr)		+--:(cmp-csr)
	+-- cmp-csr? binary		+-- cmp-csr? binary
	3.2. YANG Module		3.2. YANG Module
	This module uses a data types and groupings [RFC8791] and		This module uses a data types and groupings [RFC8791] and
	[I-D.ietf-netconf-crypto-types]. The module has additional normative		[I-D.ietf-netconf-crypto-types]. The module has additional normative
	references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015],		references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015],
	and an informative reference to [Std-802.1AR-2018].		and an informative reference to [Std-802.1AR-2018].
	<CODE BEGINS> file "ietf-ztp-types@2021-10-22.yang"		<CODE BEGINS> file "ietf-ztp-types@2021-10-25.yang"
	module ietf-ztp-types {		module ietf-ztp-types {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";		namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types";
	prefix zt;		prefix zt;
	import ietf-crypto-types {		import ietf-crypto-types {
	prefix ct;		prefix ct;
	reference		reference
	"RFC AAAA: YANG Data Types and Groupings for Cryptography";		"RFC AAAA: YANG Data Types and Groupings for Cryptography";
	skipping to change at page 19, line 20 ¶		skipping to change at page 19, line 20 ¶
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
	itself for full legal notices.		itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
	'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',		'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
	'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this		'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
	document are to be interpreted as described in BCP 14		document are to be interpreted as described in BCP 14
	(RFC 2119) (RFC 8174) when, and only when, they appear		(RFC 2119) (RFC 8174) when, and only when, they appear
	in all capitals, as shown here.";		in all capitals, as shown here.";
	revision 2021-10-22 {		revision 2021-10-25 {
	description		description
	"Initial version";		"Initial version";
	reference		reference
	"RFC XXXX: Conveying a Certificate Signing Request (CSR)		"RFC XXXX: Conveying a Certificate Signing Request (CSR)
	in a Secure Zero Touch Provisioning (SZTP)		in a Secure Zero Touch Provisioning (SZTP)
	Bootstrapping Request";		Bootstrapping Request";
	}		}
	identity certificate-request-format {		identity certificate-request-format {
	description		description
	skipping to change at page 30, line 16 ¶		skipping to change at page 30, line 16 ¶
	Regardless if using a new asymmetric key or the bootstrapping		Regardless if using a new asymmetric key or the bootstrapping
	device's manufacturer-generated key (e.g., the IDevID key), the		device's manufacturer-generated key (e.g., the IDevID key), the
	public key is placed in the CSR and the CSR is signed by that private		public key is placed in the CSR and the CSR is signed by that private
	key. Proof-of-possession of the private key is verified by ensuring		key. Proof-of-possession of the private key is verified by ensuring
	the signature over the CSR using the public key placed in the CSR.		the signature over the CSR using the public key placed in the CSR.
	4.2.2. Verifying Proof of Origin		4.2.2. Verifying Proof of Origin
	When the bootstrapping device's manufacturer-generated private key		When the bootstrapping device's manufacturer-generated private key
	(e.g., the IDevID key) is reused for the CSR, proof-of-origin is		(e.g., the IDevID key) is reused for the CSR, proof-of-origin is
	verified by ensuring the CSR was signed by that key.		verified by validating the IDevID-issuer cert and ensuring that the
			CSR uses the same key pair.
	When a new asymmetric key is used, proof-or-origin is provided, in		When a new asymmetric key is used, proof-or-origin is provided, in
	the CMP and CMC formats, by the CSR's parent ASN.1 structure		the CMP and CMC formats, by the CSR's parent ASN.1 structure
	containing origin authentication using either the manufacturer-		containing origin authentication using either the manufacturer-
	generated private key or a shared secret.		generated private key or a shared secret.
	When a new asymmetric key is used, with the CMP or CMC formats, the		When a new asymmetric key is used, with the CMP or CMC formats, the
	parent ASN.1 structure of the CSR provides origin authentication		parent ASN.1 structure of the CSR provides origin authentication
	using either the manufacturer-generated private key or a shared		using either the manufacturer-generated private key or a shared
	secret. In this way the proof-of-possession of the CSR is directly		secret. In this way the proof-of-possession of the CSR is directly
End of changes. 10 change blocks.
	10 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/