Diff: draft-ietf-netconf-sztp-csr-02.txt - draft-ietf-netconf-sztp-csr-03.txt

	< draft-ietf-netconf-sztp-csr-02.txt	draft-ietf-netconf-sztp-csr-03.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: 20 November 2021 S. Turner	Expires: 17 December 2021 S. Turner
	sn3rd	sn3rd

	19 May 2021	15 June 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-02	draft-ietf-netconf-sztp-csr-03

	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 42 ¶	skipping to change at page 1, line 42 ¶

	* "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-	* "AAAA" --> the assigned RFC value for I-D.ietf-netconf-crypto-
	types	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-05-19" --> the publication date of this draft	* "2021-06-15" --> 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 20 November 2021.	This Internet-Draft will expire on 17 December 2021.

	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 5, line 5 ¶	skipping to change at page 5, line 5 ¶
	* The "request-info" structure is used by the SZTP-server to signal	* The "request-info" structure is used by the SZTP-server to signal
	back to the SZTP-client its desire to sign a CSR. The "request-	back to the SZTP-client its desire to sign a CSR. The "request-
	info" structure additionally communicates details about the CSR	info" structure additionally communicates details about the CSR
	the SZTP-client is to generate.	the SZTP-client is to generate.

	* The "csr" node is used by the SZTP-client to communicate its CSR	* The "csr" node is used by the SZTP-client to communicate its CSR
	to the SZTP-server. Not shown is how the SZTP-server communicates	to the SZTP-server. Not shown is how the SZTP-server communicates
	the signed certificate to the SZTP-client; how to do this is	the signed certificate to the SZTP-client; how to do this is
	discussed later in this document.	discussed later in this document.


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

	module: ietf-sztp-csr	module: ietf-sztp-csr


	augment /ietf-sztp-bootstrap-server:get-bootstrapping-data/ietf-sz\	augment /sztp-svr:get-bootstrapping-data/sztp-svr:input:
	tp-bootstrap-server:input:	+---w csr-support!
	+---- csr-support!	\| +---w key-generation!
	\| +---- key-generation!	\| \| +---w supported-algorithms
	\| \| +---- supported-algorithms	\| \| +---w algorithm-identifier* binary
	\| \| +---- algorithm-identifier* binary	\| +---w csr-generation
	\| +---- csr-generation	\| +---w supported-formats
	\| +---- supported-formats	\| +---w format-identifier* identityref
	\| +---- format-identifier* identityref	+---w csr!
	+---- csr!	+---w (request-type)
	+---- (request-type)
	+--:(p10)	+--:(p10)

	\| +---- p10? ietf-crypto-types:csr	\| +---w p10? ct:csr
	+--:(cmc)	+--:(cmc)

	\| +---- cmc? binary	\| +---w cmc? binary
	+--:(cmp)	+--:(cmp)

	+---- cmp? binary	+---w cmp? binary

	structure: request-info	structure: request-info

	+-- key-generation!	+--ro key-generation!
	\| +-- selected-algorithm	\| +--ro selected-algorithm
	\| +-- algorithm-identifier binary	\| +--ro algorithm-identifier binary
	+-- csr-generation	+--ro csr-generation
	\| +-- selected-format	\| +--ro selected-format
	\| +-- format-identifier identityref	\| +--ro format-identifier identityref
	+-- cert-req-info? ietf-crypto-types:csr-info	+--ro cert-req-info? ietf-crypto-types:csr-info

	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.

	The following tree diagram [RFC8340] illustrates SZTP's "get-	The following tree diagram [RFC8340] illustrates SZTP's "get-
	bootstrapping-data" RPC with the augmentation in place.	bootstrapping-data" RPC with the augmentation in place.

	module: ietf-sztp-bootstrap-server	module: ietf-sztp-bootstrap-server


	skipping to change at page 10, line 23 ¶	skipping to change at page 10, line 23 ¶
	"hw-model": "model-x",	"hw-model": "model-x",
	"os-name": "vendor-os",	"os-name": "vendor-os",
	"os-version": "17.3R2.1",	"os-version": "17.3R2.1",
	"nonce": "extralongbase64encodedvalue=",	"nonce": "extralongbase64encodedvalue=",
	"ietf-sztp-csr:csr": {	"ietf-sztp-csr:csr": {
	"p10": "base64encodedvalue=="	"p10": "base64encodedvalue=="
	}	}
	}	}
	}	}


	The SZTP-server responds with "onboarding-information" (conveyed	The SZTP-server responds with "onboarding-information" (encoded
	encoded inside the "conveyed-information" node) containing a signed	inside the "conveyed-information" node) containing a signed identity
	identity certificate for the CSR provided by the SZTP-client:	certificate for the CSR provided by the SZTP-client:

	RESPONSE	RESPONSE

	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Date: Sat, 31 Oct 2015 17:02:40 GMT	Date: Sat, 31 Oct 2015 17:02:40 GMT
	Server: example-server	Server: example-server
	Content-Type: application/yang.data+json	Content-Type: application/yang.data+json

	{	{
	"ietf-sztp-bootstrap-server:output" : {	"ietf-sztp-bootstrap-server:output" : {
	"reporting-level": "verbose",	"reporting-level": "verbose",
	"conveyed-information": "base64encodedvalue=="	"conveyed-information": "base64encodedvalue=="
	}	}
	}	}

	How the signed certificate is conveyed inside the onboarding	How the signed certificate is conveyed inside the onboarding
	information is outside the scope of this document. Some	information is outside the scope of this document. Some
	implementations may choose to convey it inside a script (e.g., SZTP's	implementations may choose to convey it inside a script (e.g., SZTP's

	"pre-configuration-script"), while other implementations convey it	"pre-configuration-script"), while other implementations may choose
	inside the SZTP "configuration" node.	to convey it inside the SZTP "configuration" node. SZTP onboarding
		information is described in Section 2.2 of [RFC8572].

	Following are two examples of conveying the signed certificate inside	Following are two examples of conveying the signed certificate inside
	the "configuration" node. Both examples assume that the SZTP-client	the "configuration" node. Both examples assume that the SZTP-client
	understands the "ietf-keystore" module defined in	understands the "ietf-keystore" module defined in
	[I-D.ietf-netconf-keystore].	[I-D.ietf-netconf-keystore].

	This first example illustrates the case where the signed certificate	This first example illustrates the case where the signed certificate
	is for the same asymmetric key used by the SZTP-client's	is for the same asymmetric key used by the SZTP-client's
	manufacturer-generated identity certificate (e.g., an IDevID, from	manufacturer-generated identity certificate (e.g., an IDevID, from
	[Std-802.1AR-2018]). As such, the configuration needs to associate	[Std-802.1AR-2018]). As such, the configuration needs to associate

	skipping to change at page 12, line 48 ¶	skipping to change at page 12, line 48 ¶
	]	]
	}	}
	}	}
	]	]
	}	}
	}	}
	}	}

	In addition to configuring the signed certificate, it is often	In addition to configuring the signed certificate, it is often
	necessary to also configure the Issuer's signing certificate so that	necessary to also configure the Issuer's signing certificate so that

	the the device (i.e., STZP-client) can authenticate certificates	the device (i.e., STZP-client) can authenticate certificates
	presented by peer devices signed by the same issuer as its own.	presented by peer devices signed by the same issuer as its own.
	While outside the scope of this document, one way to do this would be	While outside the scope of this document, one way to do this would be
	to use the "ietf-truststore" module defined in	to use the "ietf-truststore" module defined in
	[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], uses a data type	This module augments an RPC defined in [RFC8572], uses a data type
	defined in [I-D.ietf-netconf-crypto-types], has an normative	defined in [I-D.ietf-netconf-crypto-types], has an normative
	references to [RFC2986] and [ITU.X690.2015], and an informative	references to [RFC2986] and [ITU.X690.2015], and an informative
	reference to [Std-802.1AR-2018].	reference to [Std-802.1AR-2018].


	<CODE BEGINS> file "ietf-sztp-csr@2021-05-19.yang"	<CODE BEGINS> file "ietf-sztp-csr@2021-06-15.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 "RFC 8572: Secure Zero Touch Provisioning (SZTP)";	reference
		"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
	}	}

	import ietf-yang-structure-ext {	import ietf-yang-structure-ext {
	prefix sx;	prefix sx;

	reference "RFC BBBB:YANG Data Structure Extensions";	reference
		"RFC 8791: YANG Data Structure Extensions";
	}	}

	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";
	}	}

	organization	organization
	"IETF NETCONF (Network Configuration) Working Group";	"IETF NETCONF (Network Configuration) Working Group";

	contact	contact
	"WG Web: http://tools.ietf.org/wg/netconf	"WG Web: http://tools.ietf.org/wg/netconf
	WG List: <mailto:netconf@ietf.org>	WG List: <mailto:netconf@ietf.org>
	Authors: Kent Watsen <mailto:kent+ietf@watsen.net>	Authors: Kent Watsen <mailto:kent+ietf@watsen.net>
	Russ Housley <mailto:housley@vigilsec.com>	Russ Housley <mailto:housley@vigilsec.com>
	Sean Turner <mailto:sean@sn3rd.com>";	Sean Turner <mailto:sean@sn3rd.com>";

	description	description

	"This module augments the 'get-bootstrapping-data' RPC,	"This module augments the 'get-bootstrapping-data' RPC,
	defined in the 'ietf-sztp-bootstrap-server' module from	defined in the 'ietf-sztp-bootstrap-server' module from
	SZTP (RFC 8572), enabling the SZTP-client to obtain a	SZTP (RFC 8572), enabling the SZTP-client to obtain a
	signed identity certificate (e.g., an LDevID from IEEE	signed identity certificate (e.g., an LDevID from IEEE
	802.1AR) as part of the SZTP 'onboarding-information'	802.1AR) as part of the SZTP onboarding information
	response.	response.


	Copyright (c) 2020 IETF Trust and the persons identified	Copyright (c) 2020 IETF Trust and the persons identified
	as authors of the code. All rights reserved.	as authors of the code. All rights reserved.


	Redistribution and use in source and binary forms, with	Redistribution and use in source and binary forms, with
	or without modification, is permitted pursuant to, and	or without modification, is permitted pursuant to, and
	subject to the license terms contained in, the Simplified	subject to the license terms contained in, the Simplified
	BSD License set forth in Section 4.c of the IETF Trust's	BSD License set forth in Section 4.c of the IETF Trust's
	Legal Provisions Relating to IETF Documents	Legal Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info).	(https://trustee.ietf.org/license-info).


	This version of this YANG module is part of RFC XXXX	This version of this YANG module is part of RFC XXXX
	(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-05-19 {	revision 2021-06-15 {
	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
	"A base identity for the request formats supported	"A base identity for the request formats supported
	by the SZTP-client.	by the SZTP-client.

	Additional derived identities MAY be defined by	Additional derived identities MAY be defined by
	future efforts.";	future efforts.";
	}	}

	identity p10 {	identity p10 {

	base "certificate-request-format";	base certificate-request-format;
	description	description
	"Indicates that the SZTP-client supports generating	"Indicates that the SZTP-client supports generating
	requests using the 'CertificationRequest' structure	requests using the 'CertificationRequest' structure
	defined in RFC 2986.";	defined in RFC 2986.";
	reference	reference
	"RFC 2986: PKCS #10: Certification Request Syntax	"RFC 2986: PKCS #10: Certification Request Syntax
	Specification Version 1.7";	Specification Version 1.7";


	}	}

	identity cmc {	identity cmc {

	base "certificate-request-format";	base certificate-request-format;
	description	description
	"Indicates that the SZTP-client supports generating	"Indicates that the SZTP-client supports generating
	requests using a constrained version of the 'Full	requests using a constrained version of the 'Full
	PKI Request' structure defined in RFC 5272.";	PKI Request' structure defined in RFC 5272.";
	reference	reference
	"RFC 5272: Certificate Management over CMS (CMC)";	"RFC 5272: Certificate Management over CMS (CMC)";
	}	}

	identity cmp {	identity cmp {

	base "certificate-request-format";	base certificate-request-format;
	description	description
	"Indicates that the SZTP-client supports generating	"Indicates that the SZTP-client supports generating
	requests that contain a PKCS#10 Certificate Signing	requests that contain a PKCS#10 Certificate Signing
	Request (p10cr), as defined in RFC 2986, encapsulated	Request (p10cr), as defined in RFC 2986, encapsulated
	in a Nested Message Content (nested), as defined in	in a Nested Message Content (nested), as defined in
	RFC 4210.";	RFC 4210.";
	reference	reference
	"RFC 2986: PKCS #10: Certification Request Syntax	"RFC 2986: PKCS #10: Certification Request Syntax
	Specification Version 1.7	Specification Version 1.7
	RFC 4210: Internet X.509 Public Key Infrastructure	RFC 4210: Internet X.509 Public Key Infrastructure

	skipping to change at page 15, line 35 ¶	skipping to change at page 15, line 36 ¶
	reference	reference
	"RFC 2986: PKCS #10: Certification Request Syntax	"RFC 2986: PKCS #10: Certification Request Syntax
	Specification Version 1.7	Specification Version 1.7
	RFC 4210: Internet X.509 Public Key Infrastructure	RFC 4210: Internet X.509 Public Key Infrastructure
	Certificate Management Protocol (CMP)";	Certificate Management Protocol (CMP)";
	}	}

	// Protocol-accessible nodes	// Protocol-accessible nodes

	augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" {	augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" {


	description	description
	"This augmentation adds the 'csr-support' and 'csr' nodes to	"This augmentation adds the 'csr-support' and 'csr' nodes to
	the SZTP (RFC 8572) 'get-bootstrapping-data' request message,	the SZTP (RFC 8572) 'get-bootstrapping-data' request message,
	enabling the SZTP-client to obtain an identity certificate	enabling the SZTP-client to obtain an identity certificate
	(e.g., an LDevID from IEEE 802.1AR) as part of the onboarding	(e.g., an LDevID from IEEE 802.1AR) as part of the onboarding
	information response provided by the SZTP-server.	information response provided by the SZTP-server.

	The 'csr-support' node enables the SZTP-client to indicate	The 'csr-support' node enables the SZTP-client to indicate
	that it supports generating certificate signing requests	that it supports generating certificate signing requests
	(CSRs), and to provide details around the CSRs it is able	(CSRs), and to provide details around the CSRs it is able
	to generate.	to generate.

	The 'csr' node enables the SZTP-client to relay a CSR to	The 'csr' node enables the SZTP-client to relay a CSR to
	the SZTP-server.";	the SZTP-server.";

		reference
	reference	"IEEE 802.1AR: IEEE Standard for Local and metropolitan
	"IEEE 802.1AR: IEEE Standard for Local and metropolitan	area networks - Secure Device Identity
	area networks - Secure Device Identity	RFC 8572: Secure Zero Touch Provisioning (SZTP)";
	RFC 8572: Secure Zero Touch Provisioning (SZTP)";

	container csr-support {	container csr-support {
	presence	presence
	"Indicates that the SZTP-client is capable of sending CSRs.";	"Indicates that the SZTP-client is capable of sending CSRs.";
	description	description
	"The 'csr-support' node enables the SZTP-client to indicate	"The 'csr-support' node enables the SZTP-client to indicate
	that it supports generating certificate signing requests	that it supports generating certificate signing requests

	(CSRs), and to provide details around the CSRs it is able	(CSRs), and provide details around the CSRs it is able
	to generate.	to generate.

	When present, the SZTP-server MAY respond with the HTTP	When present, the SZTP-server MAY respond with the HTTP
	error 400 (Bad Request) with an 'ietf-restconf:errors'	error 400 (Bad Request) with an 'ietf-restconf:errors'
	document having the 'error-tag' value 'missing-attribute'	document having the 'error-tag' value 'missing-attribute'
	and the 'error-info' node containing the 'request-info'	and the 'error-info' node containing the 'request-info'
	structure described in this module.";	structure described in this module.";
	container key-generation {	container key-generation {
	presence	presence
	"Indicates that the SZTP-client is capable of	"Indicates that the SZTP-client is capable of

	skipping to change at page 17, line 28 ¶	skipping to change at page 17, line 27 ¶
	base certificate-request-format;	base certificate-request-format;
	}	}
	min-elements 1;	min-elements 1;
	description	description
	"A certificate request format supported by the	"A certificate request format supported by the
	SZTP-client.";	SZTP-client.";
	}	}
	}	}
	}	}
	}	}


	container csr {	container csr {

	presence	presence "Indicates that the SZTP-client has sent a CSR.";
	"Indicates that the SZTP-client has sent a CSR.";
	description	description
	"The 'csr' node enables the SZTP-client to convey	"The 'csr' node enables the SZTP-client to convey
	a certificate signing request, using the encoding	a certificate signing request, using the encoding
	format selected by the SZT-server's 'request-info'	format selected by the SZT-server's 'request-info'
	response to the SZTP-client's previously sent	response to the SZTP-client's previously sent
	'get-bootstrapping-data' request containing the	'get-bootstrapping-data' request containing the
	'csr-support' node.	'csr-support' node.

	When present, the SZTP-server SHOULD respond with	When present, the SZTP-server SHOULD respond with

	an SZTP 'onboarding-information' message containing	an SZTP onboarding information message containing
	a signed certificate for the conveyed CSR. The	a signed certificate for the conveyed CSR. The
	SZTP-server MAY alternatively respond with another	SZTP-server MAY alternatively respond with another
	HTTP error containing another 'request-info', in	HTTP error containing another 'request-info', in
	which case the SZTP-client MUST invalidate the CSR	which case the SZTP-client MUST invalidate the CSR
	sent in this node.";	sent in this node.";
	choice request-type {	choice request-type {
	mandatory true;	mandatory true;
	description	description
	"A choice amongst certificate signing request formats.	"A choice amongst certificate signing request formats.


	skipping to change at page 21, line 4 ¶	skipping to change at page 20, line 49 ¶
	ITU-T X.690:	ITU-T X.690:
	Information technology - ASN.1 encoding rules:	Information technology - ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER),	Specification of Basic Encoding Rules (BER),
	Canonical Encoding Rules (CER) and Distinguished	Canonical Encoding Rules (CER) and Distinguished
	Encoding Rules (DER).";	Encoding Rules (DER).";
	}	}
	}	}
	}	}
	}	}
	}	}


	sx:structure request-info {	sx:structure request-info {
	container key-generation {	container key-generation {
	presence	presence
	"Indicates that the SZTP-client is to generate a new	"Indicates that the SZTP-client is to generate a new
	asymmetric key. If missing, then the SZTP-client	asymmetric key. If missing, then the SZTP-client
	MUST reuse the key associated with its existing	MUST reuse the key associated with its existing
	identity certificate (e.g., IDevID).	identity certificate (e.g., IDevID).

	This leaf MUST only appear if the SZTP-clients	This leaf MUST only appear if the SZTP-clients
	'csr-support' included the 'key-generation' node.";	'csr-support' included the 'key-generation' node.";
	description	description

	"Specifies details for the key that the SZTP-client	"A YANG data structure, per RFC 8791, that specifies
	is to generate.";	details for the key that the SZTP-client is to
		generate.";
		reference
		"RFC 8791: YANG Data Structure Extensions";
	container selected-algorithm {	container selected-algorithm {
	description	description
	"The key algorithm selected by the SZTP-server. The	"The key algorithm selected by the SZTP-server. The
	algorithm MUST be one of the algorithms specified	algorithm MUST be one of the algorithms specified
	by the 'supported-algorithms' node in the	by the 'supported-algorithms' node in the
	SZTP-client's request message.";	SZTP-client's request message.";
	leaf algorithm-identifier {	leaf algorithm-identifier {
	type binary;	type binary;
	mandatory true;	mandatory true;
	description	description

	skipping to change at page 21, line 51 ¶	skipping to change at page 22, line 4 ¶
	container csr-generation {	container csr-generation {
	description	description
	"Specifies details for the CSR that the SZTP-client	"Specifies details for the CSR that the SZTP-client
	is to generate.";	is to generate.";
	container selected-format {	container selected-format {
	description	description
	"The CSR format selected by the SZTP-server. The	"The CSR format selected by the SZTP-server. The
	format MUST be one of the formats specified by	format MUST be one of the formats specified by
	the 'supported-formats' node in the SZTP-client's	the 'supported-formats' node in the SZTP-client's
	request message.";	request message.";


	leaf format-identifier {	leaf format-identifier {
	type identityref {	type identityref {
	base certificate-request-format;	base certificate-request-format;
	}	}
	mandatory true;	mandatory true;
	description	description
	"A certificate request format to be used by the	"A certificate request format to be used by the
	SZTP-client.";	SZTP-client.";
	}	}
	}	}
	}	}
	leaf cert-req-info {	leaf cert-req-info {
	type ct:csr-info;	type ct:csr-info;
	description	description
	"A CertificationRequestInfo structure, as defined in	"A CertificationRequestInfo structure, as defined in

	RFC 2986.	RFC 2986, and modeled via a 'typedef' statement by
		RFC AAAA.

	Enables the SZTP-server to provide a fully-populated	Enables the SZTP-server to provide a fully-populated
	CertificationRequestInfo structure that the SZTP-client	CertificationRequestInfo structure that the SZTP-client
	only needs to sign in order to generate the complete	only needs to sign in order to generate the complete
	'CertificationRequest' structure to send to SZTP-server	'CertificationRequest' structure to send to SZTP-server
	in its next 'get-bootstrapping-data' request message.	in its next 'get-bootstrapping-data' request message.

	When provided, the SZTP-client SHOULD use this	When provided, the SZTP-client SHOULD use this
	structure to generate its CSR; failure to do so MAY	structure to generate its CSR; failure to do so MAY

	result in another 400 (Bad Request) response.	result in a 400 (Bad Request) response containing
		another 'request-info' structure.

	When not provided, the SZTP-client SHOULD generate a	When not provided, the SZTP-client SHOULD generate a
	CSR using the same structure defined in its existing	CSR using the same structure defined in its existing
	identity certificate (e.g., IDevID).	identity certificate (e.g., IDevID).

	It is an error if the 'AlgorithmIdentifier' field	It is an error if the 'AlgorithmIdentifier' field
	contained inside the 'SubjectPublicKeyInfo' field	contained inside the 'SubjectPublicKeyInfo' field
	does not match the algorithm identified by the	does not match the algorithm identified by the
	'selected-algorithm' node.";	'selected-algorithm' node.";
	reference	reference

	skipping to change at page 23, line 44 ¶	skipping to change at page 23, line 44 ¶

	3.1.2. Reuse of a Manufacturer-generated Private Key	3.1.2. Reuse of a Manufacturer-generated Private Key

	It is RECOMMENDED that a new private key is generated for each CSR	It is RECOMMENDED that a new private key is generated for each CSR
	described in this document.	described in this document.

	This private key SHOULD be protected as well as the built-in private	This private key SHOULD be protected as well as the built-in private
	key associated with the device's initial secure device identity	key associated with the device's initial secure device identity
	certificate (e.g., the IDevID, from [Std-802.1AR-2018]).	certificate (e.g., the IDevID, from [Std-802.1AR-2018]).


	In cases where it it not possible to generate a new private key that	In cases where it is not possible to generate a new private key that
	is protected as well as the built-in private key, it is RECOMMENDED	is protected as well as the built-in private key, it is RECOMMENDED

	to reuse the built-in private key rather then generate a new private	to reuse the built-in private key rather than generate a new private
	key that is not as well protected.	key that is not as well protected.

	3.1.3. Replay Attack Protection	3.1.3. Replay Attack Protection

	This RFC enables an SZTP-client to announce an ability to generate	This RFC enables an SZTP-client to announce an ability to generate
	new key to use for its CSR.	new key to use for its CSR.

	When the SZTP-server responds with a request for the device to	When the SZTP-server responds with a request for the device to
	generate a new key, it is essential that the device actually	generate a new key, it is essential that the device actually
	generates a new key.	generates a new key.

End of changes. 40 change blocks.
	83 lines changed or deleted	84 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/