draft-ietf-lamps-lightweight-cmp-profile-09.txt		draft-ietf-lamps-lightweight-cmp-profile-10.txt
	LAMPS Working Group H. Brockhaus, Ed.		LAMPS Working Group H. Brockhaus, Ed.
	Internet-Draft D. von Oheimb		Internet-Draft D. von Oheimb
	Intended status: Standards Track S. Fries		Intended status: Standards Track S. Fries
	Expires: 20 June 2022 Siemens		Expires: 5 August 2022 Siemens
	17 December 2021		1 February 2022
	Lightweight Certificate Management Protocol (CMP) Profile		Lightweight Certificate Management Protocol (CMP) Profile
	draft-ietf-lamps-lightweight-cmp-profile-09		draft-ietf-lamps-lightweight-cmp-profile-10
	Abstract		Abstract
	This document aims at simple, interoperable, and automated PKI		This document aims at simple, interoperable, and automated PKI
	management operations covering typical use cases of industrial and		management operations covering typical use cases of industrial and
	IoT scenarios. This is achieved by profiling the Certificate		IoT scenarios. This is achieved by profiling the Certificate
	Management Protocol (CMP), the related Certificate Request Message		Management Protocol (CMP), the related Certificate Request Message
	Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct		Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
	but sufficiently detailed and self-contained way. To make secure		but sufficiently detailed and self-contained way. To make secure
	certificate management for simple scenarios and constrained devices		certificate management for simple scenarios and constrained devices
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 June 2022.		This Internet-Draft will expire on 5 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. How to Read This Document . . . . . . . . . . . . . . . . 4		1.1. How to Read This Document . . . . . . . . . . . . . . . . 4
	1.2. Motivation for a lightweight profile of CMP . . . . . . . 5		1.2. Motivation for a lightweight profile of CMP . . . . . . . 5
	1.3. Special requirements of industrial and IoT scenarios . . 6		1.3. Special requirements of industrial and IoT scenarios . . 6
	1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7		1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7
	1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7		1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7
	1.6. Compatibility with existing CMP profiles . . . . . . . . 8		1.6. Compatibility with existing CMP profiles . . . . . . . . 8
	1.7. Scope of this document . . . . . . . . . . . . . . . . . 9		1.7. Scope of this document . . . . . . . . . . . . . . . . . 10
	1.8. Structure of this document . . . . . . . . . . . . . . . 10		1.8. Structure of this document . . . . . . . . . . . . . . . 10
	1.9. Convention and Terminology . . . . . . . . . . . . . . . 11		1.9. Convention and Terminology . . . . . . . . . . . . . . . 11
	2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12		2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12
	3. Generic aspects of the PKI message . . . . . . . . . . . . . 13		3. Generic aspects of the PKI message . . . . . . . . . . . . . 14
	3.1. General description of the CMP message header . . . . . . 14		3.1. General description of the CMP message header . . . . . . 15
	3.2. General description of the CMP message protection . . . . 16		3.2. General description of the CMP message protection . . . . 17
	3.3. General description of CMP message extraCerts . . . . . . 17		3.3. General description of CMP message extraCerts . . . . . . 17
	3.4. Generic PKI management operation prerequisites . . . . . 17		3.4. Generic PKI management operation prerequisites . . . . . 18
	3.5. Generic validation of a PKI message . . . . . . . . . . . 19		3.5. Generic validation of a PKI message . . . . . . . . . . . 19
	3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21		3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21
	3.6.1. Reporting error conditions upstream . . . . . . . . . 21		3.6.1. Reporting error conditions upstream . . . . . . . . . 21
	3.6.2. Reporting error conditions downstream . . . . . . . . 22		3.6.2. Reporting error conditions downstream . . . . . . . . 22
	3.6.3. Handling error conditions on nested messages used for		3.6.3. Handling error conditions on nested messages used for
	batching . . . . . . . . . . . . . . . . . . . . . . 22		batching . . . . . . . . . . . . . . . . . . . . . . 22
	3.6.4. Reporting error conditions . . . . . . . . . . . . . 22		3.6.4. Reporting error conditions . . . . . . . . . . . . . 23
	4. End Entity PKI management operations . . . . . . . . . . . . 24		4. End Entity PKI management operations . . . . . . . . . . . . 24
	4.1. Requesting a new certificate from a PKI . . . . . . . . . 27		4.1. Requesting a new certificate from a PKI . . . . . . . . . 27
	4.1.1. Requesting a certificate from a new PKI with		4.1.1. Requesting a certificate from a new PKI with
	signature-based protection . . . . . . . . . . . . . 28		signature-based protection . . . . . . . . . . . . . 28
	4.1.2. Requesting an additional certificate with		4.1.2. Requesting an additional certificate with
	signature-based protection . . . . . . . . . . . . . 34		signature-based protection . . . . . . . . . . . . . 34
	4.1.3. Updating an existing certificate with signature		4.1.3. Updating an existing certificate with signature
	protection . . . . . . . . . . . . . . . . . . . . . 35		protection . . . . . . . . . . . . . . . . . . . . . 35
	4.1.4. Requesting a certificate from a legacy PKI using a		4.1.4. Requesting a certificate from a legacy PKI using a
	PKCS#10 request . . . . . . . . . . . . . . . . . . . 36		PKCS#10 request . . . . . . . . . . . . . . . . . . . 36
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	UNISIG has included a CMP profile for enrollment of TLS certificates		UNISIG has included a CMP profile for enrollment of TLS certificates
	in the Subset-137 specifying the ETRAM/ETCS on-line key management		in the Subset-137 specifying the ETRAM/ETCS on-line key management
	for train control systems [UNISIG.Subset-137] in 2015.		for train control systems [UNISIG.Subset-137] in 2015.
	Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and		Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and
	HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI		HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI
	management operations for unattended devices and services.		management operations for unattended devices and services.
	1.5. Use of CMP in SZTP and BRSKI environments		1.5. Use of CMP in SZTP and BRSKI environments
	In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments,		In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other
	SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing		environments using NETCONF/YANG modules, SZTP-CSR
	requests (CSR) in device bootstrapping to obtain a public-key		[I-D.ietf-netconf-sztp-csr] offers a YANG module that includes
			different types of certificate requests to obtain a public-key
	certificate for a locally generated key pair. One option is using a		certificate for a locally generated key pair. One option is using a
	CMP p10cr message. Such a CSR is of form ietf-sztp-types:cmp-csr		CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp-
	from module ietf-sztp-csr. To allow PKI management entities to also		csr from module ietf-ztp-csr and offers both proof-of-possession and
	comply with this profile, the p10cr message must be formatted by the		proof-of-identity. To allow PKI management entities to also comply
	EE as described in Section 4.1.4 of this profile, and it may be		with this profile, the p10cr message must be formatted by the EE as
	forwarded as specified in Section 5.2.		described in Section 4.1.4 of this profile, and it may be forwarded
			as specified in Section 5.2.
	In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]		In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
	environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous		environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous
	Enrollment [I-D.ietf-anima-brski-async-enroll] describes a		Enrollment [I-D.ietf-anima-brski-async-enroll] describes a
	generalization regarding the employed enrollment protocols to allow		generalization regarding the employed enrollment protocols to allow
	alternatives to EST [RFC7030]. For the use of CMP, it requires		alternatives to EST [RFC7030]. For the use of CMP, it requires
	adherence to this profile.		adherence to this profile.
	1.6. Compatibility with existing CMP profiles		1.6. Compatibility with existing CMP profiles
	skipping to change at page 19, line 11 ¶		skipping to change at page 19, line 21 ¶
	specific name patterns for subject DN or SAN portions that may		specific name patterns for subject DN or SAN portions that may
	identify an RA, and/or by having a dedicated root CA usable only		identify an RA, and/or by having a dedicated root CA usable only
	for authenticating PKI management entities.		for authenticating PKI management entities.
	* Each PKI management entity MUST have sufficient information to be		* Each PKI management entity MUST have sufficient information to be
	able to authorize the downstream PKI entity requesting the PKI		able to authorize the downstream PKI entity requesting the PKI
	management operation.		management operation.
	Note: For authorizing an RA the same examples apply as above. The		Note: For authorizing an RA the same examples apply as above. The
	authorization of EEs can be very specific to the application		authorization of EEs can be very specific to the application
	domain and may involve information from configuration or inventory		domain based on local PKI policy.
	database. It may involve, e.g., the issuer information of the EE
	certificate, specific contents of the CMP protection certificate
	used by the EE such as name patterns of subject DN or SAN
	portions, shared secret information, and other types of
	credentials and evidence potentially communicated out-of-band.
	3.5. Generic validation of a PKI message		3.5. Generic validation of a PKI message
	This section describes generic validation steps of each PKI entity		This section describes generic validation steps of each PKI entity
	receiving a PKI request or response message before any further		receiving a PKI request or response message before any further
	processing or forwarding. If a PKI management entity decides to		processing or forwarding. If a PKI management entity decides to
	terminate a PKI management operation because a check failed, it MUST		terminate a PKI management operation because a check failed, it MUST
	send a negative response or an error message as described in		send a negative response or an error message as described in
	Section 3.6. The PKIFailureInfo bits given below in parentheses MAY		Section 3.6. The PKIFailureInfo bits given below in parentheses MAY
	be used in the failInfo field of the PKIStatusInfo as described in		be used in the failInfo field of the PKIStatusInfo as described in
	skipping to change at page 22, line 28 ¶		skipping to change at page 22, line 35 ¶
	according to the checks described in Section 3.5 it MUST report them		according to the checks described in Section 3.5 it MUST report them
	downstream in the form of an error message as described in		downstream in the form of an error message as described in
	Section 3.6.4.		Section 3.6.4.
	3.6.3. Handling error conditions on nested messages used for batching		3.6.3. Handling error conditions on nested messages used for batching
	Batching of messages using nested messages as described in		Batching of messages using nested messages as described in
	Section 5.2.2.2 requires special error handling.		Section 5.2.2.2 requires special error handling.
	If the error condition is on an upstream nested message containing		If the error condition is on an upstream nested message containing
	batched requests, it MUST not attempt to respond to the individual		batched requests, it MUST NOT attempt to respond to the individual
	requests included in it.		requests included in it.
	In case a PKI management entity receives an error message in response		In case a PKI management entity receives an error message in response
	to a nested message, it must propagate the error by responding with		to a nested message, it must propagate the error by responding with
	an error message to each of the request messages contained in the		an error message to each of the request messages contained in the
	nested message.		nested message.
	In case a PKI management entity detects an error condition on the		In case a PKI management entity detects an error condition on the
	downstream nested message received in response to a nested message		downstream nested message received in response to a nested message
	sent before, it MAY ignore this error condition and handle the		sent before, it MAY ignore this error condition and handle the
	skipping to change at page 23, line 39 ¶		skipping to change at page 23, line 47 ¶
	- certRevoked: Revocation requested for a certificate already		- certRevoked: Revocation requested for a certificate already
	revoked		revoked
	- badCertTemplate: The contents of a certificate request are not		- badCertTemplate: The contents of a certificate request are not
	accepted, e.g., a field is missing or has a non-acceptable		accepted, e.g., a field is missing or has a non-acceptable
	value or the given public key is already in use in some other		value or the given public key is already in use in some other
	certificate (depending on policy).		certificate (depending on policy).
	- transactionIdInUse: This is sent by a PKI management entity in		- transactionIdInUse: This is sent by a PKI management entity in
	case the received request contains a transaction ID that has		case the received request contains a transactionID that has
	already been used for another transaction. An EE receiving		already been used for another transaction. An EE receiving
	such error message SHOULD resend the request in a new		such error message SHOULD resend the request in a new
	transaction using a different transaction ID.		transaction using a different transactionID.
	- notAuthorized: The sender of a request message is not		- notAuthorized: The sender of a request message is not
	authorized for requesting the operation.		authorized for requesting the operation.
	- systemUnavail: This is sent by a PKI management entity in case		- systemUnavail: This is sent by a PKI management entity in case
	a back-end system is not available.		a back-end system is not available.
	- systemFailure: This is sent by a PKI management entity in case		- systemFailure: This is sent by a PKI management entity in case
	a back-end system is currently not functioning correctly.		a back-end system is currently not functioning correctly.
	skipping to change at page 28, line 23 ¶		skipping to change at page 28, line 23 ¶
	potentially intended restrictions of the key usage.		potentially intended restrictions of the key usage.
	Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2		Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2
	[NIST.SP.800-57p1r5] the newly generated private key MAY be used for		[NIST.SP.800-57p1r5] the newly generated private key MAY be used for
	self-signature, if technically possible, even if the keyUsage		self-signature, if technically possible, even if the keyUsage
	extension requested in the certificate request prohibits generation		extension requested in the certificate request prohibits generation
	of digital signatures.		of digital signatures.
	The requesting EE provides the binding of the proof-of-possession to		The requesting EE provides the binding of the proof-of-possession to
	its identity by signature-based or MAC-based protection of the CMP		its identity by signature-based or MAC-based protection of the CMP
	request message containing that POP. As detailed in Section 5.1.1		request message containing that POP. An upstream PKI management
	and Section 5.1.2, an upstream PKI management entity should verify		entity should verify whether this EE is authorized to obtain a
	whether this EE is authorized to obtain a certificate with the		certificate with the requested subject and other fields and
	requested subject and other fields and extensions.		extensions.
	The EE MAY indicate the certificate profile to use in the certProfile		The EE MAY indicate the certificate profile to use in the certProfile
	extension of the generalInfo field in the PKIHeader of the		extension of the generalInfo field in the PKIHeader of the
	certificate request message as described in Section 3.1.		certificate request message as described in Section 3.1.
	In case the EE receives a CA certificate in the caPubs field for		In case the EE receives a CA certificate in the caPubs field for
	installation as a new trust anchor, it MUST properly authenticate the		installation as a new trust anchor, it MUST properly authenticate the
	message and authorize the sender as trusted source of the new trust		message and authorize the sender as trusted source of the new trust
	anchor. This authorization is typically indicated using shared		anchor. This authorization is typically indicated using shared
	secret information for protecting an initialization response (ir)		secret information for protecting an initialization response (ir)
	skipping to change at page 63, line 38 ¶		skipping to change at page 63, line 38 ¶
	-- As described in Section 3.2		-- As described in Section 3.2
	-- MUST use the same credentials as in the first response		-- MUST use the same credentials as in the first response
	-- message of the PKI management operation		-- message of the PKI management operation
	extraCerts RECOMMENDED		extraCerts RECOMMENDED
	-- As described in Section 3.3		-- As described in Section 3.3
	-- MAY be omitted if the message size is critical and the EE has		-- MAY be omitted if the message size is critical and the EE has
	-- cached the extraCerts from the first response message of		-- cached the extraCerts from the first response message of
	-- the PKI management operation		-- the PKI management operation
	Final response – any type of response message		Final response - any type of response message
	Field Value		Field Value
	header		header
	-- MUST be the header as described for the response message		-- MUST be the header as described for the response message
	-- of the respective PKI management operation		-- of the respective PKI management operation
	body		body
	-- The response of the PKI management entity to the initial		-- The response of the PKI management entity to the initial
	skipping to change at page 67, line 50 ¶		skipping to change at page 67, line 50 ¶
	message if this is technically necessary. Concrete PKI system		message if this is technically necessary. Concrete PKI system
	specifications may define in more detail when to do so.		specifications may define in more detail when to do so.
	This is particularly relevant in the upstream communication of a		This is particularly relevant in the upstream communication of a
	request message.		request message.
	Each forwarding PKI management entity has one or more		Each forwarding PKI management entity has one or more
	functionalities. It may		functionalities. It may
	* verify the identities of EEs and make authorization decisions for		* verify the identities of EEs and make authorization decisions for
	certification request processing based on specific knowledge of		certification request processing based on local PKI policy,
	the local setup, e.g., by consulting an inventory or asset
	management system,
	* add or modify fields of certificate request messages,		* add or modify fields of certificate request messages,
	* store data from a message in a database for later usage or audit		* store data from a message in a database for later usage or audit
	purposes,		purposes,
	* provide traversal of a network boundary,		* provide traversal of a network boundary,
	* replace a MAC-based protection by a signature-based protection		* replace a MAC-based protection by a signature-based protection
	that can be verified also further upstream,		that can be verified also further upstream,
	* double-check if the messages transferred back and forth are		* double-check if the messages transferred back and forth are
	properly protected and well-formed,		properly protected and well-formed,
	skipping to change at page 71, line 15 ¶		skipping to change at page 71, line 15 ¶
	The PKI management entity responding to the request contained in the		The PKI management entity responding to the request contained in the
	nested message sends the response message as described in		nested message sends the response message as described in
	Section 5.1, without wrapping it in a nested message.		Section 5.1, without wrapping it in a nested message.
	Note: This form of nesting messages is characterized by the fact that		Note: This form of nesting messages is characterized by the fact that
	the transactionID in the header of the nested message is the same as		the transactionID in the header of the nested message is the same as
	the one used in the included message.		the one used in the included message.
	Specific prerequisites augmenting the prerequisites in Section 3.4:		Specific prerequisites augmenting the prerequisites in Section 3.4:
	* The PKI management entity MUST have the authorization to perform		* The PKI management entity MUST be able to validate the respective
	the validation and approval of the respective request according to		request and have the authorization to perform approval of the
	the PKI policies.		request according to the PKI policies.
	Message flow:		Message flow:
	Step# PKI management entity PKI management entity		Step# PKI management entity PKI management entity
	1 format nested		1 format nested
	2 -> nested ->		2 -> nested ->
	3 handle or forward nested		3 handle or forward nested
	4 format or receive response		4 format or receive response
	5 <- response <-		5 <- response <-
	6 forward response		6 forward response
	skipping to change at page 74, line 11 ¶		skipping to change at page 74, line 11 ¶
	This variant of forwarding a message means that a PKI management		This variant of forwarding a message means that a PKI management
	entity forwards a CMP message with or without modifying the message		entity forwards a CMP message with or without modifying the message
	header or body while preserving any included proof-of-possession.		header or body while preserving any included proof-of-possession.
	In case the PKI management entity breaks an existing proof-of-		In case the PKI management entity breaks an existing proof-of-
	possession, the message adaptation described in Section 5.2.3.2 needs		possession, the message adaptation described in Section 5.2.3.2 needs
	to be applied instead.		to be applied instead.
	Specific prerequisites augmenting the prerequisites in Section 3.4:		Specific prerequisites augmenting the prerequisites in Section 3.4:
	* The PKI management entity MUST have the authorization to perform		* The PKI management entity MUST be able to validate the respective
	the validation and approval of the respective request according to		request and have the authorization to perform approval of the
	the PKI policies.		request according to the PKI policies.
	5.2.3.2. Breaking proof-of-possession		5.2.3.2. Breaking proof-of-possession
	This variant of forwarding a message needs to be used if a PKI		This variant of forwarding a message needs to be used if a PKI
	management entity breaks a signature-based proof-of-possession in a		management entity breaks a signature-based proof-of-possession in a
	certificate request message, for instance because it forwards an ir		certificate request message, for instance because it forwards an ir
	or cr message with modifications of the certTemplate, i.e.,		or cr message with modifications of the certTemplate, i.e.,
	modification, addition, or removal of fields.		modification, addition, or removal of fields.
	The PKI management entity MUST verify the proof-of-possession		The PKI management entity MUST verify the proof-of-possession
	contained in the original message using the included public key. If		contained in the original message using the included public key. If
	successful, the PKI management entity MUST change the popo field		successful, the PKI management entity MUST change the popo field
	value to raVerified.		value to raVerified.
	Specific prerequisites augmenting the prerequisites in Section 3.4:		Specific prerequisites augmenting the prerequisites in Section 3.4:
	* The PKI management entity MUST have the authorization to verify		* The PKI management entity MUST be authorized to replace the proof-
	the proof-of-possession.		of-possession (after verifying it) with raVerified.
	* The PKI management entity MUST have the authorization to perform		* The PKI management entity MUST be able to validate the respective
	the validation and approval of the respective request according to		request and have the authorization to perform approval of the
	the PKI policies.		request according to the PKI policies.
	The new popo field MUST contain the raVerified choice in the certReq		The new popo field MUST contain the raVerified choice in the certReq
	structure of the modified message as follows:		structure of the modified message as follows:
	popo		popo
	raVerified REQUIRED		raVerified REQUIRED
	-- MUST have the value NULL and indicates that the PKI		-- MUST have the value NULL and indicates that the PKI
	-- management entity verified the popo of the original message		-- management entity verified the popo of the original message
	5.3. Acting on behalf of other PKI entities		5.3. Acting on behalf of other PKI entities
	skipping to change at page 79, line 30 ¶		skipping to change at page 79, line 30 ¶
	keys, also confidentiality is a must. These goals are sufficiently		keys, also confidentiality is a must. These goals are sufficiently
	achieved by CMP itself, also in an end-to-end fashion. If a second		achieved by CMP itself, also in an end-to-end fashion. If a second
	line of defense is required or general privacy concerns exist, TLS		line of defense is required or general privacy concerns exist, TLS
	can be used to provide confidentiality on a hop-by-hop basis.		can be used to provide confidentiality on a hop-by-hop basis.
	TLS SHOULD be used with certificate-based authentication to further		TLS SHOULD be used with certificate-based authentication to further
	protect the HTTP transfer as described in [RFC2818]. The CMP		protect the HTTP transfer as described in [RFC2818]. The CMP
	transfer via HTTPS MUST use TLS server authentication and SHOULD use		transfer via HTTPS MUST use TLS server authentication and SHOULD use
	TLS client authentication.		TLS client authentication.
	Note: The requirements for checking certificates given in [RFC5280],		Note: The requirements for checking certificates given in [RFC5280]
	[RFC5246], and [RFC8446] MUST be followed for the TLS layer.		and either [RFC5246] or [RFC8446] MUST be followed for the TLS layer.
	Certificate status checking SHOULD be used for the TLS certificates		Certificate status checking SHOULD be used for the TLS certificates
	of all communication partners.		of all communication partners.
	TLS with mutual authentication based on shared secret information MAY		TLS with mutual authentication based on shared secret information MAY
	be used in case no suitable certificates for certificate-based		be used in case no suitable certificates for certificate-based
	authentication are available, e.g., a PKI management operation with		authentication are available, e.g., a PKI management operation with
	MAC-based protection is used.		MAC-based protection is used.
	Note: The entropy of the shared secret information is crucial for the		Note: The entropy of the shared secret information is crucial for the
	level of protection available using shard secret information-based		level of protection available using shard secret information-based
	skipping to change at page 87, line 17 ¶		skipping to change at page 87, line 17 ¶
	Sahni, M. and S. Tripathi, "CoAP Transfer for the		Sahni, M. and S. Tripathi, "CoAP Transfer for the
	Certificate Management Protocol", Work in Progress,		Certificate Management Protocol", Work in Progress,
	Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8		Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8
	November 2021, <https://datatracker.ietf.org/doc/html/		November 2021, <https://datatracker.ietf.org/doc/html/
	draft-ietf-ace-cmpv2-coap-transport-04>.		draft-ietf-ace-cmpv2-coap-transport-04>.
	[I-D.ietf-lamps-cmp-algorithms]		[I-D.ietf-lamps-cmp-algorithms]
	Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,		Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
	"Certificate Management Protocol (CMP) Algorithms", Work		"Certificate Management Protocol (CMP) Algorithms", Work
	in Progress, Internet-Draft, draft-ietf-lamps-cmp-		in Progress, Internet-Draft, draft-ietf-lamps-cmp-
	algorithms-08, 17 November 2021,		algorithms-09, 22 December 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	cmp-algorithms-08>.		cmp-algorithms-09>.
	[I-D.ietf-lamps-cmp-updates]		[I-D.ietf-lamps-cmp-updates]
	Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate		Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
	Management Protocol (CMP) Updates", Work in Progress,		Management Protocol (CMP) Updates", Work in Progress,
	Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17		Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12
	December 2021, <https://datatracker.ietf.org/doc/html/		January 2022, <https://datatracker.ietf.org/doc/html/
	draft-ietf-lamps-cmp-updates-15>.		draft-ietf-lamps-cmp-updates-17>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification		[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
	Request Syntax Specification Version 1.7", RFC 2986,		Request Syntax Specification Version 1.7", RFC 2986,
	DOI 10.17487/RFC2986, November 2000,		DOI 10.17487/RFC2986, November 2000,
	<https://www.rfc-editor.org/info/rfc2986>.		<https://www.rfc-editor.org/info/rfc2986>.
	skipping to change at page 89, line 16 ¶		skipping to change at page 89, line 16 ¶
	Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI		Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
	with Pledge in Responder Mode (BRSKI-PRM)", Work in		with Pledge in Responder Mode (BRSKI-PRM)", Work in
	Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,		Progress, Internet-Draft, draft-ietf-anima-brski-prm-00,
	25 October 2021, <https://datatracker.ietf.org/doc/html/		25 October 2021, <https://datatracker.ietf.org/doc/html/
	draft-ietf-anima-brski-prm-00>.		draft-ietf-anima-brski-prm-00>.
	[I-D.ietf-netconf-sztp-csr]		[I-D.ietf-netconf-sztp-csr]
	Watsen, K., Housley, R., and S. Turner, "Conveying a		Watsen, K., Housley, R., and S. Turner, "Conveying a
	Certificate Signing Request (CSR) in a Secure Zero Touch		Certificate Signing Request (CSR) in a Secure Zero Touch
	Provisioning (SZTP) Bootstrapping Request", Work in		Provisioning (SZTP) Bootstrapping Request", Work in
	Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-12,		Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-13,
	3 December 2021, <https://datatracker.ietf.org/doc/html/		31 January 2022, <https://datatracker.ietf.org/doc/html/
	draft-ietf-netconf-sztp-csr-12>.		draft-ietf-netconf-sztp-csr-13>.
	[IEC.62443-3-3]		[IEC.62443-3-3]
	IEC, "Industrial communication networks - Network and		IEC, "Industrial communication networks - Network and
	system security - Part 3-3: System security requirements		system security - Part 3-3: System security requirements
	and security levels", IEC 62443-3-3, August 2013,		and security levels", IEC 62443-3-3, August 2013,
	<https://webstore.iec.ch/publication/7033>.		<https://webstore.iec.ch/publication/7033>.
	[IEEE.802.1AR_2018]		[IEEE.802.1AR_2018]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks - Secure Device Identity", IEEE 802.1AR-2018,		networks - Secure Device Identity", IEEE 802.1AR-2018,
	skipping to change at page 93, line 12 ¶		skipping to change at page 93, line 12 ¶
	}		}
	}		}
	}		}
	Appendix B. History of changes		Appendix B. History of changes
	Note: This appendix will be deleted in the final version of the		Note: This appendix will be deleted in the final version of the
	document.		document.
			From version 09 -> 10:
			* Resolved some nits reported by I-D nit checker tool
			* Resolve some wording issues
	From version 08 -> 09:		From version 08 -> 09:
	* Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into		* Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into
	more detailed tables in Section 7 (see thread "WG Last Call for		more detailed tables in Section 7 (see thread "WG Last Call for
	draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-		draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-
	cmp-profile-08")		cmp-profile-08")
	* Updated Section 3.1 and 4.1.1 making implicitConfirm recommended		* Updated Section 3.1 and 4.1.1 making implicitConfirm recommended
	for ir/cr/p10cr/kur and providing further recommendations on its		for ir/cr/p10cr/kur and providing further recommendations on its
	use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp-		use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp-
	updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")		updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")
	skipping to change at page 96, line 12 ¶		skipping to change at page 96, line 21 ¶
	From version 01 -> 02:		From version 01 -> 02:
	* Extend Section 1.6 with regard to conflicts with UNISIG Subset-		* Extend Section 1.6 with regard to conflicts with UNISIG Subset-
	137.		137.
	* Minor clarifications on extraCerts in Section 3.3 and		* Minor clarifications on extraCerts in Section 3.3 and
	Section 4.1.1.		Section 4.1.1.
	* Complete specification of requesting a certificate from a trusted		* Complete specification of requesting a certificate from a trusted
	PKI with signature protection in Section 4.1.2.		PKI with signature protection in Section 4.1.2.
	* Changed from symmetric key-encryption to password-based key		* Changed from symmetric key-encryption to password-based key
	management technique in section Section 4.1.6.3 as discussed on		management technique in Section 4.1.6.3 as discussed on the
	the mailing list (see thread "draft-ietf-lamps-lightweight-cmp-		mailing list (see thread "draft-ietf-lamps-lightweight-cmp-
	profile-01, section 5.1.6.1")		profile-01, section 5.1.6.1")
	* Changed delayed enrollment described in Section 4.4 from		* Changed delayed enrollment described in Section 4.4 from
	recommended to optional as decided at IETF 107		recommended to optional as decided at IETF 107
	* Introduced the new RootCAKeyUpdate structure for root CA		* Introduced the new RootCAKeyUpdate structure for root CA
	certificate update in Section 4.3.2 as decided at IETF 107 (also		certificate update in Section 4.3.2 as decided at IETF 107 (also
	see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,		see email thread "draft-ietf-lamps-lightweight-cmp-profile-01,
	section 5.4.3")		section 5.4.3")
	* Extend the description of the CertReqTemplate PKI management		* Extend the description of the CertReqTemplate PKI management
	operation, including an example added in the Appendix. Keep		operation, including an example added in the Appendix. Keep
	rsaKeyLen as a single integer value in Section 4.3.3 as discussed		rsaKeyLen as a single integer value in Section 4.3.3 as discussed
End of changes. 29 change blocks.
	60 lines changed or deleted		59 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/