Diff: draft-ietf-netconf-sztp-csr-04.txt - draft-ietf-netconf-sztp-csr-05.txt

	< draft-ietf-netconf-sztp-csr-04.txt	draft-ietf-netconf-sztp-csr-05.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: 31 December 2021 S. Turner	Expires: 8 January 2022 S. Turner
	sn3rd	sn3rd

	29 June 2021	7 July 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-04	draft-ietf-netconf-sztp-csr-05

	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-06-29" --> the publication date of this draft	* "2021-07-07" --> 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 31 December 2021.	This Internet-Draft will expire on 8 January 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 3, line 37 ¶	skipping to change at page 3, line 37 ¶
	1. Introduction	1. Introduction

	1.1. Overview	1.1. Overview

	This draft extends the "get-bootstrapping-data" RPC defined in	This draft extends the "get-bootstrapping-data" RPC defined in
	[RFC8572] to include an optional certificate signing request (CSR)	[RFC8572] to include an optional certificate signing request (CSR)
	[RFC2986], enabling a bootstrapping device to additionally obtain an	[RFC2986], enabling a bootstrapping device to additionally obtain an
	identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of	identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of
	the "onboarding information" response provided in the RPC-reply.	the "onboarding information" response provided in the RPC-reply.


		The ability to provision an identity certificate that is purpose-
		built for a production environment during the bootstrapping process
		removes reliance on the manufacturer CA, and it also enables the
		bootstraped device to join the production environment with an
		appropriate identity and other attributes in its LDevID certificate.

	1.2. Terminology	1.2. Terminology

	This document uses the following terms from [RFC8572]:	This document uses the following terms from [RFC8572]:

	* Bootstrap Server	* Bootstrap Server
	* Bootstrapping Data	* Bootstrapping Data
	* Conveyed Information	* Conveyed Information
	* Device	* Device
	* Manufacturer	* Manufacturer
	* Onboarding Information	* Onboarding Information

	skipping to change at page 8, line 41 ¶	skipping to change at page 8, line 41 ¶
	"ietf-sztp-csr:cmc",	"ietf-sztp-csr:cmc",
	"ietf-sztp-csr:cmp"	"ietf-sztp-csr:cmp"
	]	]
	}	}
	}	}
	}	}
	}	}
	}	}

	Assuming the SZTP-server wishes to prompt the SZTP-client to provide	Assuming the SZTP-server wishes to prompt the SZTP-client to provide

	a CSR, then it would respond with an HTTP 300 Multiple Choices error	a CSR, then it would respond with an HTTP 400 Bad Request error code:
	code:

	RESPONSE	RESPONSE

	HTTP/1.1 300 Multiple Choices	HTTP/1.1 400 Bad Request
	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-restconf:errors" : {	"ietf-restconf:errors" : {
	"error" : [	"error" : [
	{	{
	"error-type": "application",	"error-type": "application",
	"error-tag": "missing-attribute",	"error-tag": "missing-attribute",

	skipping to change at page 13, line 12 ¶	skipping to change at page 13, line 12 ¶
	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 normative references	defined in [I-D.ietf-netconf-crypto-types], has normative references
	to [RFC2986] and [ITU.X690.2015], and an informative reference to	to [RFC2986] and [ITU.X690.2015], and an informative reference to
	[Std-802.1AR-2018].	[Std-802.1AR-2018].


	<CODE BEGINS> file "ietf-sztp-csr@2021-06-29.yang"	<CODE BEGINS> file "ietf-sztp-csr@2021-07-07.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 14, line 27 ¶	skipping to change at page 14, line 27 ¶
	(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-06-29 {	revision 2021-07-07 {
	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 16, line 20 ¶	skipping to change at page 16, line 20 ¶
	presence	presence
	"Indicates that the SZTP-client is capable of sending	"Indicates that the SZTP-client is capable of sending
	CSRs.";	CSRs.";
	description	description
	"The 'csr-support' node enables the SZTP-client to	"The 'csr-support' node enables the SZTP-client to
	indicate that it supports generating certificate	indicate that it supports generating certificate
	signing requests (CSRs), and provide details around	signing requests (CSRs), and provide details around
	the CSRs it is able to generate.	the CSRs it is able to generate.

	When present, the SZTP-server MAY respond with the HTTP	When present, the SZTP-server MAY respond with the HTTP

	code 300 Multiple Choices with an 'ietf-restconf:errors'	code 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
	generating a new asymmetric key pair.	generating a new asymmetric key pair.

	If this node is not present, the SZTP-server MAY	If this node is not present, the SZTP-server MAY
	request a CSR using the asymmetric key associated	request a CSR using the asymmetric key associated

	skipping to change at page 22, line 34 ¶	skipping to change at page 22, line 34 ¶
	RFC AAAA.	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 a 300 Multiple Choices response containing	result in a 400 Bad Request response containing
	another 'request-info' structure.	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.";

End of changes. 12 change blocks.
	12 lines changed or deleted	17 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/